Skip to main content
Glama
README.md
# pkg-api-mcp

> The antidote to your coding agent inventing functions that don't exist.

An [MCP](https://modelcontextprotocol.io) server that feeds Claude, Cursor, and any MCP client the **real exported API surface and type signatures** of any npm package — extracted straight from its published `.d.ts` declarations. If a function isn't in the output, the package doesn't export it. Full stop.

## Why this exists

The most common way an AI coding agent wastes your time: confidently calling `library.doThing(...)` where `doThing` never existed, or passing an option the API doesn't accept. The ground truth — the package's own TypeScript declarations — is sitting on a CDN. This server puts it in the agent's context, version-pinned, before it writes the call.

## Tools

| Tool | What it does |
|------|--------------|
| `package_api` | The exported surface of `package@version` — functions, classes, consts, interfaces, types — grouped by kind with one-line signatures. Check this before calling into any unfamiliar library. |
| `package_types` | The **raw** `.d.ts` text — exact generics, overloads, and option-object shapes when a summary isn't enough. |
| `list_type_files` | Every declaration file in the package — for split types or submodule imports. |

No API key. Types are read from [jsDelivr](https://www.jsdelivr.com/), version-pinned.

## Quick start

```bash
npx pkg-api-mcp
```

### Claude Code

```bash
claude mcp add pkg-api -- npx -y pkg-api-mcp
```

### Claude Desktop / Cursor / Windsurf / any MCP client

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

## Example prompts

- *"What does zod@3.23.8 actually export? Use pkg-api before writing the schema."*
- *"Show me the real signature of `format` in date-fns@latest."*
- *"I need the exact props type for the Query client in @tanstack/react-query — pull the raw types."*

## Config

| Env var | Default | Purpose |
|---------|---------|---------|
| `PKG_API_MAX_CHARS` | `16000` | Max characters returned per call, to protect the context window. |

## How it works

```
package[@version]
   │
   ├─ jsDelivr resolve ──► exact version
   ├─ read package.json "types"/"typings" (or derive from "main")
   ├─ fetch the .d.ts from the CDN
   └─ extract every `export …` ──► grouped, signature-level API index
```

The extractor is deliberately dependency-free (no TypeScript compiler in your runtime) and handles functions, classes, consts, interfaces, types, enums, namespaces, `export default`, and `export { … } from`/`export *` re-exports.

## Develop

```bash
npm install
npm run build
node dist/index.js
```

## Caveats

- Packages that ship **no** types (pure JS, no bundled `.d.ts`) won't resolve here — their types usually live in a separate `@types/<name>` package; run `package_api` on that instead.
- The extractor is regex-based, not a full TS parse: it's built for an accurate at-a-glance index. For byte-exact overloads, use `package_types`.

## License

MIT © Anicodeth

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct role: package_api provides a summarized list of exports, list_type_files lists declaration files, and package_types returns raw text. The descriptions clearly differentiate these, so an agent can choose correctly without confusion.

Naming Consistency3/5

Two tools follow a package_ prefix pattern (package_api, package_types) but the third uses a verb_noun style (list_type_files). This mixed convention is readable but not fully consistent.

Tool Count4/5

With 3 tools, the server is minimal but well-scoped. Each tool covers a necessary aspect of inspecting package declarations, and none feel redundant.

Completeness5/5

The toolset covers the full read-only workflow: locate declaration files, get a summarized API, and retrieve raw type text. There are no obvious gaps for its stated purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues