Loading ToolBench
Go SDK for AgentCat MCP server integration with support for both mark3labs/mcp-go and official modelcontextprotocol/go-sdk. Provides analytics, session tracking, user identification, sensitive data redaction, and tool call context capture.
AgentCat Go SDK exposes 22 tools with mixed quality. Most tools have basic descriptions (10-50 chars) and input schemas, but lack depth and LLM-optimization. Naming is inconsistent: verb_noun pattern used for some (add_todo, list_todos, get_todo, complete_todo, delete_todo, echo, reverse, count_chars) but many test/utility tools use non-standard names (always_fails, pointer_error, slow_tool, multi_error, big_numbers, structured_no_schema, structured_only, echo_raw). Parameter descriptions are sparse or missing entirely. Output schemas are undocumented. Error handling is minimal. The server appears to be an SDK/framework for building MCP servers rather than a production tool suite, many tools are test fixtures (always_fails, pointer_error, slow_tool, multi_error, echo_raw, big_numbers, structured_no_schema, structured_only, error_test) that should not be scored as real tools. Excluding test fixtures, the core todo tools (add_todo, list_todos, get_todo, complete_todo, delete_todo) and utility tools (echo, reverse, count_chars) show basic competence but lack production polish.
About this todo server
Add a new todo item
Always returns an error result
Returns structuredContent with integers beyond float64 precision
Mark a todo item as completed
Count the number of characters in the input text
Delete a todo item
Test/fixture tools mixed with production tools. Tools like 'always_fails', 'pointer_error', 'slow_tool', 'multi_error', 'echo_raw', 'big_numbers', 'structured_no_schema', 'structured_only' are clearly test fixtures and should not be exposed in a production MCP server. They pollute the tool namespace and confuse agents about what the server actually does.
Missing or trivial descriptions. 'about' tool has no description (0 chars). Many tools have descriptions under 20 chars (e.g., 'ordered_tool': 'A tool whose raw input schema pins its property order'). Descriptions should be 50-200 chars, explaining WHAT the tool does, WHEN to use it, and any prerequisites.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2025-06-18+ | v2 |
Echo back the input text
Echoes the arguments the handler received
Echoes the raw argument bytes the handler received
Always errors — use this to test stack trace capture
Tool that allows agents to report missing capabilities and request additional tools from the server
Get a todo item by ID
List all todo items
Returns an error result built from several text blocks
A tool whose raw input schema pins its property order
Returns an error result with pointer content
Reverse the input text
Takes a measurable amount of time to run
Returns structuredContent without declaring an output schema
Returns structuredContent and no content blocks
Summarize all current todos
Output schemas undocumented. No tool declares what fields it returns or the structure of its response. LLMs cannot plan downstream tool calls or extract data without knowing the output schema. This violates the pattern:tool requirement that 'Document the output schema.'
Parameter descriptions missing or minimal. Most parameters lack descriptions explaining their purpose, format, or constraints. E.g., 'get_todo' has parameter 'id' with description 'ID of the todo item', too generic. Should specify format (UUID? integer? string?), whether it's required, and what happens if not found.
No error handling guidance. Tools like 'always_fails', 'pointer_error', 'multi_error' exist but no tool provides actionable error messages or recovery guidance. Per pattern:recovery-guide, errors must tell the LLM what to do next, not just fail silently.