Loading ToolBench
CLI and MCP server for noticed — search your developer network, trace connections, find the shortest path to anyone through GitHub and LinkedIn.
Two tools with complete schemas and reasonable descriptions, but significant gaps in parameter documentation and output schema clarity. The 'search' tool has good descriptions (154 chars) and proper enum guidance for category. The 'execute' tool description is adequate (145 chars) but lacks guidance on error recovery. Both tools have proper JSON Schema with type definitions and constraints. However, neither tool documents its output schema structure, forcing LLMs to infer response format. Parameter descriptions are present but minimal, 'Capability name from search results' and 'Arguments object matching the capability's parameter schema' lack actionable detail on what fields to expect or how to construct args. The server-side denylist filtering is mentioned in comments but not exposed to the LLM, creating a hidden contract. No error handling guidance is visible in tool descriptions.
Run a capability by exact name. Use `search` first to find the name and required arguments. Pass capability arguments in the `args` object (e.g. args: { mission_id: '...' }).
Discover noticed capabilities by keyword and optional category. Returns names, descriptions, categories, and JSON parameter schemas. Call with no arguments to list everything. This is the source of truth for which capabilities exist — do not assume a fixed list.
Output schemas not documented. Neither 'search' nor 'execute' declares what fields the response contains. LLMs cannot plan downstream calls or extract required data without knowing response structure.
Parameter 'args' in execute tool lacks structure guidance. Description says 'Arguments object matching the capability's parameter schema' but does not explain how LLM discovers that schema or what happens if args are malformed. Should reference search tool or provide error recovery guidance.
No error handling guidance in tool descriptions. If execute fails (capability not found, args invalid, API error), the description does not tell the LLM what to do next. Should include recovery hints like 'If capability not found, call search() first.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Server-side denylist (nine chat-only capabilities filtered) is mentioned in code comments but not exposed to the LLM. LLM may attempt to call filtered capabilities and receive confusing 'not found' errors instead of understanding why they are unavailable.
Parameter 'limit' in search tool has default=50 but description says 'returns the full chat-safe registry for an unfiltered call', unclear whether limit=50 is the full registry or a truncation. If registry is larger, pagination guidance is missing.