FiatDock

npm / PyPI package safety and maintenance ($0.0027)

package_intel

Read-onlyIdempotent

PAID ($0.0027 USDC via x402). Before adding a dependency: give an npm or PyPI package (and optionally an exact version; default latest). Returns every vulnerability OSV.dev lists for that version (ids, CVE aliases, severity as its database labels it, fixed versions), whether it is deprecated (npm) or yanked (PyPI), licence, https source repository, publish dates, latest version, last week's downloads, runtime dependency and maintainer counts, and risk flags from a stated rule list. It reads registry metadata and advisories, not the code; 'no vulnerabilities' means none known to OSV. An unknown package or version, or an outage, answers 4xx/502 and is not charged. Without payment this returns the 402 challenge; the fiatdock-mcp npm package pays automatically. Any answer the tool cannot produce is >= 400 and is NOT charged.

Input Schema

Name	Required	Description
`name`	No	The package name: an npm package (lodash, @types/node) or a PyPI project (requests, Django)
`payment`	No	Base64 of a single x402 v2 PaymentPayload (EIP-3009 transferWithAuthorization on Base USDC). OMIT it on the first call: the 402 you get back carries `howToPay.payloadTemplate` — the exact envelope to fill in — plus the price and the EIP-712 domain. Send it on the second call to complete the purchase; it is forwarded as the PAYMENT-SIGNATURE header, never as body data. Nothing is charged for the 402 itself, and a call that fails after payment settles nothing.
`version`	No	An exact published version to analyse (4.17.20, 2.31.0). Omit for the latest release; ranges like ^4 are refused
`ecosystem`	No	Which registry the name is on: npm (default) or pypi

Output Schema

Name	Required	Description
`asOf`	Yes	ISO time of the oldest upstream read this answer used
`name`	Yes	The package name as the registry spells it
`note`	Yes	How to read the answer, its rules and limits, and the data attribution
`source`	Yes	Where the data came from
`license`	Yes	The declared licence (SPDX expression where given), or null when none is declared
`version`	Yes	The version analysed (the latest when none was named)
`homepage`	Yes	The declared homepage, or null
`isLatest`	Yes	True when the analysed version is the latest
`defaulted`	No	Present only when the body named no field: which package the answer is for, and why
`ecosystem`	Yes	The registry: npm or pypi
`riskFlags`	Yes	Flags from a stated rule list (see note): malicious_package, deprecated, yanked, known_vulnerabilities, high_or_critical_vulnerability, newer_version_available, no_release_in_2_years, very_low_downloads, no_license, no_repository
`deprecated`	Yes	npm: the deprecation message of this version; PyPI: 'yanked: <reason>' when the release is yanked; null otherwise
`osvRecords`	Yes	OSV records returned before the same flaw from two databases was folded into one row
`repository`	Yes	The declared source repository as an https URL, or null
`description`	Yes	The package's own one-line description
`publishedAt`	Yes	ISO time the analysed version was published (null when the registry could not be read for dates)
`latestVersion`	Yes	The registry's latest release (npm's `latest` dist-tag; PyPI's current version)
`dependencyCount`	Yes	Runtime dependencies this version declares (npm `dependencies`; PyPI `requires_dist` entries not tied to an extra); null when undeclared metadata makes it unknown
`vulnerabilities`	Yes	Known vulnerabilities OSV.dev lists for THIS version, most severe first
`maintainersCount`	Yes	Accounts allowed to publish (npm's current maintainers; PyPI's owners and maintainers)
`downloadsLastWeek`	Yes	Downloads in the last 7 days (npm: api.npmjs.org; PyPI: pypistats.org last_week); null when the counter did not answer
`latestPublishedAt`	Yes	ISO time the latest release was published
`vulnerabilityCount`	Yes	Number of vulnerabilities listed (the same flaw published by two databases counts once)
`daysSinceLatestRelease`	Yes	Whole days since the latest release was published

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 9, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/idempotent annotations: it discloses the paid x402 flow, that failures (unknown package, outage) return 4xx/502 and are NOT charged, that the 402 challenge is free, that it reads registry metadata rather than code, and that 'no vulnerabilities' only means none known to OSV. This is exactly the behavioral 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads cost and purpose effectively, but the 'not charged' guarantee is repeated three times across separate sentences, adding length without new information. Dense yet navigable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present the returns need not be explained, yet the description enumerates them anyway and fully covers the payment lifecycle, error/charging behavior, and data sources. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so name, version, ecosystem and payment are already documented in the schema; the description largely restates that (version defaults to latest, ranges refused). Baseline 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: it returns OSV.dev vulnerabilities, deprecation/yank status, licence, repo, download stats and risk flags for a named npm or PyPI package. No sibling tool covers package registries, so the agent can route here unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Before adding a dependency' gives a concrete trigger for use, and the payment mechanics (omit payment on first call, send it on the second, fiatdock-mcp pays automatically) tell the agent how to invoke it. There are no exclusions or competing alternatives named, but none exist among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All FiatDock tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.