Loading ToolBench
Platform API server for BlockNext AI with MCP (Model Context Protocol) integration for tool execution and workflow management
Two tools with basic verb-noun naming (get_*) and documented input schemas. However, descriptions are minimal (under 100 chars each), parameter descriptions are generic, and output schemas are not documented. No error handling guidance, no pagination metadata returned, and no tool annotations. Schemas present but lack depth, parameters have types but descriptions are sparse. This is typical of a basic API wrapper without LLM-optimization.
Retrieve all tool invocations for an organization with pagination and search support
Retrieve a specific tool invocation by ID for an organization
Minimal parameter descriptions. 'query' is described as 'Search query string' (18 chars), does not explain what fields are searched, format constraints, or when to use it vs other filters.
No output schema documented. LLMs cannot infer what fields are returned (e.g., does get_all_tool_invocations return pagination metadata, timestamps, status codes?). Breaks downstream tool chaining.
No pagination guidance in tool description. get_all_tool_invocations accepts offset/limit but does not state result cap, total count return, or when pagination is required.
No error handling or recovery guidance. If organizationId is invalid or user lacks permission, what error is returned? How should the LLM respond?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Both tools are read-only but this is not declared in the schema, forcing LLMs to infer safety from the name alone.