Open-source package & CVE security scanner for coding agents. Checks npm, PyPI, or Rust crates against Google OSV.dev for known security vulnerabilities, deprecation status, and latest stable version.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Package name (e.g., 'lodash', 'express', 'requests', 'tokio') | |
| version | No | Optional specific version to audit (defaults to latest version) | |
| ecosystem | No | Package registry ecosystem (default: 'npm') |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the data source (Google OSV.dev) and the kinds of results returned (vulnerabilities, deprecation status, latest stable version), which is useful. However it omits whether the call is read-only/network-dependent, any rate limits or auth requirements, and how unknown packages are handled.
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 tight sentences with the identifying noun phrase front-loaded ('Open-source package & CVE security scanner'), followed by the concrete data source and outputs. No filler; only minor redundancy between the title-like opener and the rest.
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 simple three-parameter lookup tool with no output schema, the description covers what it queries, where it queries, and roughly what comes back. Only the operational details (read-only nature, failure modes for unknown packages) are 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 description coverage is 100%, and each field is already documented (name examples, version optionality, ecosystem enum). The description's mention of npm/PyPI/Rust mirrors the enum but adds no default or format detail beyond the schema, so baseline 3 applies.
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 and resource: an open-source package/CVE scanner that checks npm, PyPI, and Rust crates against Google OSV.dev. This is concrete and distinguishable from siblings like domain_intel or github_intel, though it never explicitly contrasts itself with the nearby security_audit tool.
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?
"For coding agents" gives loose context for who would call it, but there is no statement of when to prefer this over security_audit or the other intel tools, and no exclusions or prerequisites (e.g., offline packages, private registries). Usage must be inferred from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.