The NPM Package Docs MCP server retrieves up-to-date documentation for any npm package directly within your IDE.
Retrieve Documentation: Fetch the latest README content for any npm package by name
GitHub Priority: Automatically pulls documentation from the package's GitHub repository (main, master, or develop branches)
NPM Fallback: Extracts documentation from the package tarball if no GitHub repository is found
IDE Integration: Seamlessly integrates with MCP-compatible IDEs like Cursor for enhanced development workflow
Natural Language Commands: Request documentation for specific packages using conversational commands in your IDE
Click on "Install 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., "@NPM Package Docs MCP show me the docs for react-router-dom"
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.
A Model Context Protocol (MCP) tool that provides up-to-date documentation for npm packages directly in your IDE. This tool fetches the latest README documentation from either the package's GitHub repository or the README bundled with the npm package itself.
This MCP tool helps your IDE (like Cursor) get the most current documentation for any npm package instead of relying on outdated or incomplete information. It works by:
GitHub Repository First: If the package has a GitHub repository, it fetches the README directly from the repository's main branch (trying master, main, or develop branches)
NPM Package Fallback: If no GitHub repository is available, it downloads the package tarball and extracts the README file from the bundled package
Real-time Updates: Always gets the latest documentation, ensuring you have the most current information
Related MCP server: MCP LLMS.txt Explorer
No more guesswork: Get accurate, up-to-date documentation instead of relying on potentially outdated IDE suggestions
Better development experience: Understand package APIs and usage patterns with current documentation
Reduced errors: Avoid issues caused by using outdated API references or deprecated methods
Seamless integration: Works directly in your IDE through the MCP protocol
get_docs_for_npm_packageDescription: Retrieves the latest documentation for any npm package
Parameters:
packageName (string): The name of the npm package (e.g., "react", "lodash", "express")
Returns: The README content as text, either from the GitHub repository or the package tarball
Example Usage:
// In your IDE, you can now ask for documentation like:
// "Show me the docs for express"
// "What's the latest API for react-router-dom?"
// "Get documentation for axios"Package Lookup: Queries the npm registry to get package metadata
Repository Detection: Checks if the package has a GitHub repository URL
GitHub Fetch: If available, fetches README.md from the repository's main branch
Tarball Extraction: If no GitHub repo, downloads and extracts the package tarball to find the README
Content Return: Returns the documentation content to your IDE
Node.js (v16 or higher)
Cursor IDE (or any MCP-compatible IDE)
Edit your Cursor MCP configuration file (usually located at ~/.cursor/mcp.json):
{
"mcpServers": {
"npm-package-docs-mcp": {
"command": "npx",
"args": [
"meanands/npm-package-docs-mcp"
]
}
}
}Restart Cursor: Restart Cursor IDE to load the new MCP server
Once installed, you can use the tool in Cursor by:
Opening the command palette (Cmd/Ctrl + Shift + P)
Typing your request, for example:
"Get docs for express"
"Show me the latest react documentation"
"What's new in lodash v4?"
The tool will fetch and display the current documentation for the requested package.
npm run devnpm run buildnpm-docs-mcp/
├── src/
│ ├── server.ts # Main MCP server implementation
│ └── types/
│ └── index.ts # TypeScript type definitions
├── package.json
├── tsconfig.json
└── README.mdContributions are welcome! Please feel free to submit a Pull Request.
MIT License - see the LICENSE file for details.
If you encounter any issues or have questions, please open an issue on the GitHub repository.
Get the docs for an npm package
| Name | Required | Description | Default |
|---|---|---|---|
| packageName | Yes | Name of the npm package |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without detailing how it works—such as source of docs (e.g., npm registry, GitHub), format of return (e.g., markdown, JSON), error handling, or any constraints like rate limits or authentication needs. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that efficiently conveys the core action. It is front-loaded with no unnecessary words, making it easy to parse. However, it is overly terse, missing details that could enhance usability without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It fails to explain what 'docs' include, the return format, or any behavioral aspects like error cases. For a tool with minimal structured data, the description should provide more context to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'packageName' clearly documented. The description does not add any meaning beyond the schema, as it only repeats the tool's purpose without elaborating on parameter usage (e.g., package naming conventions or validation). With high schema coverage, the baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the docs for an npm package' restates the title and name with minimal elaboration. It specifies the verb 'Get' and resource 'docs for an npm package', but lacks detail on what 'docs' entails (e.g., README, API documentation, or installation guides) or how they are retrieved. Without sibling tools, differentiation isn't needed, but the purpose remains vague beyond basic restatement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool. The description does not mention prerequisites, alternatives, or context for usage (e.g., vs. searching npm registry or checking package versions). With no sibling tools, explicit alternatives aren't required, but general usage context is missing, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_docs_for_npm_packageWith only one tool, there is no possibility of confusion or overlap between tools. The tool's purpose is singular and clearly defined, making disambiguation perfect.
The single tool name follows a clear verb_noun pattern (get_docs_for_npm_package), and with only one tool, consistency is inherently perfect as there are no other names to compare against.
A single tool for an 'NPM Package Docs' server feels too thin and under-scoped. The server's purpose suggests potential for more operations like searching packages, listing versions, or getting specific documentation sections, but only one basic retrieval tool is provided.
The tool surface is severely incomplete for the apparent domain of npm package documentation. It only allows getting docs for a package, with no support for operations like searching, filtering, or handling multiple packages, which are likely needed for effective agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Dive into the world of npm with our NPM Package Info MCP. Access crucial metadata about any npm
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/meanands/npm-package-docs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server