Loading ToolBench
AstroFabric MCP server (stdio): agentic AI for business intelligence, company and contact discovery, verification, enrichment, signals, lists and governed delivery.
Single tool with well-defined schema, good description, and proper use of annotations. The mission_agent tool has clear input parameters with Zod validation, comprehensive description explaining the stateful thread continuation pattern, and explicit destructiveHint/openWorldHint annotations. However, output schema is not formally documented (response structure is inferred from the implementation), and error messages are functional but could be more structured. The tool follows a reasonable single-responsibility pattern (autonomous mission execution), though the description is relatively lengthy (500+ chars) at the upper end of the optimal range. No parameter validation issues detected, objective has min/max length constraints, thread_id is optional with length limit.
Give AstroFabric a business intelligence objective in plain language. It plans and executes a data mission: discover companies and contacts, verify emails, enrich records, research business signals, score account fit, build lists and audiences, and deliver results into connected systems under workspace budgets and approval settings. The result starts with a [thread:<id>] line; pass that id as thread_id on follow-ups to continue the mission. It may reply with a clarifying question; answer it the same way.
Output schema not formally documented. Callers must infer response structure (thread_id prefix, reply text) from implementation and description text rather than a declared schema. LLMs cannot reliably plan downstream actions without knowing what fields the tool returns.
Error responses lack actionable recovery guidance. Examples: 'Could not reach the AstroFabric API: <error>' and 'Mission failed: <detail>' tell the LLM that something went wrong but not what to do next (retry? check the key? wait?). Should return structured error with retry_after, error_code, and suggested_action.
No timeout handling documentation in the parameter description. The 720-second timeout is hardcoded server-side and invisible to LLMs. If a mission times out, the error message mentions 'unusually long' but does not clarify the actual timeout duration or when to retry. Should document the timeout behavior in the tool description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
Permission model not declared. The tool description mentions 'workspace budgets and approval settings' but does not specify what scopes or permissions the calling agent requires. Should declare required permissions (e.g., 'requires: mission.execute, workspace.read') so agents can be configured with least privilege.