Library Docs MCP Server
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., "@Library Docs MCP Serverfind the latest documentation for Langchain tool calling"
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.
Library Docs MCP Server
This is an MCP (Model Context Protocol) server that allows you to search and fetch documentation for popular libraries like Langchain, Llama-Index, MCP, and OpenAI using the Serper API.
Features
Search library documentation using a natural language query.
Supports Langchain, Llama-Index, MCP, and OpenAI (Update the code to add other libraries).
Uses the
Serper APIto perform site-specific searches.Parses and returns the documentation using
BeautifulSoup.Provides updated documentation – useful for LLM models with knowledge cut-off dates.
Why Use This Server with LLMs?
Many LLM models, including those used in Claude Desktop and similar platforms, have a knowledge cut-off date and may not have access to the latest library documentation. This MCP server solves that problem by:
Fetching real-time documentation from official sources.
Providing up-to-date information for development and troubleshooting.
Improving the accuracy and relevance of responses when working with new library updates.
Setting Up with Claude Desktop
To use this server with Claude Desktop, update the claude_desktop_config.json file with the following configuration:
{
"mcpServers": {
"docs-mcp-server": {
"command": "C:\\Users\\Vikram\\.local\\bin\\uv.exe",
"args": [
"run",
"--with",
"mcp[cli]",
"mcp",
"run",
"F:\\My Projects\\AI\\docs-mcp-server\\server.py"
]
}
}
}Available Tools
1 toolget_docsB
Search the docs for a given query and library.
Supports langchain, llama-index, mcp, and openai.
Args:
query: The query to search for (e.g. "Chroma DB")
library: The library to search in (e.g. "langchain")
Returns:
Text from the docs
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| library | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the action ('search') and returns 'Text from the docs,' but fails to disclose key behavioral traits such as search scope (e.g., full-text, title-only), result limits, error handling, or authentication needs. This leaves significant gaps for an agent to understand the tool's behavior.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a concise list of supported libraries and clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and well-structured.
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 the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is minimally adequate. It covers the purpose and parameters but lacks details on behavioral aspects like search behavior or output format. Without annotations or output schema, more context on how results are returned would improve completeness.
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?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'query' is for searching (e.g., 'Chroma DB') and 'library' specifies the target (e.g., 'langchain'), including a list of supported libraries. This compensates well for the schema's lack of descriptions, though it could provide more detail on parameter constraints.
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 clearly states the tool's purpose: 'Search the docs for a given query and library.' It specifies the verb ('search') and resource ('docs'), and mentions the supported libraries. However, without sibling tools, it cannot differentiate from alternatives, so it doesn't reach a perfect score of 5.
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 supported libraries ('langchain, llama-index, mcp, and openai'), which suggests when to use it based on library compatibility. However, it lacks explicit guidance on when not to use it or alternatives, and there are no sibling tools to compare against, so the guidance is limited to implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'get_docs' has a clear, distinct purpose of searching documentation for specified libraries.
The single tool name 'get_docs' follows a clear verb_noun pattern. With only one tool, naming consistency is inherently perfect as there are no other tools to compare against.
A single tool is insufficient for a documentation search server. While the tool covers basic search functionality, the server lacks tools for browsing documentation structure, getting library metadata, or handling multiple queries efficiently, making the tool count too low for the apparent scope.
The tool surface is severely incomplete for a documentation server. There are significant gaps: no ability to list available libraries, browse documentation hierarchies, get version-specific docs, or handle pagination/search refinement. The single search tool provides only basic functionality without supporting common documentation workflows.
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
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Real-time web search, reasoning, and research through Perplexity's API
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
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/MCP-Mirror/vikramdse_docs-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server