Query package ecosystem data (licenses, versions, CVEs, repositories, dependents) for 35+ package registries across npm, PyPI, RubyGems, Cargo, Go, and more, plus search, registry listing, and health checks.
Get package details (get_package) – license, latest version, description, downloads, dependency count
Look up packages (lookup_package) – by PURL, ecosystem+name, or GitHub/GitLab repo URL
List versions (get_package_versions) – version history and release dates
Check vulnerabilities (get_package_advisories) – CVEs and security advisories for audits
Get repository stats (get_package_repository) – stars, forks, language, open issues
Find dependents (get_package_dependents) – reverse dependencies, paginated, to gauge adoption
Search packages (search_packages) – keyword search across all ecosystems (needs local DB)
List registries (list_registries) – supported ecosystems with package counts
Inspect local database (get_database_info) – total packages, ecosystem breakdown, build date
Check server health (health_check) – database connectivity and API availability
Allows querying package metadata, version history, and security advisories for the Bower package ecosystem.
Provides tools to look up package details, repository information, and dependencies for the CocoaPods ecosystem.
Enables searching for Deno packages and retrieving version history and registry data.
Allows querying metadata, versions, and registry information for Docker images.
Provides tools to retrieve metadata, dependency information, and version history for Elm packages.
Enables retrieval of repository metadata such as stars, forks, and open issues, and allows finding packages associated with specific GitHub repository URLs.
Provides access to package data, versions, and repository details for Homebrew formulae and casks.
Enables querying metadata, dependencies, and version information for the Julia package ecosystem.
Allows querying extensive data for npm packages, including licenses, download statistics, dependencies, and security advisories.
Provides tools for retrieving package metadata, versions, and security information for the NuGet ecosystem.
Enables looking up PHP package data, dependencies, and repository information from the Packagist registry.
Allows querying metadata and version history for Puppet modules.
Provides tools to retrieve package information, security advisories, and repository stats for Python packages on PyPI.
Enables querying package metadata and version information for the Racket ecosystem.
Allows looking up Ruby gem details, dependencies, and security advisories from the RubyGems registry.
Enables querying package metadata and version information for the Swift Package Manager (SwiftPM) ecosystem.
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., "@Ecosyste.ms Package Data What license does lodash use?"
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.
MCP server for querying package ecosystem data from ecosyste.ms.
Queries a local SQLite database of critical packages for fast lookups, with API fallback for packages not in the database.
npm install -g @ecosyste-ms/mcpOr run directly with npx:
npx @ecosyste-ms/mcpThe database is bundled via @ecosyste-ms/critical. No additional setup required.
To use a custom database, set ECOSYSTEMS_DB_PATH or place critical-packages.db in your working directory.
ECOSYSTEMS_DB_PATH is authoritative when set: the server uses exactly that file, or runs API-only if it is missing. Set it to none to skip the local database entirely.
Related MCP server: npm-docs-server
Open a terminal and run:
claude mcp add ecosystems -- npx @ecosyste-ms/mcpWith a custom database path:
claude mcp add ecosystems -- env ECOSYSTEMS_DB_PATH=/path/to/db.sqlite npx @ecosyste-ms/mcpFrom within Claude Code, use the /mcp command to verify the server is running.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"ecosystems": {
"command": "npx",
"args": ["@ecosyste-ms/mcp"]
}
}
}With custom database path:
{
"mcpServers": {
"ecosystems": {
"command": "npx",
"args": ["@ecosyste-ms/mcp"],
"env": {
"ECOSYSTEMS_DB_PATH": "/path/to/critical-packages.db"
}
}
}
}Add to .cursor/mcp.json in your project or ~/.cursor/mcp.json globally:
{
"mcpServers": {
"ecosystems": {
"command": "npx",
"args": ["@ecosyste-ms/mcp"]
}
}
}Open a terminal and run:
code --add-mcp '{"type":"stdio","name":"ecosystems","command":"npx","args":["@ecosyste-ms/mcp"]}'Or manually add to .vscode/mcp.json:
{
"servers": {
"ecosystems": {
"type": "stdio",
"command": "npx",
"args": ["@ecosyste-ms/mcp"]
}
}
}Then open the .vscode/mcp.json file in VS Code and click "Start server".
Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"ecosystems": {
"command": "npx",
"args": ["@ecosyste-ms/mcp"]
}
}
}Add to Zed settings (cmd+,):
{
"context_servers": {
"ecosystems": {
"command": {
"path": "npx",
"args": ["@ecosyste-ms/mcp"]
}
}
}
}Note: ChatGPT requires remote MCP servers. Run the server with a tunnel or deploy it.
For local development with a tunnel:
npx @anthropic-ai/mcp-proxy --port 8080 -- npx @ecosyste-ms/mcpThen in ChatGPT:
Navigate to Settings > Connectors
Add a custom connector with your tunnel URL
The server will be available in Composer > Deep Research
Add to ~/.codex/config.toml:
[mcp_servers.ecosystems]
command = "npx"
args = ["@ecosyste-ms/mcp"]Add to ~/.gemini/settings.json:
{
"mcpServers": {
"ecosystems": {
"command": "npx",
"args": ["@ecosyste-ms/mcp"]
}
}
}get_package - Get full package data by ecosystem and name
lookup_package - Find package by PURL, ecosystem+name, or repository URL
get_package_versions - Get all versions (publish dates come from the API; the local database stores version numbers only)
get_package_advisories - Get security advisories (CVEs)
get_package_repository - Get repository metadata (stars, forks, language)
get_package_dependents - Get packages that depend on this package
search_packages - Full-text search (requires local database)
list_registries - List all available package registries
get_database_info - Get local database stats
health_check - Check server health (database connectivity, API availability)
Ask your LLM:
"What license does lodash use?"
"Show me the CVEs for express"
"How many stars does the react repository have?"
"What packages depend on typescript?"
"Search for packages related to authentication"
"What's the latest version of axios?"
npm, pypi, rubygems, cargo, go, maven, nuget, packagist, hex, pub, hackage, cocoapods, conda, clojars, puppet, homebrew, docker, bower, cpan, cran, julia, swiftpm, elm, deno, alpine, actions, openvsx, spack, adelie, vcpkg, racket, bioconductor, carthage, postmarketos, elpa
git clone https://github.com/ecosyste-ms/mcp
cd mcp
npm install
npm testRun locally:
node index.jsMIT
Show local database stats: total packages, ecosystems breakdown, build date. Use to verify data availability.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read-only operation ('Show') for informational purposes, which is adequate for a simple stats tool. However, it lacks details on potential errors, performance characteristics, or data freshness that could be useful context.
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 two concise sentences with zero waste: the first states the action and what it returns, and the second provides usage context. It is front-loaded with the core purpose, making it easy to scan and understand quickly.
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 the tool's low complexity (0 parameters, no output schema), the description is mostly complete for a simple read operation. It covers the purpose, usage, and output semantics adequately. A minor gap is the lack of explicit output structure details, but this is mitigated by the straightforward nature of the tool.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the tool's purpose and output content (stats like total packages), which compensates for the lack of an output schema, though it doesn't fully specify the return format.
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 clearly states the specific action ('Show') and resource ('local database stats'), with explicit details on what stats are included (total packages, ecosystems breakdown, build date). It distinguishes this tool from sibling tools like 'get_package' or 'search_packages' by focusing on database-level metadata rather than package-specific operations.
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?
The description provides clear context for when to use this tool ('to verify data availability'), which implicitly differentiates it from siblings that retrieve package data. However, it does not explicitly state when not to use it or name specific alternatives, such as using 'health_check' for system status instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get package info: license, latest version, description, downloads, dependencies count. Use when asked about a specific package.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | npm, pypi, rubygems, cargo, go, maven, nuget, packagist, hex, pub, etc. | |
| name | Yes | Package name |
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. The description only states what information is retrieved without mentioning behavioral aspects like rate limits, authentication needs, error handling, or response format. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 extremely concise and well-structured with two sentences: one listing the retrieved information and another providing usage guidance. Every sentence earns its place with no wasted words, making it easy to parse and understand quickly.
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 the tool's moderate complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and usage but lacks details on behavioral traits, response format, and error handling. Without annotations or output schema, the description should do more to compensate for these gaps.
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?
Schema description coverage is 100%, so the schema already documents both parameters ('ecosystem' and 'name') with clear descriptions. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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 clearly states the tool's purpose with specific verbs ('Get package info') and lists the information retrieved (license, latest version, description, downloads, dependencies count). It distinguishes from siblings like 'get_package_advisories' or 'get_package_versions' by focusing on general package metadata rather than specific aspects. However, it doesn't explicitly differentiate from 'lookup_package' which might have similar functionality.
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?
The description provides explicit guidance on when to use this tool ('Use when asked about a specific package'), which is helpful for context. It doesn't mention when not to use it or name specific alternatives among siblings, but the implied context is clear for basic package information queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check security vulnerabilities and CVEs for a package. Use for security audits, vulnerability checks, or when asked if a package is safe.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | Package ecosystem | |
| name | Yes | Package name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('check') and hints at security-focused behavior, but lacks details on rate limits, authentication needs, error handling, or response format. For a tool with no annotations, this is a moderate gap, as it doesn't fully disclose behavioral traits beyond the basic purpose.
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 appropriately sized and front-loaded: it starts with the core purpose, followed by usage guidelines in a single, efficient sentence. Every phrase adds value without redundancy, making it highly concise and well-structured.
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 the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers purpose and usage well, but without annotations or output schema, it lacks details on behavioral aspects like response format or error conditions. This makes it adequate but not fully comprehensive for an agent to use confidently.
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?
Schema description coverage is 100%, with both parameters ('ecosystem' and 'name') documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., examples of ecosystems or package names). According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
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 clearly states the tool's purpose: 'Check security vulnerabilities and CVEs for a package.' It specifies the verb ('check') and resource ('security vulnerabilities and CVEs for a package'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_package' or 'lookup_package', which might also provide security-related information, so it doesn't reach a 5.
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?
The description provides clear usage contexts: 'Use for security audits, vulnerability checks, or when asked if a package is safe.' This gives explicit guidance on when to use the tool. However, it doesn't mention when not to use it or name specific alternatives among the sibling tools (e.g., 'get_package' might offer broader package info), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List packages that depend on this one (reverse dependencies). Use to gauge adoption or find usage examples.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | Package ecosystem | |
| name | Yes | Package name | |
| page | No | Page number | |
| per_page | No | Results per page (max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation by using 'List', but does not disclose behavioral traits like pagination handling, rate limits, authentication needs, or error conditions. The mention of 'page' and 'per_page' in the schema hints at pagination, but the description does not elaborate on this behavior.
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 two sentences, front-loaded with the core purpose and followed by usage context. Every word earns its place, with no redundancy or unnecessary elaboration, making it efficient and easy to parse.
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 and no output schema, the description provides basic purpose and usage but lacks details on behavior (e.g., pagination, errors) and return values. For a tool with 4 parameters and pagination, this leaves gaps in understanding how to effectively invoke and interpret results, though the purpose is clear.
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 schema description coverage is 100%, so the schema already documents all parameters (ecosystem, name, page, per_page). The description does not add meaning beyond the schema, such as explaining what 'ecosystem' entails or how pagination works in practice. Baseline 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 clearly states the verb ('List') and resource ('packages that depend on this one'), with the parenthetical 'reverse dependencies' providing precise terminology. It distinguishes this tool from siblings like get_package or search_packages by focusing on dependents rather than package details or general searches.
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?
The description provides clear context for when to use it ('to gauge adoption or find usage examples'), which helps an agent understand its purpose. However, it does not explicitly state when not to use it or name alternatives among siblings, such as get_package for package details instead of dependents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get GitHub stats: stars, forks, language, open issues. Use when asked about popularity, maintenance, or source repo.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | Package ecosystem | |
| name | Yes | Package name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation by using 'Get', but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or response format. The description adds minimal context beyond the basic purpose, leaving gaps in transparency for an API tool.
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 highly concise and front-loaded: two sentences with zero waste. The first sentence states the purpose with specific stats, and the second provides usage guidelines. Every word earns its place, making it efficient and easy to parse.
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 the tool's moderate complexity (2 required parameters, no annotations, no output schema), the description is adequate but incomplete. It covers purpose and usage well but lacks details on behavior, response format, or error cases. For a tool fetching GitHub stats, more context on what 'stats' includes or how results are structured would improve completeness.
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?
Schema description coverage is 100%, so the schema already documents both parameters ('ecosystem' and 'name'). The description doesn't add any meaning beyond what the schema provides—it doesn't explain what 'ecosystem' entails (e.g., npm, PyPI) or how 'name' relates to GitHub. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the tool's purpose: 'Get GitHub stats: stars, forks, language, open issues.' It specifies the verb ('Get') and resource ('GitHub stats') with concrete examples. However, it doesn't explicitly differentiate from siblings like 'get_package' or 'lookup_package', which might provide overlapping or different package information.
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?
The description provides clear usage context: 'Use when asked about popularity, maintenance, or source repo.' This gives explicit scenarios for when to invoke the tool. It doesn't specify when NOT to use it or name alternatives among siblings, but the guidance is sufficient for typical queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List package versions with release dates. Use for version history, release timeline, or finding when a version was published.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | Package ecosystem | |
| name | Yes | Package name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the output ('list package versions with release dates') and implies a read-only operation, but lacks details on behavioral traits like pagination, rate limits, error handling, or authentication needs. The description adds basic context but is minimal 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 concise and well-structured with two sentences: the first states the purpose, and the second provides usage guidelines. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 100% schema coverage, the description is adequate but minimal. It covers the purpose and usage contexts but lacks details on output format, limitations, or error cases. For a simple list tool, this might suffice, but more completeness would improve agent understanding.
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?
Schema description coverage is 100%, so the schema already documents both parameters ('ecosystem' and 'name'). The description doesn't add any meaning beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the tool's purpose with specific verbs ('List package versions') and resources ('package versions with release dates'), distinguishing it from siblings like 'get_package' or 'lookup_package'. However, it doesn't explicitly differentiate itself from potential similar tools beyond the examples given.
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?
The description provides clear usage contexts ('version history, release timeline, or finding when a version was published'), which helps an agent understand when to use this tool. It doesn't explicitly state when not to use it or name alternatives among siblings, but the context is sufficiently clear for informed selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check server health: database connectivity, API availability. Use to diagnose connection issues.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only diagnostic operation ('check', 'diagnose'), which is appropriate, but doesn't add details like whether it requires authentication, has rate limits, or what the output format might be. This leaves gaps in behavioral context, scoring it as adequate but with clear room for improvement.
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 highly concise and well-structured, consisting of two short sentences that efficiently convey the tool's purpose and usage. Every word earns its place, with no wasted information, making it easy for an agent to parse and understand quickly.
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 the tool's low complexity (0 parameters, no output schema, no annotations), the description is complete enough for basic understanding. However, it lacks details on output behavior or error handling, which could be useful for a diagnostic tool. This makes it minimally viable but not fully comprehensive in context.
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 tool has 0 parameters, and the schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description doesn't need to compensate for any parameter gaps, and it appropriately focuses on the tool's purpose without unnecessary parameter information.
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 clearly states the tool's purpose with specific verbs ('check', 'diagnose') and resources ('server health', 'database connectivity', 'API availability'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_database_info' or 'get_package', which also provide system information, so it doesn't reach the highest score.
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?
The description provides clear context for when to use this tool ('Use to diagnose connection issues'), which helps guide the agent. However, it doesn't specify when not to use it or name alternatives among the sibling tools, such as distinguishing it from 'get_database_info' for more detailed database checks, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported package registries and ecosystems with package counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying it's likely read-only and non-destructive, but doesn't confirm this or add context about rate limits, authentication needs, or what 'supported' means. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose without any fluff or unnecessary elaboration. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks behavioral context (e.g., safety, performance) and usage guidance relative to siblings. For a basic list tool, it meets minimum viability but could be more helpful.
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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately avoids redundant information about non-existent parameters.
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 clearly states the action ('List') and the target resource ('supported package registries and ecosystems with package counts'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate itself from sibling tools like 'get_database_info' or 'search_packages', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_database_info' (which might include registry info) or 'search_packages' (which might involve registries). There's no mention of prerequisites, context, or exclusions, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find packages by PURL (pkg:npm/lodash) or GitHub URL. Use when given a package URL or repo link instead of ecosystem+name.
| Name | Required | Description | Default |
|---|---|---|---|
| purl | No | Package URL, e.g. pkg:npm/lodash, pkg:pypi/requests | |
| ecosystem | No | Package ecosystem | |
| name | No | Package name | |
| repository_url | No | GitHub/GitLab URL to find associated packages |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, what happens with multiple matches, error conditions, rate limits, or authentication needs. For a lookup tool with zero annotation coverage, this leaves significant behavioral gaps.
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?
Two concise sentences with zero waste. The first states the purpose and inputs, the second provides usage guidance. Every word earns its place, and the information is front-loaded appropriately.
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?
For a lookup tool with 4 parameters, 100% schema coverage, but no annotations or output schema, the description provides adequate purpose and usage guidance but lacks behavioral context. It's complete enough for basic understanding but leaves gaps about how the tool actually behaves and what it returns.
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?
Schema description coverage is 100%, so the schema already documents all 4 parameters. The description mentions PURL and GitHub URL, which maps to purl and repository_url parameters, but doesn't add meaningful semantics beyond what the schema provides. The baseline of 3 is appropriate when schema does the heavy lifting.
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 clearly states the verb 'Find' and resource 'packages', specifies the input types (PURL or GitHub URL), and distinguishes from siblings by indicating this is for when given a URL instead of ecosystem+name. This provides specific differentiation from tools like get_package that likely use different parameters.
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?
The description explicitly states 'Use when given a package URL or repo link instead of ecosystem+name', providing clear when-to-use guidance and implicitly suggesting alternatives (ecosystem+name based tools like get_package). This gives the agent specific context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find packages by keyword across all ecosystems. Use when looking for packages that do something specific.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keywords to search for | |
| limit | No | Max results (default 20) |
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 states the tool 'finds' packages, implying a read-only operation, but doesn't disclose other traits like whether it requires authentication, has rate limits, returns paginated results, or what the output format is. For a search tool with zero annotation coverage, this is a significant gap, as the agent lacks crucial operational context.
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 appropriately sized and front-loaded: two concise sentences that directly state the purpose and usage guidelines. Every sentence earns its place by providing essential information without redundancy or fluff, making it efficient and easy for an agent to parse.
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 the tool's moderate complexity (a search function with 2 parameters) and no output schema, the description is partially complete. It covers the basic purpose and usage but lacks details on behavioral traits (e.g., output format, pagination) and doesn't leverage annotations (none provided). This is adequate as a minimum viable description but has clear gaps in operational context.
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 description mentions 'keyword' which aligns with the 'query' parameter, but it doesn't add meaning beyond what the input schema provides. The schema description coverage is 100%, with clear descriptions for 'query' and 'limit', so the baseline is 3. The description doesn't elaborate on parameter usage, syntax, or constraints, so it doesn't compensate or add extra value.
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 clearly states the tool's purpose: 'Find packages by keyword across all ecosystems.' It specifies the verb ('Find'), resource ('packages'), and scope ('across all ecosystems'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'lookup_package' or 'get_package', which might have overlapping functionality, so it doesn't reach a score of 5.
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?
The description provides clear context for usage: 'Use when looking for packages that do something specific.' This gives a general guideline on when to invoke the tool. However, it doesn't mention when not to use it or name alternatives among sibling tools (e.g., 'lookup_package' for direct lookups vs. keyword searches), so it lacks explicit exclusions or comparisons, preventing a score of 5.
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.
get_database_infoget_packageget_package_advisoriesget_package_dependentsget_package_repositoryget_package_versionshealth_checklist_registrieslookup_packagesearch_packagesScored across 10 tools
Every tool has a clearly distinct purpose with no overlap: get_database_info for database stats, get_package for general package info, get_package_advisories for security, get_package_dependents for reverse dependencies, get_package_repository for GitHub stats, get_package_versions for version history, health_check for server status, list_registries for ecosystem overview, lookup_package for URL-based queries, and search_packages for keyword searches. The descriptions explicitly state when to use each tool, eliminating any ambiguity.
Tool names follow a highly consistent verb_noun pattern throughout: get_database_info, get_package, get_package_advisories, get_package_dependents, get_package_repository, get_package_versions, health_check, list_registries, lookup_package, and search_packages. All use snake_case with clear verbs (get, list, lookup, search, health_check) and specific nouns, making the naming predictable and easy to understand.
With 10 tools, the count is well-scoped for the server's purpose of providing package data from Ecosyste.ms. Each tool earns its place by covering distinct aspects like package info, security, dependencies, versions, and search, without being too sparse or bloated. This aligns with typical effective tool sets (3-15 tools) for such a domain.
The tool surface provides complete coverage for the domain of package data analysis. It includes core operations like retrieving package info, security advisories, dependencies, repository stats, and versions, plus utilities for health checks, registry listing, URL lookups, and keyword searches. There are no obvious gaps; agents can perform comprehensive package-related tasks without dead ends.
Dev-registry data: npm/PyPI/Docker/VS Code packages, dep graphs, vulns, 50+ ecosystems.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Detect malicious or vulnerable npm packages: registry search, OSV.dev and GitHub advisory lookups