What this category of data looks like
Data for this category is generated by change management teams composed of R&D, process, quality, production, and procurement personnel at manufacturing enterprises. Sources include PLM, ERP, MES, supplier materials, validation tests, and customer-specific requirements. Data updates are triggered irregularly with each process or engineering change. Core documents include ECN/ECR forms, change assessment reports, drawings and BOM version files, process validation reports, production switching plans, inventory disposal documents, and customer approval documents. Fields include change number, version number, associated bill of materials, validation results, and approval node information.
What constraints these characteristics impose on the tool calling and plugins workflow
Data sources for this category are scattered and have diverse formats, requiring tool calling to support interface integration with multiple systems such as PLM, ERP, and MES to prevent data synchronization failures caused by incompatible interface formats. Data updates have no fixed cycle, so tools must support real-time pulling of the latest change documents and version information, and cannot rely on static cached data. Core documents include structured forms and unstructured drawings, so tools must support parsing rules for different formats to ensure accurate field extraction. Validation tasks for complex changes take a long time, so tool calling configurations must support long-running tasks to avoid premature termination.
Configuration reference
This document applies to FastGPT v4.17.0. The following are reference settings for tool calling and plugins:
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Workflow/API function-call configuration | Enable forced tool calling | Requires calling a custom MCP service to handle complex change validation logic, ensuring transaction processes execute as expected |
| Workflow/API tool selection | Automatically match corresponding tools | Needs to automatically call interfaces from different systems such as PLM and MES based on change type to improve audit efficiency |
| Tool call timeout setting | 180 seconds | Complex transaction processing for custom MCP services typically exceeds 90 seconds, so the setting must accommodate long-running tasks |
| Document parsing format adaptation | Automatically switch parsing rules based on document type | Core documents include multiple formats such as structured forms, drawings, and BOM files, so matching corresponding parsing logic is required |
| API call retry count | 3 times | Prevents interface call failures caused by temporary network fluctuations, improving audit process stability |
| Context window size | 8000 token | Requires carrying complete change history, associated documents, and approval records to ensure the large language model generates accurate audit suggestions |
Three common configuration errors
- Timeout termination when calling a custom MCP service, with a specified error message displayed in the interface. The cause is that the default timeout waiting period for the MCP service is 90 seconds, while complex change validation task processing time exceeds this threshold.
- Empty responses marked with the
chat:LLM_model_response_emptyidentifier returned by conversation nodes. The cause is that core document data such as ECN and BOM versions associated with the change was not fully carried during tool calling, preventing the large language model from generating valid audit content. - Failure to synchronize updated version information to the PLM system after change audit. The cause is that the tool calling configuration is not bound to the update interface of the corresponding system, or the parameter transfer format does not meet the requirements of the target system.
How to verify the configuration is correct
- Test calling the custom MCP service, submit a simulated complex change validation task, and confirm that the task completes normally even when processing time exceeds 120 seconds, to verify that the timeout configuration is effective.
- Submit a simulated change application, check whether the tool automatically calls the interface of the corresponding system and returns correct associated data, to verify that the tool selection strategy configuration is effective.
- View the conversation log, confirm that the large language model response includes all complete document fields required for change audit, with no empty responses, to verify that the context configuration is reasonable.
- Cross-check data in the PLM and MES systems, confirm that change information has been synchronized and updated, to verify that the interface binding configuration is correct.
The values listed above are common starting points and should be evaluated against the reader's own samples.