Skip to main content
Glama
NirojShah

mcp-npm-package-documentation

by NirojShah

MCP Node Documentation

A Model Context Protocol (MCP) server that retrieves documentation for any npm package by automatically discovering its GitHub repository and returning its README.md.

The server is built using the official @modelcontextprotocol/server SDK and communicates over STDIO, making it compatible with MCP clients such as Claude Desktop, the MCP Inspector, and other MCP-compatible applications.


Features

  • Fetches package information directly from the npm registry.

  • Automatically detects the GitHub repository associated with an npm package.

  • Downloads the project's README from GitHub.

  • Supports repositories using either:

    • main

    • master

  • Supports common README filename variations:

    • README.md

    • Readme.md

    • readme.md

  • Uses request timeouts to avoid hanging requests.

  • Implements clean separation between:

    • MCP Server

    • Service Layer

    • HTTP Layer

  • Fully written in TypeScript.

  • Compatible with MCP 2.x.


How It Works

          User / MCP Client
                  │
                  ▼
        MCP Tool Invocation
                  │
                  ▼
        npm-package-documentation
                  │
                  ▼
       Fetch npm Registry Metadata
                  │
                  ▼
      Extract GitHub Repository URL
                  │
                  ▼
        Download README.md
                  │
                  ▼
        Return README as Response

Project Structure

mcp-node-documentation
│
├── src
│   ├── index.ts
│   │
│   └── service
│       ├── data.model.ts
│       ├── fetch.api.ts
│       ├── service.ts
│       └── service.implementation.ts
│
├── package.json
├── tsconfig.json
├── .gitignore
└── README.md

Folder Explanation

src/index.ts

Entry point of the application.

Responsibilities:

  • Creates the MCP Server.

  • Registers the tool.

  • Connects using StdioServerTransport.

  • Handles tool requests.

  • Returns documentation to the MCP client.

Registered Tool:

npm-package-documentation

Input:

{
    "packageName": "express"
}

Output:

Contents of README.md

Related MCP server: NPM Context Agent MCP

src/service/service.ts

Defines the service interface.

interface Service {
    getRepoInfo(packageName: string): Promise<RepoInfo>;
    getDocumentation(user: string, repo: string): Promise<DocumentationResponse>;
}

This abstraction allows multiple implementations in the future.


src/service/service.implementation.ts

Contains all business logic.

Responsibilities:

1. Fetch npm package metadata

Example:

https://registry.npmjs.org/express

Extracts

{
    "repository": {
        "url": "git+https://github.com/expressjs/express.git"
    }
}

Converts it into

user = expressjs
repo = express

2. Fetch GitHub README

It searches multiple possible locations.

Examples:

main/README.md
master/README.md
main/readme.md
master/readme.md
main/Readme.md
master/Readme.md

The first successful request is returned using

Promise.any(...)

src/service/fetch.api.ts

Wrapper around the native fetch() API.

Features:

  • Timeout support

  • AbortController

  • Error handling

  • Automatic cleanup

Instead of repeatedly writing

fetch(...)

the project uses

fetchApi.fetch(...)

which provides consistent behavior.


src/service/data.model.ts

Contains project models.

export interface RepoInfo {
    user: string;
    repo: string;
}

and

export type DocumentationResponse = {
    CONTENT: string;
}

Tool Definition

Tool Name

npm-package-documentation

Input Schema

{
    "packageName": "string"
}

Example

{
    "packageName": "react"
}

Response

Entire README.md content

Request Flow

User

↓

MCP Tool

↓

getRepoInfo()

↓

npm Registry API

↓

GitHub Repository

↓

getDocumentation()

↓

raw.githubusercontent.com

↓

README.md

↓

MCP Response

Installation

Clone the repository.

git clone https://github.com/<your-username>/mcp-node-documentation.git

Move into the project.

cd mcp-node-documentation

Install dependencies.

npm install

Build

npm run build

Compiled JavaScript will be generated inside

dist/

Development

Run in watch mode.

npm run dev

Production

npm start

Run MCP Inspector

npm run local

This launches the official MCP Inspector.

You can invoke the tool directly from the Inspector UI.


Example Tool Call

Input

{
    "packageName": "express"
}

Processing

↓

Fetch npm registry

↓

Extract repository

↓

Fetch README

↓

Return documentation

Output

# Express

Fast, unopinionated, minimalist web framework...

APIs Used

npm Registry

https://registry.npmjs.org/<package-name>

Example

https://registry.npmjs.org/react

Used for discovering the GitHub repository.


GitHub Raw Content

