Skip to main content
Glama
ts-docs-mcp

ts-docs-mcp

by xvantz

ts-docs-mcp

An MCP server that gives AI coding agents accurate, version-aware API documentation for any npm package — straight from the source.

⚡ npx ts-docs-mcp — works with Cursor, Claude Code, VS Code Copilot, and any MCP-compatible client.


The Problem

When you ask an AI coding agent (Claude Code, Cursor, Copilot) to write code using an npm package, the model relies on its training data — which is often months or years out of date.

The result:

// ❌ Model hallucinates — Express 4 syntax, but you have Express 5 installed
import bodyParser from 'body-parser';
app.use(bodyParser.json());

// ❌ Wrong API — Zod v3 pattern, but Zod v4 changed the API
const schema = z.object({ name: z.string() });
schema.parse(data); // Zod v4 requires schema.parse({...}) with options

Models know about libraries, but they don't know which version you have installed or what the current API looks like.


Related MCP server: @particle-academy/docs-mcp

The Solution

ts-docs-mcp provides documentation sourced from the actual package source code — not training data.

The pipeline:

npm registry → GitHub .ts (JSDoc) → npm tarball (.d.ts) → DefinitelyTyped (@types/)
  1. Resolves the exact version from the npm registry

  2. Reads TypeScript source from GitHub, including JSDoc, @param, @returns

  3. Follows re-exports to find actual declarations (BFS, parallel fetches)

  4. Falls back to .d.ts from the npm tarball if GitHub source is insufficient

  5. Falls back to DefinitelyTyped for JS-only packages (express, etc.)

  6. Returns clean Markdown — full signatures, parameters, deprecation notices, examples

Before vs After

Package

Before (v0.1.0)

After (v0.4.1)

zod

31 symbols

577

axios

0

83

uuid

0

23

chalk

19

32

fastify

51

~100+

express

0

13 (via @types/express)


How It Works

┌──────────────────┐       ┌──────────────────────────────────────────────┐
│  AI Coding Agent │ ◄──── │          ts-docs-mcp                         │
│  (Cursor, Claude │ MCP   │   (MCP Server via stdio)                     │
│   Code, etc.)    │       │                                              │
└──────────────────┘       │  get_package_docs("zod")                     │
         │                  │    ↓                                        │
         │   "Here is the  │  1. npm registry → package metadata          │
         │   full API      │  2. GitHub raw → JSDoc from .ts source       │
         │   documentation"│  3. BFS re-export resolution (parallel)      │
         ▼                  │  4. npm tarball → .d.ts parsing (no JSDoc?) │
  Writes correct code       │  5. @types/{name} fallback (JS-only)        │
                            │  6. Merge + dedup → Markdown                │
                            │  7. XDG cache (24h TTL)                     │
                            └──────────────────────────────────────────────┘

Tools

Tool

Description

get_package_docs

Get API docs for any npm package. Optional query, version, subpath.

Examples

# Latest version
get_package_docs("zod")

# Specific version
get_package_docs("zod", version="3.23.8")

# Subpath export (e.g. zod/v4/classic)
get_package_docs("zod", subpath="v4/classic")

# Query a specific symbol
get_package_docs("zod", query="transform")

Fallback chain

GitHub .ts (JSDoc + declarations)
  → BFS re-export resolution (depth=2, concurrency=5)
    → merge: GitHub .d.ts (from tarball, with re-export following)
      → if 0 symbols: DefinitelyTyped (@types/{name})
        → merge all results, dedup by name (GitHub takes priority)

What the model gets

## findByEmail (function)
> Find a user by their email address.
> @param email — The email to search for
> @returns The user object or null

```typescript
export function findByEmail(email: string, includeDeleted?: boolean): User | null;

Parameters:

  • email — The email to search for

  • includeDeleted — Whether to include deleted users

Returns: The user object or null


Full signatures, no truncation. `@param`, `@returns`, `@deprecated`, `@example` are preserved.

### Cache

Documentation is cached in `~/.cache/ts-docs-mcp/` (XDG-compatible), keyed by `package@version`. TTL is 24 hours. Old entries are cleaned up after 7 days.

---

## Usage

### Quick start

Add to your MCP configuration:

```json
{
  "mcpServers": {
    "ts-docs-mcp": {
      "command": "npx",
      "args": ["-y", "ts-docs-mcp"]
    }
  }
}

