Loading ToolBench
expo-docs-mcp demonstrates significant gaps in definition quality. While all 5 tools have basic descriptions and parameter schemas visible in test-server.js and src/index.ts, they lack the rigor expected of production-grade tools. Tool descriptions are generic (40-80 chars), parameter descriptions are minimal or absent, output schemas are entirely undocumented, and there is no evidence of error handling guidance. The server treats documentation as a checkbox rather than an LLM optimization problem. No tool descriptions explain WHEN to use the tool vs. alternatives, WHAT the return structure looks like, or HOW to chain calls. Parameter descriptions are sparse (e.g., 'path within the documentation' with no format guidance). No error recovery paths are documented. The tool naming is verb-first and reasonable (search_, get_, list_), but that alone cannot overcome missing descriptions and undocumented outputs.
Get API reference for a specific Expo SDK module
Get the full content of a specific Expo documentation page
Get quick start guide for Expo
List all available documentation sections and topics
Search through Expo documentation
Output schemas entirely undocumented. No tool description explains what fields the response contains, their types, or which can be chained to other tools. LLMs cannot plan multi-step calls or extract structured data from responses.
Parameter descriptions are minimal, generic, or missing. 'path' in get_expo_doc_content says 'Path within the documentation (e.g., guides/routing)' but provides no guidance on format (slash-separated? dot-notation?), validation rules, or what happens if the path doesn't exist. 'version' appears in multiple tools with identical vague descriptions ('SDK version (e.g., latest, v51.0.0, v50.0.0)') but never explains if 'latest' is a reserved keyword, what versions are available, or how to discover them.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
Tool descriptions lack context and selection guidance. 'Search through Expo documentation' (48 chars) tells the LLM WHAT but not WHEN to use it vs. list_expo_sections, how results are ranked, whether it supports regex or phrase matching, or how many results are returned. The descriptions do not answer: What does it return? Is this the right tool or is there a better one? What happens on no results?
get_expo_doc_content has no required parameters defined (required: []). Both 'url' and 'path' are optional with minimal descriptions. This creates ambiguity: must the caller provide one? Both? Can they be omitted? The schema forces the LLM to guess. Combined with no output schema, the LLM cannot know if it should expect HTML, markdown, or structured data.
No error handling or recovery guidance documented. Tools have no error classification (retryable vs. user-fixable vs. fatal), no recovery suggestions, and no handling for edge cases. What happens if a version doesn't exist? If a module is not found? If search returns no results? The LLM has no guidance.
Parameter constraints not formally declared. 'section' has an enum (home, guides, eas, reference, learn, versions) but the description does not mention it or explain what each section contains. 'platform' in get_expo_quick_start has an enum but no description of what each platform means or what 'all' includes. Enums must be redundantly stated in descriptions for LLM clarity.
No pagination or result limits documented. search_expo_docs provides no limit or page parameters and no description of max results. LLMs cannot predict whether results will fit in context or if they need to call a second time. The baseline pattern expects limit/offset and a total count or next_cursor.