Skip to main content
Glama
SARAN-KUMAR-S

DOC-Intelligence-MCP-SERVER

by SARAN-KUMAR-S
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

DOC-Intelligence-MCP-SERVER

A Model Context Protocol (MCP) server that enables LLMs (like Claude) to dynamically search, scrape, and query libraries' official documentation using Google Serper and Groq.

Features

  • Google Serper API Integration: Searches documentation sites for up-to-date information.

  • Fast Web Scraping: Extracts page content cleanly using trafilatura.

  • LLM Content Cleaning: Automatically cleans and strips HTML bloat from documentation pages using Groq (llama-3.1-8b-instant).

  • Claude Integration: Instantly works as a tool within Claude Desktop or any other MCP client.

Related MCP server: Library Docs MCP Server

Supported Libraries (Configured Domains)

  • uv (docs.astral.sh/uv)

  • openai (platform.openai.com/docs)

  • langchain (python.langchain.com/docs)

  • llama-index (docs.llamaindex.ai/en/stable)

Setup

1. Requirements

Ensure you have uv installed.

2. Configure Environment Variables

Copy .env.example to .env and fill in your API keys:

cp .env.example .env

Inside .env:

3. Run Locally (Testing)

You can run the test client to verify operations:

uv run client.py

Claude Desktop Integration

To add this tool to your Claude Desktop client, edit your configuration file:

  • Windows Path: %APPDATA%\Claude\claude_desktop_config.json

  • macOS Path: ~/Library/Application Support/Claude/claude_desktop_config.json

Choose one of the integration methods below:

Option 1: Run directly from GitHub (Quickest, no cloning required)

This runs the MCP server directly from GitHub. Add this JSON snippet under "mcpServers":

{
  "mcpServers": {
    "docs-intelligence": {
      "command": "uv",
      "args": [
        "run",
        "https://raw.githubusercontent.com/SARAN-KUMAR-S/DOC-Intelligence-MCP-SERVER/main/mcp_server.py"
      ],
      "env": {
        "SERPER_API_KEY": "YOUR_SERPER_API_KEY",
        "GROQ_API_KEY": "YOUR_GROQ_API_KEY"
      }
    }
  }
}
IMPORTANT

ReplaceYOUR_SERPER_API_KEY and YOUR_GROQ_API_KEY with your actual credentials.

Option 2: Clone and Run Locally (Best for making code changes)

If you cloned the repository locally, create a .env file containing your API keys in the root directory, and configure the path under "mcpServers":

{
  "mcpServers": {
    "docs-intelligence": {
      "command": "uv",
      "args": [
        "--directory",
        "ABSOLUTE_PATH_TO_CLONED_FOLDER",
        "run",
        "mcp_server.py"
      ]
    }
  }
}
NOTE

ReplaceABSOLUTE_PATH_TO_CLONED_FOLDER with the full path where you cloned this repository (e.g. C:\\Users\\Username\\DOC-Intelligence-MCP-SERVER). The local .env file in that folder will be loaded automatically.

Restart Claude Desktop, and the get_docs tool will be ready to use!

Available Tools

1 tool
get_docsA

Search the latest official documentation to answer developer queries. Use this tool whenever the user asks questions about uv, openai, langchain, or llama-index.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe search terms or query (e.g. "How to use publish a package with uv on gitlab")
libraryYesThe specific library/technology to search for.

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Search the latest official documentation' but fails to disclose important traits such as result format, pagination, caching behavior, or error handling. For a search tool, this is a significant gap.

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?

Two sentences, both front-loaded. The first sentence states purpose, the second gives usage guidance. No unnecessary words. Perfectly concise and well-structured.

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

Completeness3/5

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

The tool is simple with two parameters and no output schema. The description covers purpose and when to use, but lacks details on return format, output behavior, or any limitations. Without output schema, the description should hint at what the agent can expect. It falls short, though the core use is conveyed.

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

Parameters3/5

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

Schema description coverage is 100%, with both parameters described in the input schema. The description adds minimal extra meaning beyond the schema—it reiterates the library list and the query's purpose. Baseline is 3 for high coverage; the description does not provide substantial additional semantics.

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 'Search the latest official documentation to answer developer queries,' specifying the verb (search) and resource (latest official documentation). It explicitly lists the four libraries, making the tool's domain unambiguous. No siblings exist, so no differentiation needed.

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 explicitly states when to use the tool: 'Use this tool whenever the user asks questions about uv, openai, langchain, or llama-index.' This provides clear usage context, though it does not mention when not to use or alternatives. Given the absence of sibling tools, this is sufficient.

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
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no risk of ambiguity or overlap.

Naming Consistency5/5

With a single tool, naming is trivially consistent; the name 'get_docs' clearly conveys its purpose.

Tool Count3/5

One tool for a broad domain (multiple libraries) feels minimal; while it can handle many queries, it offers no specialized operations.

Completeness3/5

The server covers basic documentation search, but lacks other functionality like listing sources or performing updates, which may be needed for comprehensive querying.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers