Loading ToolBench
A client library and toolkit for accessing Gatana MCP servers and managing tools through API endpoints
This is a HTTP client library that wraps REST API calls to a Gatana backend service, not an MCP server. The 9 tools are thin wrappers around HTTP endpoints with minimal schema definition. Tool names use REST conventions (get_*, put_, post_) rather than action-oriented MCP naming. Descriptions are present but minimal (13-72 chars, well below the 50-200 char LLM-optimized range). Input schemas exist but are severely underdocumented: most parameters have only a description string and type, with no guidance on constraints, enums, valid ranges, or dependencies. Output schemas are not visible in the provided code, the response types (Schema257, ServerToolDto) are not defined here. Error handling is generic (UnexpectedStatus, TimeoutException) with no recovery guidance. The tool definitions appear to be auto-generated from an OpenAPI spec rather than hand-crafted for agent readability.
Get all tools available for a specific MCP server
Get a specific tool by name from an MCP server
Get all tools associated with a specific profile
Get all available tools across all servers
Call a specific tool on an MCP server with arguments
Refresh tools configuration, optionally for a specific server
Enable or disable all tools for a specific MCP server
Tool names use REST API conventions (get_*, post_*, put_) rather than action-oriented verb_noun naming. Names like 'get_mcp_servers_server_slug_tools' are opaque and lengthy, forcing LLMs to parse URL structure instead of inferring intent from the name. Recommended: rename to 'list_server_tools', 'get_server_tool', 'call_tool', 'enable_server_tools', 'enable_tool', 'list_profile_tools', 'configure_profile_server_tools', 'discover_tools', 'refresh_tools'.
Descriptions are minimal (13 - 72 chars, below the 50 - 200 char LLM-optimized baseline). Most lack context on WHEN to use the tool, what it returns, or how it relates to other tools. Example: 'Get all tools available for a specific MCP server' (51 chars) does not explain whether this lists enabled tools, all tools, or metadata. LLMs struggle to select the right tool without richer context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 26 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Enable or disable a specific tool for an MCP server
Update tools configuration for a profile on a specific server
Output schemas are not documented in the visible code. Response types like 'Schema257' and 'ServerToolDto' are opaque type references without visible field definitions. LLMs cannot plan downstream tool calls or extract the right data without knowing what fields to expect. This violates the 'Document the output schema' requirement.
Parameter descriptions are generic and lack constraints. 'server_slug' and 'tool_name' are described only as 'The server slug identifier' and 'The name of the tool', no guidance on format, length limits, valid characters, or examples. The 'body' parameter in POST/PUT tools references opaque schema objects (PostMcpServersServerSlugToolsToolNameCallBody, Schema73) without inline documentation.
Error handling is minimal. The code catches 'UnexpectedStatus' and 'TimeoutException' but provides no recovery guidance to the LLM. A 404 response does not suggest alternative tools or next steps. LLMs cannot self-correct without actionable error messages.
No tool annotations present (toolAnnotations=false). Tools that modify state (post_*, put_*) should declare 'destructiveHint: true' and 'idempotentHint' to guide agent retry logic. Current-spec MCP requires these hints for proper agent planning.
Parameters use generic names like 'server_slug', 'profile_id', 'tool_name'. While clear in context, they do not hint at whether the input should be a UUID, slug, or name. Recommend suffixing parameter names with the type: 'server_slug' (already clear), but 'profile_id' should clarify format (e.g. 'profile_id: UUID' in description).