Loading ToolBench
Model Context Protocol server for YApi integration, enables AI tools like Cursor to interact with YApi API documentation
YApi MCP Server has significant structural issues that prevent confident production use. While all 5 tools are explicitly registered with schemas and descriptions, the quality falls short of production baselines. Naming is mostly clear but descriptions lack depth and constraint guidance. Schemas are present but sparse, many parameters accept free-form strings where enums or patterns should enforce valid values. Output formats are unstructured JSON blobs rather than typed responses. Error handling is minimal and non-actionable. The server accepts YApi connection credentials as environment variables (good), but parameter validation and error recovery guidance are absent. Average per-tool score: 42/100 across 5 tools. This server would require substantial rework before production deployment.
获取YApi中特定接口的详细信息
获取YApi项目下的接口分类列表
列出YApi的项目ID和项目名称
新增或更新YApi中的接口信息
搜索YApi中的接口，支持多个项目和多个关键字的组合搜索
yapi_save_api accepts 18 parameters almost all as strings without enums or format constraints. Parameters like 'status', 'method', 'req_body_type', 'res_body_type' should be enums, not free-form strings. LLM will hallucinate invalid values (e.g. 'PATCH' when only 'GET|POST|PUT|DELETE' are valid, or status 'approved' when only 'done|undone' exist).
yapi_save_api parameter 'req_params', 'req_query', 'req_headers', 'req_body_form', 'req_body_other' are all declared as strings with description '...JSON format array...' but no validation that they are valid JSON. LLM will likely pass malformed JSON. No validation or parsing inside the tool (from code review of server.ts, parsing is not shown).
Output of yapi_get_api_desc returns raw formatted JSON as text without a structured response schema. The response is a free-form nested object passed as JSON string. LLM cannot extract specific fields programmatically for chaining downstream calls. If the next tool needs apiInterface._id or title, the LLM must parse the JSON response.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
yapi_search_apis accepts 'nameKeyword', 'pathKeyword', 'tagKeyword' as free-form strings with 'supports multiple keywords comma separated' description. No guidance on quoting, escaping, or format. LLM will struggle with special characters and multi-word keywords.
yapi_list_projects and yapi_get_categories return no pagination parameters (limit, page, offset) and no documented result structure. If a YApi instance has hundreds of projects or categories, the response could be massive and blow context window. No guidance on result limits.
All tool descriptions are in Chinese. While functional, this creates a language mismatch with English-speaking LLMs and reduces discoverability in English-first environments. Tool names are English; descriptions should be too.
Error handling returns generic 'xxx出错: {error}' (error occurred) responses without actionable recovery guidance. LLM cannot determine if error is retryable, user-fixable, or fatal. Example: if projectId does not exist, error should be 'Project 28 not found. Call yapi_list_projects() to see available projects.'
yapi_save_api has complex conditional logic (catid required for new, id required for update) documented only in descriptions. No formal parameter constraints (e.g. oneOf, allOf) to express mutual dependencies. LLM may pass both catid and id (update mode) or neither (ambiguous).