Loading ToolBench
The Unity Docs MCP server has 4 tools, all properly registered with schemas and descriptions. However, descriptions are minimal (10-24 chars), parameter descriptions lack critical constraints and context, and output schemas are undocumented. Tool names follow action-verb conventions (get_, search_, list_, suggest_) but descriptions do not explain WHEN to use each tool, what they return, or dependencies. The server is read-only (low risk), but LLM tool selection will be hampered by sparse descriptions. No error recovery guidance, no pagination hints despite search results, no per-param validation rules visible.
Get Unity API documentation for a specific class or method
List supported Unity versions
Search Unity documentation
Get suggestions for Unity class names
Tool descriptions are too short (10-24 chars) and lack actionable context. Each description should state WHAT, WHEN to use, and WHAT is returned. LLMs cannot reliably select between search_unity_docs and get_unity_api_doc with only 'Search Unity documentation' vs 'Get Unity API documentation...'
Parameter descriptions lack constraints and format guidance. 'version' is described as 'optional - defaults to latest' but does not specify format (e.g., '2023.1', '6.0.0'), how to obtain valid versions, or what happens on invalid input. 'query' and 'partial_name' lack examples of expected input length, character restrictions, or how fuzzy matching works.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 19 | - | v1 |
Output schemas are not documented. Callers cannot know the structure of results from get_unity_api_doc (is it markdown? HTML? JSON? structured object?), search_unity_docs (array of objects? pagination?), list_unity_versions (array of strings? objects with metadata?), or suggest_unity_classes. Without documented outputs, LLMs cannot plan downstream processing.
No error handling guidance visible. Code shows validation for class_name and version (e.g., 'Unsupported Unity version') but error messages lack recovery hints. E.g., if version is invalid, the error should suggest 'Call list_unity_versions() to see available versions.'
search_unity_docs likely returns multiple results but no pagination (limit, offset, total_count, next_cursor) is visible in the input schema. If results can be large, pagination is critical to prevent context window exhaustion.
Tool selection ambiguity: get_unity_api_doc accepts class_name + optional method_name, while search_unity_docs accepts a free-form query. LLMs will struggle to know when to use each. Description should clarify: 'Use get_unity_api_doc when you know the exact class name; use search_unity_docs for exploratory queries or when you only know keywords.'