Scriptdocs MCP Server

ScriptDocs MCP Server

A Model Context Protocol (MCP) server that gives AI coding agents real, live, source-cited documentation for npm and PyPI packages — pulled directly from registry.npmjs.org and pypi.org at call time.

Built by ScriptMaster Labs.

What this actually does (and doesn't)

Every tool call makes a real HTTP request to the actual registry. There is no cached demo data, no fabricated example output, and no guessing. If a package or its docs can't be found, the tool returns an explicit error — never a plausible-looking made-up answer. Every successful response includes source_url and fetched_at so the caller can verify exactly where the data came from and how fresh it is.

Not yet built (honest status, not hype):

• Payment/licensing (Stripe, API keys, usage tiers) — this is scaffolding work that needs your real Stripe account and pricing decisions. Nothing in this repo simulates a working payment system.
• GitHub-source doc fetching beyond README/long-description (e.g. specific guide pages, versioned doc sites) — README/long-description only in v0.1.

Tools

Project layout

scriptdocs-mcp-server/
├── package.json
├── tsconfig.json
├── Dockerfile
├── src/
│   ├── index.ts          # server entry point, transport selection
│   ├── constants.ts
│   ├── types.ts
│   ├── services/
│   │   ├── npm.ts        # real npm registry client
│   │   ├── pypi.ts       # real PyPI registry client (supports version pinning)
│   │   ├── osv.ts        # real OSV.dev vulnerability database client
│   │   └── docSearch.ts  # keyword/snippet extraction over fetched text
│   └── tools/
│       ├── getPackageInfo.ts
│       ├── getReadme.ts
│       ├── searchDocs.ts
│       └── checkVulnerabilities.ts
└── dist/                 # build output (git-ignored)

Run it locally (stdio — for Claude Desktop / Cursor)

npm install
npm run build
node dist/index.js

To wire it into Claude Desktop or Cursor, point their MCP config at:

{
  "mcpServers": {
    "scriptdocs": {
      "command": "node",
      "args": ["/absolute/path/to/scriptdocs-mcp-server/dist/index.js"]
    }
  }
}

Run it as a remote server (HTTP — for Render, same pattern as your other services)

npm install
npm run build
TRANSPORT=http PORT=3000 node dist/index.js

• Health check: GET /health
• MCP endpoint: POST /mcp

Deploy to Render

The included Dockerfile builds and runs the HTTP transport. Point a Render Web Service at this repo with:

• Environment: Docker
• Health check path: /health

This mirrors how mcp-x402 and squeezeos-api are already deployed.

Verified working (tested against live registries and APIs)

• docs_get_package_info → express (npm) returned real current version and metadata straight from registry.npmjs.org.
• docs_get_readme → zod (npm, via jsDelivr fallback), requests (PyPI, latest), and requests==2.28.0 (PyPI, version-pinned) all returned real, verbatim README text from the exact version requested.
• docs_search_docs → keyword search over the real zod README returned verbatim matching context.
• docs_check_vulnerabilities → express@4.17.1 correctly returned 2 real advisories (incl. CVE-2024-43796) from OSV.dev; express@5.2.1 (current) correctly returned zero — verified against the live OSV.dev API, not simulated.
• Nonexistent package name → correctly returns an explicit isError: true response instead of fabricating a plausible answer.
• Both stdio and TRANSPORT=http modes verified against the actual MCP JSON-RPC protocol (initialize, tools/list, tools/call).

Getting listed as a real alternative (not hype — the actual mechanics)

There's no "beat Context7's ranking" button. There's one source-of-truth feed and a handful of directories that read from it. This is the real, current (as of July 2026) process, verified against the official docs at modelcontextprotocol.io/registry:

1. The official MCP Registry (registry.modelcontextprotocol.io) is what a growing number of AI clients read to discover servers. There's no review queue — you publish a server.json record under a namespace you prove you own, and it's live.
2. Discovery directories — Smithery, Glama, PulseMCP, mcp.so — crawl GitHub and the registry on their own. You may already show up there unclaimed once this is public; claiming ownership is what lets you control the description instead of a bot's guess.

What's already prepped in this repo

• package.json has "mcpName": "io.github.Timwal78/scriptdocs-mcp-server" and is renamed to the scoped package @scriptmasterlabs/scriptdocs-mcp-server (under the existing @scriptmasterlabs org scope — same one publishing mcp-x402 and mcp-x402-sdk — rather than a personal scope, since this sits alongside your other MCP infrastructure)
• server.json is written and validated against the real, live official schema (static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json) — not guessed at.
• .github/workflows/publish-mcp.yml auto-publishes to npm and the MCP Registry every time you push a v* tag, using the official OIDC flow (no registry secret needed — just an NPM_TOKEN).
• License changed from UNLICENSED to MIT — a package meant for strangers to install needs a license that actually lets them use it.

What only you can do (needs your accounts/credentials — I don't have them)

1. Push this to a public GitHub repo at github.com/Timwal78/scriptdocs-mcp-server (or wherever you want it — update repository in package.json and server.json to match if the path differs).
2. Add an NPM_TOKEN secret to that repo (Settings → Secrets → Actions) from an npm access token tied to your npm account.
3. Tag and push a release: git tag v0.2.0 && git push origin v0.2.0 — the workflow handles npm publish + MCP Registry publish automatically from there.
4. Claim your listing on Smithery, Glama, and PulseMCP once the registry record is live — they crawl and often list you automatically, but claiming moves you from "anonymous crawl result" to a verified, owner-controlled listing.

Being honest about "replacing Context7"

Context7 has real scale (tens of thousands of installs, broad ecosystem coverage) built over time. What actually makes a server "a viable alternative" in these registries isn't a claim in a README — it's real uptime, a working install, and accurate tool descriptions, which is what steps 1-4 above get you: correctly listed, discoverable, and functioning. Nothing here fabricates traction that doesn't exist yet.

Other next steps (your call)

1. Licensing/monetization — needs your real Stripe keys and a decision on free-tier call limits before anything gets built here. I won't wire up fake gating that pretends to work.
2. More ecosystems — Cargo (Rust), Go modules, RubyGems would follow the same services/*.ts pattern already established for npm/PyPI.
3. Versioned doc pages (not just README) — would need per-package doc site scraping, which is a bigger lift than the registry APIs used here.
4. Caching layer — currently every call hits the live registry fresh (correct for accuracy, but means repeated calls for the same package in one session re-fetch). A short in-memory TTL cache would cut latency without sacrificing truthfulness — not yet built.
5. Remote (HTTP) registry listing — the registry also supports a remotes entry pointing at a live URL (same pattern as your other Render-hosted MCP servers), which can be added to server.json alongside the npm packages entry once this is actually deployed to Render with a public URL.