https://raw.githubusercontent.com/<user>/<repo>/<branch>/README.md

Example

https://raw.githubusercontent.com/facebook/react/main/README.md

Used for retrieving documentation.


Error Handling

The project gracefully handles:

  • Invalid package names

  • Missing repositories

  • Non-GitHub repositories

  • Missing README files

  • Network failures

  • Timeout errors

  • Invalid GitHub URLs

Errors are returned as plain text responses to the MCP client.


Dependencies

Runtime

Package

Purpose

@modelcontextprotocol/server

MCP server implementation

zod

Input validation


Development

Package

Purpose

typescript

TypeScript compiler

tsx

Execute TypeScript directly

@types/node

Node.js type definitions


Design Decisions

The project follows a layered architecture.

MCP Server

↓

Service Layer

↓

HTTP Layer

↓

External APIs

Benefits:

  • Easy to maintain

  • Easy to test

  • Easy to extend

  • Separation of concerns

  • Reusable HTTP logic


Future Improvements

Potential enhancements include:

  • Support GitLab repositories.

  • Support Bitbucket repositories.

  • Cache README responses.

  • Add configurable request timeouts.

  • Return additional package metadata (version, description, homepage, author).

  • Support documentation files other than README (e.g., docs/, CONTRIBUTING.md, CHANGELOG.md).

  • Support branch detection via the GitHub API instead of assuming main or master.

  • Add unit and integration tests.

  • Add logging with configurable log levels.

  • Publish the MCP server as an npm package.

  • Containerize with Docker.

  • Add CI/CD workflows using GitHub Actions.


Requirements

  • Node.js 20+

  • npm

  • TypeScript


License

This project is licensed under the ISC License.


Author

Developed as a simple MCP server that demonstrates how to integrate the npm Registry API with GitHub's raw content service to provide package documentation on demand.

Available Tools

1 tool
npm-package-documentationNPM Package DocumentationD

Documentation for the npm package.

ParametersJSON Schema
NameRequiredDescriptionDefault
packageNameYesThe name of the npm package to get documentation for.

TDQS

D1.9/5.0
Behavior1/5

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

With no annotations, the description carries the full burden of disclosing behavior. It fails to mention whether the tool fetches live data, returns static text, requires network access, or has side effects. The description is completely silent on any behavioral traits.

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

Conciseness2/5

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

The description is extremely brief, but brevity here is under-specification rather than conciseness. It does not front-load useful information; the single sentence is too vague to help an agent understand purpose or usage, so it does not earn its place as meaningful guidance.

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

Completeness1/5

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

Given the simple tool (one parameter), the description still fails to convey what output or result the agent should expect. With no output schema present, the description must explain return values, but it does not. This makes the tool effectively opaque.

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%: the only parameter, 'packageName', is fully described as 'The name of the npm package to get documentation for.' The tool description adds nothing extra, but the baseline for high schema coverage is 3, and the schema already provides adequate semantic clarity for the parameter.

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

Purpose2/5

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

The description 'Documentation for the npm package.' essentially restates the tool name and title without specifying an action (e.g., retrieve, fetch, list). It does not distinguish the tool from any other potential npm-related utilities, making it a tautological rather than informative explanation.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool, what problem it solves, or any alternatives. Since no sibling tools or context are provided, the description gives no indication of appropriate usage scenarios, leaving the agent without direction.

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 updatev1.0.0
    • First observednpm-package-documentation

TDQS

C2.6/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion between tools. The tool's purpose is clearly tied to the server's domain.

Naming Consistency5/5

The single tool name 'npm-package-documentation' is descriptive and consistent. No competing patterns exist, so naming is effectively coherent.

Tool Count3/5

The tool count is at the thin edge—one tool can fulfill a very specific purpose, but it feels minimal for a server. It is borderline but acceptable.

Completeness4/5

For a documentation-only server, the single tool may cover the main use case, but the vague description leaves potential gaps (e.g., versioning, search) unaddressed.

Maintenance

ActivitySlowing
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    Provides comprehensive contextual information about npm packages including README files, versions, dependencies, download statistics, and search functionality. Enables users to explore and analyze npm packages through natural language queries with intelligent GitHub README fetching and branch fallback.
    9
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Intelligently detects package managers and provides unified access to documentation and information across 15+ package ecosystems including npm, PyPI, and others. Automatically routes requests to appropriate package-specific MCP servers for README retrieval, package information, and cross-ecosystem package search.
    14
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Provides intelligent, version-aware access to npm library documentation. Supports semantic search, API validation, and version comparison to assist developers in using libraries correctly.
    2
    MIT