Provides tools to search and retrieve relevant documentation excerpts from LangChain's official docs, enabling up-to-date answers about LangChain usage.
Provides tools to search and retrieve relevant documentation excerpts from OpenAI's official docs, enabling up-to-date answers about OpenAI APIs and features.
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., "@Docs MCP Server Explain how to use LangChain with chat models, using live 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.
An MCP (Model Context Protocol) server that gives an LLM host (Claude Desktop, an IDE, etc.) a tool for pulling live documentation, instead of relying on the model's training data. Searches are scoped to a library's official docs site, fetched pages are chunked and embedded into a local vector store, and the tool returns only the most relevant excerpts — not raw scraped HTML — for the query.
LLM host (e.g. Claude Desktop)
│ calls get_docs(query, library) over MCP (stdio)
▼
main.py
│ 1. site-scoped Google search via Serper API
│ 2. fetches matching pages concurrently (httpx + asyncio.gather)
│ 3. strips HTML → plain text (BeautifulSoup)
▼
rag.py
│ 4. chunks each page (langchain-text-splitters)
│ 5. embeds + upserts chunks into a local Chroma collection,
│ scoped by library, keyed by URL (idempotent — re-fetching
│ a page doesn't duplicate it)
│ 6. queries the collection for the top-k chunks most relevant
│ to the original query
▼
Returns the top-k excerpts (with source URLs) back to the LLM hostEmbeddings run locally via Chroma's bundled model — no external embedding API key required.
Related MCP server: Context7 MCP Clone
File | Responsibility |
MCP server entry point; defines the | |
Chunking, embedding, and retrieval against a local Chroma vector store | |
Minimal FastAPI dashboard for exercising | |
pytest suite; all HTTP calls mocked via | |
Lint ( |
uv sync --all-groups
cp .env.example .env # then add your SERPER_API_KEYuv run main.pyThis starts the server over stdio — it's meant to be launched by an MCP host, not run standalone for interactive use (see below).
To try the tool from a browser instead of an MCP host:
uv run uvicorn web:app --reloadThen open http://127.0.0.1:8000.
Edit your Claude Desktop config (claude_desktop_config.json):
{
"mcpServers": {
"docs": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/THIS/PROJECT",
"run",
"main.py"
]
}
}
}Restart Claude Desktop, then ask something like "how do I use Chroma DB
with LangChain?" — Claude will call get_docs and answer from the live
docs instead of its training data.
Currently langchain, llama-index, and openai — see DOCS_URLS in
main.py. Add your own by adding an entry mapping a library
name to its docs site.
uv run pytest -v
uv run ruff check .MIT — see LICENSE.
Search the latest docs for a given query and library, index the results
into a local RAG store, and return the most relevant excerpts.
Supports langchain, openai, and llama-index.
Args:
query: The query to search for (e.g. "Chroma DB")
library: The library to search in (e.g. "langchain")
Returns:
The most relevant text excerpts from the docs, with source URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| library | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses the non-obvious side-effect of indexing results into a local RAG store — a persistent write behavior an agent would not infer from the tool's name or schema. It also states the return format (text excerpts with source URLs). It does not cover potential rate limits, network/auth requirements, or index persistence duration, but the most critical non-obvious behavior is explicitly surfaced.
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?
The description is front-loaded with the primary purpose sentence, followed by the supported-libraries line and a compact Args/Returns section. Every sentence earns its place and nothing is redundant with the schema. It is a touch more verbose than strictly necessary given the two simple parameters, but the structure is clean and scannable.
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?
For a simple 2-parameter search tool with no output schema, no annotations, and no siblings, the description covers everything an agent needs: what it does, which libraries it supports, how to fill both parameters (with examples), and the shape of its return value. Nothing material is missing to call it correctly, making it complete relative to the tool's 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?
Schema description coverage is 0% — the schema fields carry only bare titles ('Query', 'Library'). The description fully compensates with per-parameter explanations and concrete examples ('Chroma DB', 'langchain'), and the supported-library list in the body constrains the library param's valid values. This adds real meaning beyond the empty schema and gives an agent enough to invoke it correctly.
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 states a specific combination of actions — searching the latest docs for a query and library, indexing into a local RAG store, and returning most relevant excerpts — which crisply defines the tool's resource and outcome. It also enumerates the supported libraries (langchain, openai, llama-index), removing any ambiguity about scope. With no siblings to differentiate against, the purpose is fully self-contained and clear.
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?
The description implies usage by listing the three supported libraries, which tells an agent which libraries this tool can search. However, there is no explicit when-to-use guidance, no exclusions, and no mention of conditions where a different tool or approach would be preferable. Since no sibling tools exist, the guidance burden is lower, but the description still never states under what circumstances the agent should reach for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0get_docsWith only one tool, there is no possibility of confusing tools with overlapping purposes. The single tool's purpose is clearly defined as searching documentation and returning relevant excerpts.
The tool name 'get_docs' follows a clear verb_noun convention. Since there's only one tool, naming consistency is trivially maintained.
A single tool feels thin for a general-purpose docs server, especially since only three libraries are explicitly supported. Borderline for a narrow utility, but it could benefit from additional operations like listing supported libraries or retrieving raw document content.
For the stated purpose—searching documentation for a query and library—the tool fully covers the operation. There are no obvious missing features within the described scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Versioned documentation registry and semantic search for AI tools and coding assistants.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MukeshW11/mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server