What data for this category looks like
Vulnerability scanning service data originates from vulnerability scanners, asset inventories, CVE databases, and patch bulletins. Daily generated documents include scanning plans, vulnerability lists, rectification work orders, and rescan reports. Scanning plans include an execution cycle field. Vulnerability lists include fields such as CVE numbers, asset IP addresses, vulnerability severity levels, and discovery times. Rectification work orders link corresponding vulnerabilities and rectification responsible parties. Rescan reports include details such as rescan times and rectification completion rates. Data updates occur weekly or monthly. The asset scope covered by a single scan is limited by fields like IP ranges and tags in the asset inventory.
What constraints these characteristics impose on tool calling and plugins
Data sources are scattered, and update cycles are fixed. Tool calling must support batch pulling of multi-source data to avoid repeated requests to different interfaces. Field restrictions on asset scope and vulnerability severity require targeted filtering rules for tool calling. Only fields and data that meet business requirements are processed. Daily documents have multiple types. Plugins must support mapping different parameter logic based on document type. For example, the cycle parameter of scanning plans must match the data update rhythm. Fields in rescan reports must link with rectification work orders. Data update frequency is low. Tool calling trigger cycles must align with weekly or monthly update rhythms to avoid invalid calls.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
toolChoice | auto | Adapts to FastGPT v4.17.0's automatic tool selection logic, supports on-demand calling of vulnerability scanning-related plugins |
functionCall | {"name": "vulnerability_scan", "parameters": {"scan_type": "full"}} | Binds a preset vulnerability scanning tool, specifies a full scan type to match the coverage scope of the asset inventory |
| Scheduled trigger cycle | Weekly / Monthly | Matches the weekly or monthly data update frequency of the vulnerability scanning service, avoids frequent triggering of invalid scans |
| Asset scope filtering | Match by asset IP prefix | Based on the IP range field in the asset inventory, filters scan data outside the target scope |
| False positive filtering threshold | Medium and high severity | Based on the severity field in the vulnerability list, excludes low-severity false positive data and focuses on core risks |
| Single tool call timeout | 600 seconds | Matches the typical execution duration of vulnerability scans, avoids call failures due to excessively long scan times |
Three common errors
- Calls to the
/api/v1/chat/completionsAPI do not apply the provided prompt. This occurs when context parameters forfunctionCallare not configured correctly, so the model does not load the preset vulnerability scanning business prompt. - The number of vulnerabilities returned by tool calls does not match expectations. This happens when no asset scope filtering rules are configured, leading to a scan scope that exceeds the preset asset inventory.
- No rescan report is generated after plugin execution. This is caused by missing trigger conditions for result synchronization, so scan data is not written to the corresponding document template.
How to verify correct configuration
- Initiate a test call to
/api/v1/chat/completions. Check if the returned results include vulnerability scanning-related tool call output. - View FastGPT plugin logs to confirm the scheduled trigger cycle matches the preset weekly or monthly rules.
- Manually modify the rectification status of a high-severity vulnerability. Check if corresponding fields are updated synchronously in the rescan report.
- Verify the token authentication method. Confirm the
Authorizationparameter in the request header conforms to platform requirements.
The values provided are common starting points and should be measured against local operational 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.