MCP server providing AI agents with accurate, version-aware React Native and Expo documentation
Server provides 9 well-scoped tools with complete input schemas and descriptions. Naming follows verb_noun convention (detect-, search-, get-, validate-, find-, resolve-, semantic-search-, generate-). Descriptions are substantive (100-250 chars typical), explaining WHAT and WHEN. However, output schemas are not documented in the source code provided, only input schemas are visible. Parameter descriptions are present but some lack format/constraint details (e.g., 'cwd' is just 'The current working directory' without guidance on absolute vs relative paths). Error handling and recovery guidance are not evident in the tool definitions. No tool annotations (readOnlyHint, destructiveHint) despite all tools being READ_ONLY.
Detects the React Native, Expo, React Navigation, and Ignite versions in the current project.
Finds code examples for a specific topic using the index
Generates boilerplate code for common React Native patterns like FlatList, navigation screens, forms, API calls, and more. Returns production-ready, type-safe code following best practices.
Get performance and architecture best practices for a library
Get specific documentation with smart chunking and pagination for token efficiency
Resolves a fuzzy library name to exact library ID and available versions
Output schemas not documented. Tool definitions show input schemas but no return type documentation. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns.
Tool annotations missing. All 9 tools are READ_ONLY but lack readOnlyHint annotation in schema. This prevents clients from rendering appropriate UI affordances and agents from understanding safety guarantees.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Lists available documentation topics for a library. Use semantic-search-docs for AI-powered content search.
Performs semantic search across documentation using AI embeddings to find conceptually similar content, even when exact keywords don't match. Returns the most relevant documentation chunks with similarity scores.
Fast validation if a symbol exists, checking node_modules first then docs index
Parameter descriptions lack format/constraint details. 'cwd' parameter appears in 6 tools with minimal guidance ('The current working directory to check'). No indication of absolute vs relative paths, validation rules, or defaults when omitted.
No error handling or recovery guidance in tool definitions. Tools do not document what happens on failure (e.g., library not found, invalid symbol, network timeout). LLMs have no guidance on retry strategy or fallback actions.
Pagination not explicitly documented. 'get-library-docs' accepts 'page' parameter but tool description does not state total page count, whether pages are 0-indexed or 1-indexed, or what happens when page exceeds available content.