What the data for this category looks like
Market data originates from official interfaces of compliant trading venues and professional market aggregation services. Update frequency adjusts dynamically with trading hours. It refreshes frequently during trading hours, and syncs at fixed intervals outside trading hours. Data is packaged in structured JSON format. Core fields include ticker code, transaction timestamp, latest transaction price, price change percentage, trading volume, and trading amount. Units follow standard measurement formats used by the trading venue, such as Chinese yuan and shares. The data structure strictly matches trading rules. Fields have no redundancy and are tightly bound to trading behavior.
Constraints These Characteristics Impose on Tool Calling and Plugins
The high-frequency update nature of market data requires strict control of request frequency for tool calls, to avoid triggering rate limiting rules of trading interfaces. The structured field structure requires precise specification of tickers and query dimensions when calling plugins. Fuzzy matching cannot be used to obtain valid results. The extremely strong timeliness requires that the result cache duration for tool calls must be very short. Otherwise, returned data will lose practical value due to insufficient real-time performance. At the same time, market data is tightly tied to trading. Abnormal statuses returned by interfaces must be identified and handled quickly, to avoid impacting the overall natural language retrieval workflow.
Configuration Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
mcpServerProxyEndpoint | https://your-mcp-server-proxy:8080/mcp | Market data plugins must connect to compliant market interfaces via an MCP proxy. Specify the full access address of the proxy service |
toolCallFrequencyLimit | 10 requests per 10 seconds | Most market data interfaces have high-frequency rate limits. Avoid triggering interception by sending too many requests in a short period |
resultCacheTTL | 3 seconds | Market data has extremely strong timeliness. Cache duration must match the high-frequency update rhythm to avoid returning expired data |
requiredToolFields | ["symbol", "tradeTime", "latestPrice"] | Core fields of market data are ticker identifier, transaction time, and latest price. Mandatory specification can filter invalid returns |
mcpConnectionTimeout | 5 seconds | Market interfaces require real-time response. Timeout settings must be strictly controlled to avoid blocking the natural language retrieval workflow |
maxToolCallRetries | 2 retries | Limited retries can improve call success rates during network fluctuations or temporary interface rate limiting. Avoid excessive retries that trigger anti-scraping measures |
The parameter values provided on this page are common starting points for configuration. Actual values are affected by data form, data volume, and business rules. Specific issues require targeted analysis. Testing on local samples is recommended before finalizing settings.
Three Common Configuration Mistakes
- Symptom: Empty results are returned after calling, with no market data. Cause:
mcpServerProxyEndpointis not configured correctly, or the proxy service has not connected to a compliant market data interface, so no valid data source can be accessed. - Symptom: Tool calls trigger a
429 Too Many Requestserror. Cause:toolCallFrequencyLimitis not set, or the limit threshold is too high. Sending too many requests in a short period triggers the rate limiting rules of the market data interface. - Symptom: Returned market data fields are missing or formatted incorrectly. Cause: Core fields are not specified via
requiredToolFields, or the structured data parsing switch is not enabled. This prevents the plugin from correctly extracting target fields.
How to Verify Successful Configuration
- The plugin debugging panel in FastGPT can be used to manually input a ticker code and query instruction, trigger a tool call, and check if the returned structured data contains the preset core fields.
- Running logs of the MCP proxy service can be reviewed to confirm successful market data interface requests and return records, with no connection timeout or permission errors.
- Adjust
resultCacheTTLto 0, send two identical queries consecutively, and confirm that the transaction timestamps of the two returned results differ. This verifies that the real-time update logic is active. - Simulate sending multiple requests in a short period, check if a
429 Too Many Requestserror is triggered, and confirm that thetoolCallFrequencyLimitconfiguration is effective.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.