Loading ToolBench
ModelContextProtocol implementation for Hyperf framework, providing MCP server capabilities with PHP/Swoole backend
This MCP server exposes 7 tools covering protocol fundamentals (initialize, list tools/resources/prompts) and execution (call tools, read resources, get prompts). Tool definitions are present with names and descriptions, but exhibit significant quality gaps: descriptions are generic and lack context for LLM decision-making; parameter descriptions are minimal or absent; output schemas are not documented; no error recovery guidance. The 'tools/call' tool is particularly weak, it accepts arbitrary 'arguments' as an untyped object with no parameter descriptions, no validation hints, and no error handling guidance. Naming is adequate (verb-first convention applied) but descriptions frequently fall below the 50-char minimum for LLM optimization. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear safety distinctions (tools/list vs tools/call). Security is not addressed, no visible rate limiting, audit logging, or permission gates. Schemas rely on reflection-based generation for user-defined tools, but the core MCP protocol tools themselves lack rigorous schema documentation.
Initialize the MCP protocol connection and retrieve server capabilities
Get a specific prompt template with provided arguments
List all available prompts exposed by the MCP server
List all available resources exposed by the MCP server
Read the content of a specific resource by URI
Call a registered MCP tool with provided arguments and receive structured text response
List all available tools registered with the MCP server
Critical: 'arguments' and generic object parameters lack schema definition. tools/call accepts 'arguments' as untyped object with no nested properties, constraints, or validation rules. Prompts/get similarly accepts untyped 'arguments'. LLMs cannot infer valid keys or produce correct input without explicit schema.
Critical: Output schemas are not documented for ANY tool. LLMs cannot plan downstream actions or extract needed data without knowing response structure. 'tools/list' output structure, 'resources/read' encoding handling, 'prompts/get' response format all undocumented.
High: No error recovery guidance. All tools lack actionable error messages. E.g., tools/call offers no guidance if tool name is invalid, if arguments don't match schema, or if execution fails. resources/read offers no guidance on 404s, timeouts, or encoding errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
High: Descriptions are below optimal length for LLM reasoning. Descriptions lack WHEN/WHY context and dependency hints.
High: No tool annotations present. tools/list, resources/list, resources/read, prompts/list, and initialize are READ_ONLY; tools/call is destructive. readOnlyHint and destructiveHint annotations would clarify safety and retry semantics for agents.
Medium: Parameter descriptions are minimal (30-33 chars for URI, name, arguments), below the 72-char baseline. They lack format constraints, examples, or validation rules. E.g., 'uri' offers no guidance on scheme, encoding, or length limits.
Medium: Ambiguous parameter naming in tools/call and prompts/get. Both accept generic 'arguments' object. Per naming pattern, parameters should be suffixed with type (arguments_dict, arguments_json) or named by domain (prompt_args, tool_args) to avoid confusion.