Loading ToolBench
The MCP door: a broker in front of your assistant's tool calls — scoped per caller, under a credential it never holds, revocable, metered, audited
Single tool 'list_tools' has a reasonable description (127 chars, within 10-1024 range) but lacks a visible input schema in the provided source. The tool is described as READ_ONLY and returns a menu of available tools. However, no explicit parameter definitions, output schema documentation, or error handling guidance is visible in the code sample. The description is adequate but generic, it does not explain WHEN to call this tool, what format the response takes, or how to use the returned data. No evidence of input validation, pagination, or structured output schema.
Everything this tenant may grant, grouped by where it came from. No grant is required. Returns the menu of available tools, not anybody's order. This contacts no server — connector tools are described from the stored manifest.
No input schema visible for list_tools. Tool definition lacks parameter types, constraints, and descriptions required for LLM invocation.
Output schema not documented. LLMs cannot infer the structure of the returned tool menu (fields, types, pagination, nested objects).
Description lacks WHEN/WHY guidance. 'Everything this tenant may grant' is vague. Does not explain when to call this vs other discovery tools, or how to interpret the response.
No error handling documented. What happens if the tenant has no grants? If the manifest is corrupted? LLM receives no recovery guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | <=2025-11-25 | v2 |
Tool name 'list_tools' is generic and self-referential. Does not convey the actual domain action (e.g., 'list_available_tools', 'discover_granted_tools', 'list_connector_tools').