Loading ToolBench
MCP server for integrating with YApi API documentation platform, providing tools to retrieve API interface details and documentation
Single tool 'get_api_desc' has a clear verb-noun name and basic schema, but critical gaps undermine quality. Description is adequate (85 chars) but lacks context on when/why to use it. Parameter 'apiId' has a description but no type constraints (min/max length, format). Output is unstructured JSON text rather than typed fields, LLM must parse Chinese-language keys and nested structure. No error handling guidance; catch-all returns raw error as text. No pagination, no result limits documented. Tool does one thing (read-only), but implementation details leak into response formatting.
获取YApi中特定接口的详细信息
Output schema not documented. Tool returns unstructured JSON text with Chinese keys (基本信息, 请求参数, etc.) instead of typed fields. LLM must parse and reason about nested structure; no field descriptions provided.
Parameter 'apiId' lacks format constraints. No min/max length, no regex pattern, no guidance on valid ID format (numeric? alphanumeric?). Description mentions example '/project/1/interface/api/66' but does not state whether ID is always numeric or can contain other characters.
Error handling returns raw error object as text ('获取API接口出错: [object Object]'). No recovery guidance, no categorization (retryable vs fatal), no actionable next steps for LLM.
Tool description does not state what data is returned or when to call it instead of other discovery tools. Missing context on prerequisites (e.g., 'Requires valid YApi project ID') and use cases.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
No pagination or result limits. If YApi interface returns large nested structures (e.g., 1000+ request parameters), response could exhaust context window. No documented cap on response size.