Cursor: Settings → MCP → Add Server → paste the config above. Claude Code: claude mcp add ts-docs-mcp -- npx -y ts-docs-mcp VS Code / Copilot: .vscode/mcp.json → add the entry.

Requirements

  • Node.js 20+

  • Internet access (fetches from npm registry, GitHub, npm tarballs)

  • Package must be on npm with a public GitHub repository (or have @types/ types)


Examples

Get the full API overview:

You → "Show me the axios API"
Agent → calls get_package_docs("axios")
     → gets 83 symbols: types, interfaces, classes, functions

Find a specific symbol:

You → "How do I use Zod's transform method?"
Agent → calls get_package_docs("zod", query="transform")
     → gets ZodEffects.transform with full signature + JSDoc

Why not just use the README / training data?

Source

Coverage

Version-aware

Freshness

Training data

Variable

❌

6-24 months stale

README

~20% of API

❌

Often stale

ts-docs-mcp

All exports

✅ Exact version

✅ Real-time

TypeScript .d.ts files + GitHub source are the canonical source of truth — they always reflect the exact installed version.


Development

git clone https://git.827482.xyz/xvantz/ts-docs-mcp.git
cd ts-docs-mcp
npm install
npm run build
npm test          # 43 unit tests (5 test files)
npm run test:integration  # network tests (skipped in CI)

Project structure

src/
├── registry.ts   — npm package metadata + HTTP helpers
├── github.ts     — GitHub raw source fetching (BFS, parallel)
├── tarball.ts    — .d.ts extraction from tarball + DefinitelyTyped
├── parser.ts     — Two-phase JSDoc + declaration parser
├── format.ts     — Markdown output (summary + detail)
├── throttle.ts   — Per-endpoint token-bucket rate limiter
├── cache.ts      — XDG file cache with 24h TTL
├── types.ts      — PublicSymbol, PackageInfo interfaces
└── index.ts      — MCP server (thin handler)

License

MIT

Built because AI coding agents deserve better than hallucinated APIs.

Available Tools

1 tool
get_package_docsA

Get accurate, version-specific API documentation for any npm package.

WHEN TO USE THIS TOOL:

  • ALWAYS call this tool when the user asks about a library, package, or framework.

  • ALWAYS call this tool BEFORE writing code that uses an external npm dependency.

  • ALWAYS call this tool when you need to know function signatures, types, interfaces, classes, or exports from a package.

  • Call this tool when the user says things like: 'use zod', 'write with axios', 'how does fastify work', 'express route handler', 'prisma schema', 'lodash merge'.

  • Call this tool when a package version is mentioned: 'zod@3.23', 'express 4.18' — pass it as the 'version' parameter.

DO NOT rely on training data for package APIs — training data is months out of date. This tool fetches the EXACT version the user needs from the actual source code.

Supports:

  • Specific version: get_package_docs('zod', version='3.23.8')

  • Subpath exports: get_package_docs('zod', subpath='v4/classic')

  • Symbol search: get_package_docs('zod', query='transform')

Documentation is cached for 24 hours — repeated calls for the same package+version are instant.

NameRequiredDescriptionDefault
queryNoOptional — find a specific symbol within the package.
packageYesnpm package name, e.g. 'zod', 'express', '@prisma/client'
subpathNoOptional — subpath export entry, e.g. 'v4/classic' for zod/v4/classic.
versionNoOptional — exact version to fetch (e.g. '3.23.8'). Defaults to latest.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.6.3
    • First observedget_package_docs

TDQS

A4.1/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no ambiguity whatsoever — get_package_docs has a clearly defined purpose of fetching version-specific npm package documentation. There are no overlapping tools to confuse.

Naming Consistency4/5

The single tool name 'get_package_docs' follows the conventional verb_noun pattern and is descriptive. However, with only one tool, there's no pattern to evaluate for consistency across a set.

Tool Count2/5

A single tool for package documentation is borderline thin. While it's a focused purpose, a fuller server might include tools for discovering packages, listing versions, or comparing docs — but the single tool does serve a coherent narrow scope.

Completeness3/5

The tool covers fetching docs with version, subpath, and symbol query options, which handles the core use case of retrieving accurate package API info. However, there are no companion tools for related operations like listing supported packages, listing available versions, or fetching type definitions separately, creating minor gaps.

Related MCP Connectors

Related MCP Servers