rndocs
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@rndocsshow me the FlatList docs"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
rndocs

rndocs is a CLI tool that lets you search and read React Native documentation offline β no browser needed. It downloads the full React Native docs to your machine and gives you instant local search from the terminal.
Key Features
Search the entire React Native docs instantly from your terminal
Read full documentation pages without opening a browser
Works completely offline after the initial sync
Integrates with Claude Code and other AI assistants as an MCP server
Related MCP server: Reacticx MCP
Requirements
Python 3.11 or later
macOS, Linux, or Windows
Installation
pip install rndocsThen download the docs once:
rndocs syncUsage
Search
rndocs search "FlatList"
rndocs search "animation"
rndocs search "handle keyboard"Read a page
rndocs get flatlist
rndocs get animated
rndocs get stylesheetBrowse all pages
rndocs lsRefresh docs
rndocs syncClaude Code Integration
Add to your Claude Code MCP settings:
{
"mcpServers": {
"rndocs": {
"command": "rndocs-mcp"
}
}
}Claude can now search and read React Native docs directly inside your conversations.
Contributing
Contributions are welcome! If you've found a bug, have an idea for an improvement, or want to contribute new features, please open an issue or submit a pull request.
Find this repository useful? :heart:
Support it by joining stargazers for this repository. :star: Also, follow me on GitHub for my next creations! π€©
Available Tools
3 toolsget_react_native_docA
Get the full content of a React Native doc page by its slug.
Args: slug: The doc page slug (e.g. 'flatlist', 'animated', 'getting-started', 'stylesheet') Find slugs using search_react_native_docs first.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses that it retrieves full content, which is a read operation, but lacks details on response format, auth, or limits. Adequate for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise three-sentence structure: purpose then parameter guidance. Front-loaded with main purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter and presence of an output schema, the description covers necessary context: what the tool does, how to use the parameter, and how to get the input (via sibling tool). Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by providing example slugs and directing users to search for slugs. This compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is clearly stated: 'Get the full content of a React Native doc page by its slug.' It uses a specific verb and resource, and distinguishes from sibling tools (list and search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use search_react_native_docs first to find slugs, providing clear usage context. Does not include when-not-to-use, but the guidance is sufficient for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_react_native_docsA
List all available React Native doc pages, optionally filtered by section.
Args: section: Filter by section name (e.g. 'Components', 'APIs', 'Guides'). Leave empty for all.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. Describes the basic behavior (listing, optional filter), but lacks details on potential pagination, performance, or side effects. Adequate for a read-only list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with clear separation into purpose and parameter details. Could be slightly more streamlined, but no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description doesn't need return details. Covers purpose, parameter semantics, and context with sibling tools. Adequate for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds significant value: provides section name examples ('Components', 'APIs', 'Guides') and clarifies default behavior. Fully compensates for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies verb 'list', resource 'React Native doc pages', and optional filter by section. It distinguishes itself from siblings 'get_react_native_doc' and 'search_react_native_docs' as a listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit guidance on the 'section' parameter with examples and default behavior ('Leave empty for all'). Does not explicitly mention when to use vs siblings, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_react_native_docsA
Search React Native documentation by keyword or concept.
Args: query: Search terms (e.g. 'FlatList', 'navigation', 'StyleSheet flex') limit: Maximum number of results to return (default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It only states 'search by keyword or concept' without detailing behavior like search scope, result format, or limitations. Lacks depth for safety and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient two-sentence description with immediate purpose, followed by structured args list. No wasted words, front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple search tool, but lacks details on result format, pagination, or filtering options. Output schema exists but description does not reference it; completeness is minimal but not insufficient given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description provides essential parameter meanings with examples: query described as 'Search terms' with examples, limit explained as 'Maximum number of results' with default. Adds meaningful clarity beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Search' and resource 'React Native documentation', clearly distinguishing from sibling tools 'get_react_native_doc' and 'list_react_native_docs'. It conveys a focused action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings; only implied purpose of searching. Missing context about when to prefer search over direct retrieval or listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
3 tool updates
v0.2.0- First observed
get_react_native_doc - First observed
list_react_native_docs - First observed
search_react_native_docs
TDQS
Each tool has a clearly distinct purpose: retrieving a specific doc by slug, listing all docs (optionally filtered), and searching by keyword. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (get_react_native_doc, list_react_native_docs, search_react_native_docs), with singular/plural matching the operation.
Three tools is appropriate for a focused documentation server. Each tool serves a necessary function without redundancy, and the count is not too small or excessive.
The tool set covers the essential workflow: discover pages (list and search) and retrieve full content (get). No obvious gaps exist for the stated purpose of accessing React Native docs.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Search and read Rust documentation for the standard library and any crate on crates.io
DevDocs.io keyless docs index + entry search + content (Angular, MDN, Rust, etc.).
Get up-to-date, version-specific documentation and code examples from official sources directly inβ¦
Retrieve information from the Medusa documentation to assist you with your Medusa development.
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides comprehensive tools for React Native development, automating project initialization, version management, upgrades, Expo integration, and development workflows through AI assistance.24721MIT
- AlicenseAqualityDmaintenanceProvides documentation and component references for the Reacticx React Native library, including props, code examples, and installation guides. It enables users to search through over 90 components and retrieve setup commands for project dependencies.5132MIT
- AlicenseAqualityCmaintenanceProvides AI agents with accurate, version-aware documentation for React Native, Expo, React Navigation, and Ignite by automatically detecting project dependencies and fetching matching documentation.12MIT
- AlicenseNot gradedqualityCmaintenanceEnables fast, offline search and retrieval of Expo documentation from local .mdx files, with tools for searching, getting content, listing sections, API references, and quick start guides.19117MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AndroidPoet/rndocs'
If you have feedback or need assistance with the MCP directory API, please join our Discord server