Skip to main content
Glama
AmirUpSkill

MCP Server for Up-to-Date Library Documentation

by AmirUpSkill

MCP Server for Up-to-Date Library Documentation

Python Version License Built with uv

This project implements a Model Context Protocol (MCP) server in Python. Its primary function is to provide Large Language Models (LLMs) like Anthropic's Claude with real-time access to the latest documentation for specified Python libraries (Langchain, LlamaIndex, OpenAI) before they generate code suggestions.

Problem Solved

LLMs often possess knowledge based on their training data cutoffs. This can lead to outdated code suggestions, especially for rapidly evolving libraries common in the AI/ML space. This MCP server addresses this challenge by acting as a tool that allows the LLM to dynamically fetch and incorporate the most current documentation snippets into its context before responding to coding queries.

Related MCP server: Context7 MCP

Features

  • MCP Standard: Implements the Model Context Protocol for seamless integration with compatible clients (e.g., Claude Desktop, Claude Code).

  • get_docs Tool: Exposes a specific tool that searches official documentation sites.

  • Targeted Search: Uses the Serper API to perform site-specific Google searches, ensuring results come directly from the official docs for:

    • Langchain (python.langchain.com/docs)

    • LlamaIndex (docs.llamaindex.ai/en/stable)

    • OpenAI (platform.openai.com/docs)

  • Content Fetching: Retrieves and parses the text content from the top search results using httpx and BeautifulSoup.

  • Modern Tooling: Built with Python 3.11+, asyncio, FastMCP, and managed using the uv package manager.

Architecture Overview

This server functions as a specialized "toolbox" within the MCP ecosystem:

  1. An MCP Host (e.g., Claude Desktop, IDE with Claude Code) initiates a request requiring coding assistance for a supported library.

  2. The MCP Client within the Host connects to this running MCP Server.

  3. The LLM, recognizing the need for potentially up-to-date information, decides to use the get_docs tool provided by this server.

  4. The Client invokes the get_docs tool on this server, passing the user's query and the target library.

  5. This MCP Server constructs a site-specific search query (e.g., site:python.langchain.com/docs <user_query>).

  6. It queries the Serper API to get the top documentation page links.

  7. It fetches the content of these pages using httpx and extracts the relevant text using BeautifulSoup.

  8. The extracted text (context) is returned to the MCP Client/Host.

  9. The LLM uses this fresh context alongside the original prompt to generate a more accurate and up-to-date response/code suggestion.

Prerequisites

  • Python 3.11+

  • uv Package Manager: Install from Astral.sh.

  • Serper API Key: Obtain a free or paid key from serper.dev.

  • Node.js/npx: Required only if you plan to use the MCP Inspector for debugging.

Installation & Setup

  1. Clone the Repository (if applicable):

    git clone <your-repository-url>
    cd <your-repository-name>
  2. Initialize Project (if starting fresh):

    # If you haven't cloned a repo with pyproject.toml
    uv init mcp-server
    cd mcp-server
  3. Create and Activate Virtual Environment:

    uv venv
    # Activate (Linux/macOS):
    source .venv/bin/activate
    # Activate (Windows PowerShell):
    . \.venv\Scripts\Activate.ps1
    # Activate (Windows Cmd):
    .\.venv\Scripts\activate.bat
  4. Install Dependencies:

    uv add "mcp[cli]" httpx python-dotenv bs4
    # Or, if dependencies are listed in pyproject.toml:
    # uv sync

Configuration

  1. Create a file named .env in the root directory of the project.

  2. Add your Serper API key to this file:

    SERPER_API_KEY=your_actual_serper_api_key_here

    (The .gitignore file is already configured to prevent committing this file)

Usage

  1. Run the MCP Server: Make sure your virtual environment is activated.

    uv run main.py

    The server will start and listen for connections via standard input/output (stdio), as configured in main.py.

  2. Integrate with MCP Clients:

    • Claude Desktop:

      • Go to Settings > Developer > Edit Configuration.

      • Add an entry under mcpServers. You'll need to provide the full path to your uv executable and specify the command arguments.

      • Example structure (adjust paths accordingly):

        {
          "mcpServers": [
            {
              "name": "docs-helper", // Or any name you prefer
              "command": [
                "/full/path/to/your/.venv/bin/python", // Or full path to uv binary
                "-m", // If using python -m uv ...
                "uv",
                "run",
                "main.py"
               ],
              "workingDirectory": "/full/path/to/your/mcp-server/project"
            }
          ]
        }
      • Restart Claude Desktop. A tool hammer icon should appear.

    • Claude Code (CLI):

      • Use the claude mcp add command interactively or with flags.

      • Example interactive session prompts:

        • Server Name: documentation-fetcher (or your choice)

        • Project Type: local

        • Command: Specify the full path to uv and arguments, similar to Claude Desktop (e.g., /full/path/to/uv run main.py within the project directory).

        • Working Directory: /full/path/to/your/mcp-server/project

      • Use claude mcp list to verify.

      • Run claude - the tool should be listed.

    • Refer to the official Anthropic MCP documentation for the most up-to-date client configuration details.

Development & Debugging

The MCP Inspector is a valuable tool for testing your server's capabilities without needing a full client integration.

  1. Ensure Node.js and npx are installed.

  2. Run the inspector, pointing it to your server's run command:

    # Ensure your .venv is activated first
    npx @model-context-protocol/inspector "uv run main.py"
  3. Open your web browser to http://localhost:5173.

  4. Connect to the server via the Inspector interface.

  5. Navigate to the "Tools" section, select get_docs, provide test values for query and library, and click "Run Tool" to see the output.

License

This project is licensed under the MIT License - see the LICENSE file for details. (You'll need to add a LICENSE file with the MIT license text if you choose this)


Available Tools

1 tool
get_docsA

Search the latest docs for a given query and library. 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: Text from the docs

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
libraryYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden for behavioral disclosure. It notes that the tool searches 'latest docs' and returns text, implying a read-only operation, but does not mention potential network dependency, error cases, or any side effects. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a one-sentence purpose statement followed by clear Args/Returns sections. Every sentence adds value, and information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter tool with no output schema, the description provides sufficient context: purpose, supported libraries, parameter guidance, and return type. It lacks explicit error handling or formatting details, but these are not critical for this simple search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully explain the parameters. It does so effectively with an Args section providing both meaning and examples for 'query' and 'library', plus listing supported library values in the main description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Search the latest docs for a given query and library.' It specifies the resource (docs), the verb (search), and scope (latest), and distinguishes from sibling Chroma DB tools by focusing on doc search for specific libraries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool (when searching docs for langchain, openai, or llama-index) through the list of supported libraries. However, it lacks explicit exclusions or alternative tool references, so it doesn't fully meet the 'when-not/alternatives' criterion.

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.

  1. 1 tool updatev0.1.0
    • First observedget_docs

TDQS

A3.9/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or ambiguity between tools.

Naming Consistency5/5

Single tool named 'get_docs' follows a clear verb_noun pattern, which is consistent within the set of one.

Tool Count3/5

A single tool for a documentation server is borderline. While a search tool could cover the domain, three distinct libraries suggest at least a tool per library or a discovery tool would be more appropriate.

Completeness2/5

The server only offers a generic search, lacking any way to list supported libraries, get specific doc structures, or navigate. Agents cannot discover the available actions beyond the single query.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers