Loading ToolBench
An MCP server built in Go with configurable tools, OAuth/JWT authentication, and HTTP/stdio transport support
mcp-forge exposes 2 tools with minimal definitions. Both tools have brief descriptions (under 50 chars) and basic input schemas. The hello_world tool has a well-typed string parameter with a description, but the whoami tool accepts no parameters and provides no guidance on what it returns. Tool definitions are directly visible in internal/tools/ but lack production-grade refinement: no return type documentation, no error handling guidance, no recovery patterns, and no tool annotations (readOnlyHint/destructiveHint). The server is transport-agnostic (HTTP|STDIO capable) and uses mark3labs/mcp-go framework, but tool quality lags significantly behind A/B-tier baselines.
Say hello to someone
Expose information about the user
Tool descriptions are too brief (<50 chars). 'Say hello to someone' and 'Expose information about the user' lack context on WHEN to use each tool, what they return, and any prerequisites.
No output/return schema documented for any tool. The hello_world handler returns TextContent, and whoami returns a JWT-based response, but neither tool definition states what fields the LLM should expect in the response. Without documented return types, agents cannot plan downstream actions or parse results reliably.
whoami tool has zero input parameters documented but the implementation reads from request.Header (a JWT forwarded header). If the JWT is missing, the tool returns an error, but the LLM has no indication it should provide or understand this dependency. The tool description does not explain that it requires JWT authentication or when to call it.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
No error handling guidance. Both tools return TextContent errors (e.g., 'Error: name parameter is required' in hello_world, 'Error: JWT is empty' in whoami), but these are raw strings, not structured error objects. Errors do not tell the LLM whether to retry, call a different tool, or ask the user.
No tool annotations present. Neither tool declares readOnlyHint, destructiveHint, or idempotentHint. Per the current MCP spec (2026-07-28), these annotations help agents reason about safety and retry behavior. Both tools are marked Risk=READ_ONLY in metadata, but this is not reflected in the tool definition itself.
Tool naming lacks verb clarity. 'hello_world' is idiomatic for 'hello world' demo code, not a user-facing action. 'whoami' mimics Unix convention but does not follow the verb_noun pattern (e.g., 'get_user_info', 'describe_current_user'). LLMs may conflate 'whoami' with 'who_am_i' or struggle to infer when to call it vs. other identity tools.