Retrieves version-pinned TypeScript declaration files for npm packages from the jsDelivr CDN.
Enables MCP clients to query the exported API surface and type signatures of any npm package, including functions, classes, interfaces, types, and enums, by reading from the package's published TypeScript declaration files.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pkg-api-mcp What does zod@3.23.8 export?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The antidote to your coding agent inventing functions that don't exist.
An MCP 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.
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.
Related MCP server: Augments MCP Server
Tool | What it does |
| The exported surface of |
| The raw |
| Every declaration file in the package — for split types or submodule imports. |
No API key. Types are read from jsDelivr, version-pinned.
npx pkg-api-mcpclaude mcp add pkg-api -- npx -y pkg-api-mcp{
"mcpServers": {
"pkg-api": {
"command": "npx",
"args": ["-y", "pkg-api-mcp"]
}
}
}"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."
Env var | Default | Purpose |
|
| Max characters returned per call, to protect the context window. |
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 indexThe 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.
npm install
npm run build
node dist/index.jsPackages 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.
MIT © Anicodeth
List every TypeScript declaration (.d.ts) file shipped in an npm package@version. Use when package_api can't find the entry, when a package splits its types across many files, or to locate the declaration for one submodule/export.
Inputs: package (required), version.
Get the REAL exported API — functions, classes, constants, interfaces, types — of an npm package at a specific version, extracted from its published TypeScript declarations (.d.ts). Reach for this WHENEVER you're about to call into a library and aren't 100% certain a function/option exists with that exact name and signature. It is the antidote to inventing APIs: if it isn't in this list, the package doesn't export it. Grouped by kind, with one-line signatures.
Inputs: package (required), entry, version.
Return the raw .d.ts declaration text for an npm package@version — the ground-truth type definitions. Use when you need exact signatures, generic parameters, overloads, or option-object shapes that a summary can't capture (e.g. the precise props of a component or the full options of a function). Defaults to the package's types entry; pass file (from list_type_files) to read a specific declaration file.
Inputs: package (required), file, version, maxChars.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 3 tools
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.
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.
With 3 tools, the server is minimal but well-scoped. Each tool covers a necessary aspect of inspecting package declarations, and none feel redundant.
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.
Live npm and UNPKG data for AI agents: resolution, audits, import maps, malware/CVE checks.
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Verify npm packages before your AI agent installs them: hallucinations, advisories, API drift.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.