What data for this category looks like
Core data of image annotation projects comes from image samples, annotation platforms, category dictionaries, and inspection results. Daily produced documents include annotation specifications, bounding box examples, quality inspection reports, and rework lists. Data update frequency is usually daily or per annotation batch. Core work steps focus on target bounding box definition, occluded sample judgment, and rework communication. Relevant data must be strongly bound to visual target position and category information, which differs from annotation projects that only handle text information.
What constraints these characteristics impose on the "tool calling and plugins" link
Since data sources include multiple types of heterogeneous resources, tool calling must adapt to multiple scenarios such as image sample preprocessing, annotation platform API pulling, and category dictionary verification. Clear trigger conditions and parameter formats must be defined for different tools. The daily or batch update frequency requires tool calling to support scheduled batch execution, to avoid interface overload caused by excessive single-call data volume. The diverse document types require tool return results to support text, structured tables, and file data. It must also support classified storage of returned data by project batch, to facilitate subsequent association processing for quality inspection and rework workflows. The strong binding of visual target position and category information requires tool call results to include complete field verification logic, to ensure returned data matches established rules and reduce subsequent rework risks.
How to set the configuration
This configuration is based on FastGPT v4.17.0. The following are recommended values for core configuration items and their rationale:
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
toolChoice | auto | Adapts to multi-tool calling scenarios, covering core needs such as annotation data pulling and quality inspection report generation |
functionCall | [{"name":"pull_annotation_data","parameters":{"batch_id":"{{batch_id}}"}}] | Matches the batch-managed document structure of the project, accurately pulling annotation data for the corresponding batch |
| Tool call timeout | 300–600 seconds | Image sample processing and annotation data pulling usually require long wait times, preventing task interruption due to timeout |
| Batch call batch size | 20–50 items per batch | Matches daily or per-batch update frequency, balancing interface load and data processing efficiency |
| Return result storage path | /data/annotation_project/{{batch_id}}/ | Organizes and stores results by batch, facilitating subsequent quality inspection report generation and rework list association |
| Result verification switch | Enabled | Verifies consistency between returned annotation data, category dictionaries, and inspection results, reducing recognition error risks |
Three common mistakes
- Phenomenon: After an MCP tool call is executed in a workflow node, downstream nodes cannot obtain the annotation data fields returned by the tool. Cause: The result pass-through switch is not enabled in the tool configuration, causing the return value to not be correctly mounted to the context variable.
- Phenomenon: After calling an external annotation platform interface and returning a PPTX-format quality inspection report, the file cannot be directly pushed to the querying user. Cause: Only processing logic for text-type results is configured, and no steps for file storage and return binding are added.
- Phenomenon: When calling a model to query Mongo data for annotation projects, the token consumption displayed by the platform differs from the actual API call token consumption. Cause: Context caching for category dictionaries and bounding box examples is not included in the platform's token statistics range, leading to deviations in statistical results.
How to confirm the configuration is correct
- Execute a tool call test, check if the returned fields include key information of annotation data, category dictionaries, and inspection results, and verify that the fields match the project document structure.
- View tool call logs, confirm that the timeout setting meets the requirements of the business update frequency, and no frequent timeout errors occur.
- Verify that the return result storage path matches the project batch management rules, and manually check if formatted files are generated in the corresponding path.
- Trigger a rework list association call, confirm that the rework data returned by the tool can be correctly associated with the original annotation task, with no missing fields.
The values provided are common starting points and should be measured against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.