Pay-per-call x402 npm and PyPI package metadata, versions, search, download counts.
Scored across 6 tools
Each tool targets a distinct resource and action: npm_package vs npm_version separate general card from version-specific artifact details, and pypi_project vs pypi_release do the same for PyPI. Searches are ecosystem-specific and pypi_search is explicitly name resolution, not discovery. No meaningful overlap exists.
All names follow a consistent ecosystem_entity pattern (npm_package, npm_search, npm_version, pypi_project, pypi_release, pypi_search). Verb/entity choices are predictable and aligned across both registries.
Six tools for two package registries is well-scoped: three per ecosystem covering search, project-level metadata, and version-level metadata. Each tool earns its place with no redundancy.
The surface covers search, project metadata, and specific version metadata for both npm and PyPI, which is the core read-only lookup workflow. A minor gap is the lack of an explicit tool to enumerate all versions or releases, though agents can often work around this if only the latest or a known version is needed.
Use when you need the public npm registry card for a package (scoped or unscoped): returns description, homepage, bugs URL, repository, license, keywords, maintainers as names only (emails stripped), number of versions, latest dist-tag version, created/modified times, and last-week download count from the official downloads API. Private packages are not supported. Paid tool: x402 USDC on Base, $0.002 per successful call; call without payment to receive the PaymentRequired object.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | npm package name, optionally scoped (@scope/name). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, it discloses the private-package limitation, the paywall model ($0.002 USDC on Base x402), and the exact unauthenticated failure mode (call without payment returns a PaymentRequired object). It also notes maintainer emails are stripped and that download counts come from the official downloads API over a last-week window.
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?
Front-loaded with the usage trigger, then the return payload, then constraints and pricing — a logical order with essentially no filler. The enumerated return-field list is long but each item earns its place because no output schema exists.
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?
With no output schema, the description carries the return-value burden fully, listing the fields returned. It also covers the auth/payment flow and the unsupported case, leaving nothing an agent needs in order to call this correctly undocumented.
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% and the single `name` parameter is fully documented there, including the scoped form. The description's "(scoped or unscoped)" restates rather than extends the schema, so baseline 3 is appropriate.
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 states a specific resource (the public npm registry card for a package) and enumerates exactly what it returns, which cleanly separates it from npm_search and npm_version in practice. It never names a sibling or explicitly contrasts with one, so differentiation is inferential rather than stated.
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?
"Use when you need the public npm registry card for a package (scoped or unscoped)" gives a clear trigger condition, and "Private packages are not supported" plus the payment note act as when-not constraints. No alternative tool is named for cases like searching or version-specific lookups, so routing is only partially guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use to discover npm packages by keyword or name: returns up to 20 hits with name, version, description, keywords, date, and the registry search score. Publisher and maintainer emails are never returned (names/usernames only when present). Paid tool: x402 USDC on Base, $0.003 per successful call; call without payment to receive the PaymentRequired object.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search text. | |
| limit | No | Max results (1-20). | 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, openWorld, idempotent), and the description adds genuinely new behavior: the result cap, the exact returned fields, the privacy guarantee that publisher/maintainer emails are never returned, and the paid x402/USDC flow including what happens on an unpaid call. This is exactly the value-add the annotations cannot provide.
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 sentences, purpose front-loaded, then return shape, then payment mechanics — no filler. The second sentence is long and packs privacy plus pricing into one block, but every clause carries information.
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?
With no output schema, the description correctly compensates by listing returned fields, and it covers the non-obvious paid-invocation path. Remaining gaps are minor: no pagination/offset guidance beyond the cap and no error behavior beyond the payment case.
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 coverage is 100% ('Search text.' and 'Max results (1-20).'), so the schema carries the parameter burden; baseline is 3. The description lightly enriches q by saying it accepts a keyword or name and restates the 20-result cap, but adds no syntax, matching, or ranking detail beyond the schema.
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?
States a specific verb+resource ('discover npm packages by keyword or name') and enumerates the returned fields, so the agent knows exactly what this tool produces. It is clearly a keyword/name search rather than a single-record lookup, which implicitly separates it from npm_package/npm_version, but no sibling is named explicitly.
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?
'Use to discover npm packages by keyword or name' gives clear context for when to reach for it, and the payment note ('call without payment to receive the PaymentRequired object') gives actionable invocation guidance. However, it never states when NOT to use it or which sibling to prefer for exact-name/version lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need the exact published artifact for an npm version: dependencies, optionalDependencies, peerDependencies, bundledDependencies, engines, os/cpu, dist (tarball URL, integrity, shasum, unpacked size), and the version publish time. Give "latest" as version to resolve the current dist-tag. Paid tool: x402 USDC on Base, $0.002 per successful call; call without payment to receive the PaymentRequired object.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | npm package name. | |
| version | Yes | Exact version or "latest". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/open-world, so the bar is lower, and the description clears it by adding the payment model that nothing else discloses: paid tool, x402 USDC on Base, $0.002 per successful call, and that an unpaid call returns a PaymentRequired object. That is exactly the kind of operational context an agent needs before invoking.
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?
Front-loaded with the usage trigger, followed by the field inventory and the payment caveat. The field enumeration is dense but each entry tells the agent what it will receive, so no sentence is filler.
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?
No output schema exists, so the description carries the return-value burden and does so by listing the artifact fields. Both required parameters are addressed, and the payment/auth flow and dist-tag resolution are covered, leaving nothing an agent needs missing.
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?
With 100% schema coverage the baseline is 3, and the description adds the semantic that passing "latest" performs dist-tag resolution rather than being treated as a literal version string. That is a meaningful behavioral nuance beyond the schema's bare "Exact version or 'latest'".
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?
States a concrete verb (retrieve the exact published artifact) and a precise resource (an npm version), and enumerates what that artifact contains (deps, engines, dist, publish time). This implicitly separates it from package-level siblings like npm_package, but no sibling is named explicitly, so it stops just short of 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?
"Use when you need the exact published artifact for an npm version" gives a clear triggering context, and the note that "latest" resolves the current dist-tag is actionable guidance. However, it never states when to prefer npm_package or npm_search instead, so there are no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need the public PyPI project card: summary, home_page, project_urls, license, requires_python, a subset of classifiers, requires_dist (capped), current version, and yank status. Author/maintainer emails are omitted or redacted; only display names remain when present. Paid tool: x402 USDC on Base, $0.002 per successful call; call without payment to receive the PaymentRequired object.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | PyPI project name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/openWorld/idempotent, so the description carries the real behavioral load and does so well: it discloses data redaction (emails omitted, only display names), truncation (requires_dist capped), yank-status reporting, and the entire payment model (x402 USDC on Base, $0.002 per successful call, PaymentRequired object returned on unpaid calls). That is substantial context an agent cannot get from the structured fields.
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?
Front-loaded with the usage trigger, then a tight field enumeration, then redaction and payment caveats — every clause carries information. The field list reads as a dense run-on, which slightly blurs scanability but not at the cost of wasted content.
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?
With no output schema, the description compensates by enumerating the returned fields, and it covers privacy (email redaction), data capping (requires_dist), and billing/auth behavior. An agent has everything needed to decide to call it and to interpret the response.
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?
There is a single `name` parameter with 100% schema description coverage, so the schema already documents it fully. The description adds no syntax, format, or normalization guidance beyond what the schema provides, which is the baseline-3 case for high coverage.
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?
Names a specific verb-like action (fetch the public PyPI project card) and enumerates exactly which fields are returned, which cleanly separates it from the release-level sibling pypi_release and the search siblings. An agent can identify the resource and scope without opening the schema.
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?
"Use when you need the public PyPI project card" gives a clear triggering condition. It does not, however, name alternatives (e.g. pypi_release for version-level data or pypi_search for discovery) or state when NOT to use it, so routing between siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you need the published artifacts for a specific PyPI version: each file with filename, packagetype (sdist/bdist_wheel…), size, upload time, yank flags, digests (sha256/blake2b/md5) and download URL. Give "latest" as version to use the project's current version. Paid tool: x402 USDC on Base, $0.002 per successful call; call without payment to receive the PaymentRequired object.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | PyPI project name. | |
| version | Yes | Exact version or "latest". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only/idempotent/open-world safety, and the description goes well beyond them by disclosing the paid access model: x402 USDC on Base, $0.002 per successful call, and the fact that an unpaid call returns a PaymentRequired object. That payment/auth behavior is not derivable from any structured field and is exactly the kind of context an agent needs.
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?
Three sentences, front-loaded with the 'Use when' trigger, then the version convention, then the payment caveat. The field enumeration is a bit long but each item is a real return attribute and no sentence is redundant filler.
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?
There is no output schema, so the description's enumeration of returned file fields carries the return-value burden and does so concretely. Combined with the payment disclosure and the required-parameter guidance, an agent has everything needed to call this correctly.
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% and both parameters are documented there, so the baseline is 3. The description restates the 'latest' convenience value already present in the schema and adds no syntax, format, or constraint details beyond it.
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?
States a specific verb + resource: retrieving published artifacts (files) for a specific PyPI version, with an explicit enumeration of what each file carries (filename, packagetype, size, digests, URL). The scope 'for a specific PyPI version' implicitly separates it from pypi_project and pypi_search, but no sibling is named outright.
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?
"Use when you need the published artifacts for a specific PyPI version" gives a clear triggering condition, and the 'latest' shortcut tells the agent how to handle the common case. No explicit when-not or named alternative (e.g., pypi_project for project-level metadata) is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when you have a likely PyPI project name (or a few tokens) and need to resolve it to live projects: tries the query as-is, PEP 503 normalization (lowercase, [-_.] → -), and hyphen/underscore/dot variants, then returns up to "limit" matching projects with summary, version, requires_python and license. This is name resolution, not full-text discovery — prefer exact package names when known. Author emails are redacted. Paid tool: x402 USDC on Base, $0.003 per successful call; call without payment to receive the PaymentRequired object.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Project name or name-like query. | |
| limit | No | Max results (1-20). | 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing the exact resolution algorithm (as-is, PEP 503 normalization, [-_.] variants), the redaction of author emails, and the paid-call mechanics including price, currency, and how to obtain the PaymentRequired object. This is unusually rich behavioral disclosure.
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?
Front-loaded with the usage condition and packs algorithm, return fields, redaction, and payment into two dense sentences with no filler. The payment clause is long but operationally necessary, so it earns its place.
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?
With no output schema, the description compensates by enumerating returned fields (summary, version, requires_python, license), and it covers the non-obvious auth/payment path. Nothing needed to call it correctly is missing.
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 coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining how the 'q' value is interpreted (normalization and variant expansion) and that 'limit' caps returned matching projects — behavior the schema text alone does not convey.
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?
States a specific verb+resource (resolve a PyPI project name to live projects) and immediately scopes it against the sibling category by declaring 'This is name resolution, not full-text discovery,' which separates it from npm_search-style tools.
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?
'Use when you have a likely PyPI project name (or a few tokens)' gives clear triggering context, and 'prefer exact package names when known' adds a preference rule. However, it never names the concrete alternative tools (pypi_project, npm_search) an agent should fall back to.
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.
npm_packagenpm_searchnpm_versionpypi_projectpypi_releasepypi_searchPay-per-call x402 arXiv paper search, metadata, abstracts, and category listings.
Pay-per-call DNS/TLS truth and npm/PyPI breakage checks via x402. No account or API key.
Abandonment checks for WordPress, npm and PyPI packages, priced per call.
x402-gated safety checker for npm/PyPI packages before you npm install / pip install.
Add one secure layer between your agents and this server.