DepScope is a package intelligence MCP server providing 22 tools across 19 ecosystems, helping AI agents make safe, informed dependency decisions by preventing hallucinations, catching vulnerabilities, and stopping supply-chain attacks.
Security & Safety
Malware detection — Check packages against OpenSSF/OSV malicious package lists
Typosquat detection — Identify if a package name is a typosquat (e.g. lodsh vs lodash)
Vulnerability lookup — Retrieve CVEs/OSV advisories with CVSS scores and fix versions
Bulk pre-flight check — Batch validate multiple packages at once (existence, typosquats, malicious flags)
Package Intelligence
Full health report — Machine-readable JSON with score, vulnerabilities, maintainers, and recommendation
LLM-optimized brief — Plain-text summary with ~75% fewer tokens and a SAFE/AVOID/URGENT/MALICIOUS verdict
Health score — Quick 0–100 score for go/no-go decisions
Package existence check — Boolean guard against hallucinated package names
Latest version — Latest published version and deprecation status
Install commands — Canonical install commands across package managers
Vulnerability & Version Management
Pin safe version — Find the highest version below a chosen CVE severity tier within semver constraints
Breaking changes — List breaking changes between two major versions
Migration path — Prescriptive plan (with code diffs) for switching to a replacement package
Known bugs — Non-CVE bugs for a specific package version
Project & Stack Analysis
Scan project — Audit a full dependency list with per-package health and prioritized actions (REMOVE NOW / URGENT / REPLACE / REVIEW)
Compare packages — Side-by-side comparison of 2–10 packages (health, vulns, downloads, maintainers)
Check compatibility — Verify if a multi-package version combination works together
Find alternatives — Curated replacements for deprecated or unhealthy packages
Trust, Discovery & Support
Trust signals — Maintainer bus factor, OpenSSF Scorecard, quality metrics, and SLSA/Sigstore provenance
Resolve errors — Map error messages or stack traces to verified fixes
Trending packages — Live trending packages with rank-delta and weekly growth metrics
Submit tickets — Report bugs, security findings, anomalies, or partnership inquiries
Provides package intelligence for the CocoaPods ecosystem, including vulnerability checks, health scores, alternatives, and lockfile ingestion.
Provides package intelligence for the Composer ecosystem, including vulnerability checks, health scores, alternatives, and lockfile ingestion.
Provides package intelligence for the Homebrew ecosystem, including vulnerability checks, health scores, alternatives, and lockfile ingestion.
Provides package intelligence for the JSR (JavaScript Registry) ecosystem, including vulnerability checks, health scores, alternatives, and lockfile ingestion.
Provides package intelligence for the Julia ecosystem, including vulnerability checks, health scores, alternatives, and lockfile ingestion.
Provides package intelligence for the npm ecosystem, including vulnerability checks, health scores, alternatives, and lockfile ingestion.
Provides package intelligence for the NuGet ecosystem, including vulnerability checks, health scores, alternatives, and lockfile ingestion.
Provides package intelligence for the PyPI ecosystem, including vulnerability checks, health scores, alternatives, and lockfile ingestion.
Provides package intelligence for the RubyGems ecosystem, including vulnerability checks, health scores, alternatives, and lockfile ingestion.
Provides package intelligence for the Swift ecosystem, including vulnerability checks, health scores, alternatives, and lockfile ingestion.
Package Intelligence for AI Agents. Stops AI coding agents (Claude, ChatGPT, Cursor, Windsurf, Copilot, Cline) from installing hallucinated, deprecated, or malicious packages across 19 ecosystems.
→ Live at depscope.dev · 8.4M+ packages · 42K+ vulnerabilities (99% EPSS-enriched) · zero auth · free
{
"mcpServers": {
"depscope": {
"url": "https://mcp.depscope.dev/mcp"
}
}
}{
"mcpServers": {
"depscope": {
"command": "npx",
"args": ["-y", "depscope-mcp"]
}
}
}The MCP server source is at cuttalo/depscope-mcp (AGPL-3.0).
Related MCP server: mcp-dep-tools
22 MCP tools across 19 package ecosystems:
npm · pypi · cargo · go · composer · maven · nuget · rubygems · pub · hex · swift · cocoapods · cpan · hackage · cran · conda · homebrew · jsr · julia
Tool | Purpose |
| Full safety check: deprecation · vulnerabilities · health · recommendation |
| Malicious-package detector |
| Typosquat detection vs popular names |
| Hallucination detector (404 = LLM invented it) |
| 0–100 health score with breakdown |
| Vulnerabilities + severity scoring |
| Suggested alternatives for deprecated/abandoned packages |
| Major-version migration notes |
| Known issues for a package |
| Side-by-side comparison |
| Stack-level compatibility check |
| Error message → likely cause + fix |
| Verified install command for the target ecosystem |
| Latest stable version + maturity signal |
| Suggested safe version pin |
| Multi-signal trust score |
| Step-by-step upgrade plan |
| Bulk scan of dependency manifests |
| Fast pre-flight filter for batches |
| Trending packages by ecosystem |
| Compact LLM-friendly summary |
| Report a missing package or false positive |
Same data, plain HTTPS — no MCP client needed.
curl https://depscope.dev/api/check/npm/lodash
curl https://depscope.dev/api/check/pypi/requests
curl https://depscope.dev/api/check/cargo/serdeFull reference: depscope.dev/integrate
LLMs frequently invent package names that look real but don't exist (fastapi-turbo, lodahs, tokio-stream-extras). When an agent tries to install one, it can hit an attacker's typosquat. DepScope verifies every package before install.
Read more: depscope.dev/why
Free. No auth required. Generous rate limits.
If you need higher quotas, SLA, or on-prem deployment, contact us at depscope@cuttalo.com.
This repository is a landing page with documentation only.
MCP server (client SDK) — open source, AGPL-3.0: → cuttalo/depscope-mcp → npm: depscope-mcp
Backend (API + intelligence layer) — proprietary, hosted at depscope.dev.
This split lets us keep the client free, auditable, and community-extensible while sustaining the infrastructure that powers it.
Homepage · depscope.dev
API docs · depscope.dev/integrate
MCP server source · cuttalo/depscope-mcp
npm · depscope-mcp
Glama listing · glama.ai/mcp/servers/cuttalo/depscope
Awesome MCP · punkpeye/awesome-mcp-servers
This README and accompanying landing files: CC-BY-4.0. MCP client SDK: AGPL-3.0 (see cuttalo/depscope-mcp). Backend service: proprietary.
Built by Cuttalo srl · Italy 🇮🇹
Fast pre-flight filter for a batch of (ecosystem, package) pairs. DB-only, <100ms for 100 items. USE WHEN: about to emit npm install a b c … or pip install a b c … — catches hallucinated names, stdlib, typos, and known-bad in ONE call. NOT a dep-tree audit (use scan_project for that). RETURNS: per-item {status: exists|stdlib|malicious|typosquat_suspect|historical_incident|unknown}.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds value by stating it is 'DB-only, <100ms for 100 items' and listing possible return statuses, which are not in annotations.
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, front-loads the purpose, and uses clear sections (USE WHEN, NOT, RETURNS) with no redundant sentences.
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?
Despite no output schema, the description specifies the return format per item with enumerated statuses. It also mentions performance and max items, making it complete for typical usage.
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 0%, but the description explains that the tool processes a batch of (ecosystem, package) pairs and provides context for its use. Although it does not detail the schema fields, the enum for ecosystem is self-explanatory and the purpose is clear from the usage context.
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 it is a 'fast pre-flight filter for a batch of (ecosystem, package) pairs,' specifying the verb (filter/check) and resource (batch of packages). It distinguishes itself from `scan_project` by noting it is not a dep-tree audit.
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 says 'USE WHEN: about to emit npm install...' and 'NOT a dep-tree audit (use scan_project for that),' providing clear context for when to use and when to use an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is this specific multi-package version combo verified to work together? USE WHEN: pinning a stack (next@15 + react@19 + node@22); before recommending a version matrix. RETURNS: {compatible, conflicts[], notes}.
| Name | Required | Description | Default |
|---|---|---|---|
| packages | Yes | Package -> version map, e.g. {"next":"15","react":"19"}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds return format {compatible, conflicts[], notes}, providing behavioral insight beyond annotations.
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: first states purpose, second provides usage and return format. No wasted words, front-loaded with key 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?
For a simple read-only tool with rich annotations, clear schema, and no output schema needed, the description fully covers purpose, usage, and return format.
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% with a clear description for the 'packages' parameter. Description only reiterates 'Package -> version map', adding minimal value 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?
Description explicitly states the tool checks if a multi-package version combo is verified to work together, clearly distinguishing it from siblings like check_package (single package) or find_alternatives.
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?
Description provides explicit use cases: when pinning a stack or before recommending a version matrix. Does not explicitly mention when not to use, but context and sibling list help differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Supply-chain malware check against OpenSSF/OSV. USE WHEN: about to suggest install of an unvetted/unfamiliar package; name came from a blog/tutorial. Call BEFORE check_package for untrusted pkgs. RETURNS: {is_malicious, threat_tier, source}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by specifying the return object structure ({is_malicious, threat_tier, source}), which is not in annotations or schema.
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?
Extremely concise: three sentences covering purpose, usage, and returns. No wasted words, front-loaded with the most important 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?
Given the annotations and simple schema (2 required params), the description is largely complete. It covers what the tool does, when to use it, and what it returns. It lacks error handling details but is sufficient for most agents.
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 0%, and the description does not explain the 'ecosystem' enum or 'package' parameter beyond their names and schema. This fails to compensate for the low coverage, though the parameters are somewhat self-explanatory.
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 the tool checks for supply-chain malware against OpenSSF/OSV and provides specific use cases. It does not explicitly distinguish from sibling tools like check_typosquat or check_package, but it does indicate an ordering relative to check_package.
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?
Provides explicit when-to-use guidance ('USE WHEN') and ordering advice ('Call BEFORE check_package'). Does not cover when not to use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full machine-readable JSON report (~2k tokens). USE WHEN: you need to programmatically parse specific fields (CI gating, UI, sub-field extraction). Otherwise prefer get_package_prompt. RETURNS: {package, health:{score}, vulnerabilities[], latest, deprecated, maintainers, recommendation}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes | Package name (e.g. 'express', 'fastapi', 'serde'). | |
| version | No | Specific version (optional; default = latest). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint false, idempotentHint, openWorldHint. Description adds context about report token size (~2k tokens) and return structure, which is useful beyond annotations. No contradictions.
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?
Extremely concise: one sentence on purpose, one on usage, one on return. No wasted words. Front-loaded with key 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?
Given no output schema, the description provides a detailed return structure. Annotations cover safety. Points to sibling for alternative use. Enough for agent to select and use 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 67% (2 of 3 parameters have descriptions). The description does not add any new information about parameters beyond the schema, so it adds marginal value. 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 explicitly states it returns a 'Full machine-readable JSON report' and distinguishes from sibling get_package_prompt by noting when to use each. The verb 'check' aligns with the tool name.
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?
Clearly states 'USE WHEN: you need to programmatically parse specific fields (CI gating, UI, sub-field extraction). Otherwise prefer get_package_prompt.' Provides explicit when-to-use and when-not-to-use with alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Typosquat detector. USE WHEN: name differs from a well-known package by 1-2 chars (lodsh, reqeusts); copy-paste from unreliable source; downloads near zero but name looks familiar. RETURNS: {is_typosquat, likely_target, confidence}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, destructiveHint false, idempotentHint, and openWorldHint. The description adds the return value structure {is_typosquat, likely_target, confidence}, providing behavioral context beyond annotations. No contradictions.
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 very concise: three short sentences that front-load the main purpose, usage guidelines, and return structure. Every sentence adds value with no redundancy or 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?
Given the tool has only two parameters and no output schema, the description covers the essential aspects: purpose, when to use, and return format. The only gap is parameter guidance, which is partially addressed by the schema itself. Overall sufficient for a detection 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 two parameters (ecosystem and package) with 0% schema description coverage from the description. The description does not explain what these parameters represent or how to use them. For a tool with no parameter info in description, a low score is warranted.
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 'Typosquat detector' and provides specific examples of typosquatting patterns (e.g., 'lodsh', 'reqeusts'). It distinguishes from sibling tools like check_malicious or check_package by focusing solely on name similarity detection.
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 lists three use cases with specific conditions: name differs from a well-known package by 1-2 chars, copy-paste from unreliable source, and downloads near zero with familiar name. However, it does not specify when not to use the tool or mention alternative tools for related checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Side-by-side comparison (health, vulns, downloads, maintainers, last release) of 2-10 packages in the same ecosystem. USE WHEN: 'X vs Y' / 'should I pick X or Y'. RETURNS: table-shaped JSON, one row per package.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| packages | Yes | Package names to compare, e.g. ['express','fastify','hono']. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, which the description does not contradict. The description adds that the tool returns table-shaped JSON with one row per package, providing useful behavioral context. It could mention ordering or error handling but is sufficient.
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 plus concise 'USE WHEN' and 'RETURNS' hints. Every part adds value, and the main action is front-loaded. No redundant or unnecessary words.
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 (2 parameters, no output schema, no nested objects), the description covers purpose, usage, and output format. It does not mention error handling or edge cases, but the annotations provide safety cues. Overall, it is sufficient for an agent to invoke 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?
The description reinforces the ecosystem parameter (same ecosystem) and the packages parameter (2-10 packages). The schema already includes an example for packages and an enum for ecosystem. The description adds clarity by linking the parameters to the comparison context, exceeding schema 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?
The description clearly states the tool performs a side-by-side comparison of packages, listing specific attributes (health, vulns, downloads, etc.) and specifies the range 2-10 packages in the same ecosystem. This distinguishes it from sibling tools like check_package (single package) or find_alternatives.
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 includes explicit 'USE WHEN' guidance for comparative queries ('X vs Y' / 'should I pick X or Y'), making the intended usage clear. It does not explicitly exclude single-package checks, but the context of siblings and the tool's name imply that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inbound ticket: bug/listing/security/anomaly/partnership. USE WHEN: reporting wrong data (bug), requesting a new pkg/ecosystem index (listing), disclosing a DepScope security issue (security), flagging a concrete mismatch in another tool's output vs. authoritative source (anomaly — provide tool_called+observed+expected), or partnership/press (partnership). RETURNS: {ticket_id} or {anomaly_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Ticket category. `anomaly` routes to structured anomaly triage (requires tool_called/observed/expected). | |
| No | Reply-to email of the requester (required for bug/listing/security/partnership). | ||
| subject | No | Short subject line (3-200 chars). | |
| body | No | Message body (10-8000 chars). Be specific: include package name, ecosystem, error trace, repro steps when applicable. | |
| name | No | Sender display name (optional). | |
| company | No | Company / organization (optional). | |
| tool_called | No | For kind=anomaly: DepScope tool that produced the anomaly (e.g. check_package, get_migration_path). | |
| ecosystem | No | For kind=anomaly: ecosystem of the involved package, if any. | |
| package | No | For kind=anomaly: package name involved, if any. | |
| version | No | For kind=anomaly: package version involved, if any. | |
| observed | No | For kind=anomaly: what DepScope returned (1-1500 chars). | |
| expected | No | For kind=anomaly: what you expected to see (1-1500 chars). Be concrete. | |
| evidence_url | No | For kind=anomaly: URL to authoritative source (registry page, GHSA, CVE, repo, ...) supporting your expectation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, and the description adds return value details (ticket_id or anomaly_id). The description is consistent with annotations but does not add significant behavioral context beyond what is implied.
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 (two sentences with clear enumeration) and front-loaded with purpose. Every part earns its place with no waste.
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 complex parameter set and no output schema, the description adequately explains what the tool returns and the purpose of each kind. It lacks details on prerequisites or rate limits but is sufficient for an agent.
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?
Input schema has 100% coverage with parameter descriptions. The description groups parameters by kind but does not add new meaning beyond what's in the schema. 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 clearly states the tool creates inbound tickets for specific categories (bug, listing, security, anomaly, partnership). It distinguishes from sibling tools by focusing on ticket submission rather than package checking.
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 lists 'USE WHEN' conditions for each kind and provides specific context for anomaly. It does not explicitly state when not to use or mention alternatives, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Curated replacements for deprecated/unhealthy packages, including stdlib built-ins (e.g. fs.rm for rimraf). USE WHEN: pkg flagged AVOID/URGENT; 'what to use instead of X'; before guessing a replacement name. RETURNS: {alternatives[]: {name, reason, is_stdlib}}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds that results are 'curated', includes return format, and mentions stdlib inclusion. No contradiction with annotations.
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?
Single sentence plus structured 'USE WHEN' and 'RETURNS' clauses. Every element adds value: purpose, usage conditions, and output format. No superfluous text.
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 two-parameter lookup tool with no output schema, description covers purpose, usage triggers, and return format. Lacks handling of edge cases like no alternatives found, but overall sufficient for this complexity.
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 has 0% description coverage. Description does not clarify the expected format for the 'package' string (e.g., exact name, version?). It only mentions the output. With no parameter guidance, the description fails to compensate for the missing schema descriptions.
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 provides 'curated replacements for deprecated/unhealthy packages', including stdlib built-ins. It distinguishes from siblings like check_package or get_health_score by focusing on alternatives.
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?
Explicitly states 'USE WHEN: pkg flagged AVOID/URGENT; what to use instead of X; before guessing a replacement name', giving clear context and a negative example (guessing). Could be improved by also stating when NOT to use, e.g., when package is healthy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Breaking changes between two majors of the SAME package (next@14→15). USE WHEN: user is bumping a major; before recommending a major upgrade. Different from get_migration_path (same pkg vs. different pkg). RETURNS: {breaking_changes[]: {area, description, hint}}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes | ||
| from_version | No | ||
| to_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the return shape but does not disclose any additional behavioral traits (e.g., whether it requires specific permissions, rate limits, or data freshness). It does not contradict annotations.
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 three brief sentences, front-loading the core purpose and using structured labels ('USE WHEN', 'RETURNS'). Every sentence adds value without redundancy, achieving maximum clarity in minimal space.
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?
The description covers the core use case, sibling distinction, and return format. However, parameter guidance is missing (e.g., defaults for optional versions), and while the return is described, the lack of an output schema means more detail about the response structure would be helpful. Overall adequate but not fully comprehensive.
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 0%, and the description does not explain any parameter meaning or constraints beyond the schema itself. For instance, it does not clarify that 'from_version' and 'to_version' should be major versions or what happens if omitted. The self-explanatory parameter names partially compensate, but the lack of explicit guidance is a notable gap.
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 retrieves breaking changes between two majors of the same package, with a concrete example (next@14→15). It explicitly distinguishes from sibling tool 'get_migration_path' by scope (same package vs. different package), making the purpose unambiguous.
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 provides usage guidance: 'USE WHEN: user is bumping a major; before recommending a major upgrade.' It also implies when not to use (different package) by contrasting with get_migration_path, fulfilling the dimension criteria perfectly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single 0-100 health score — cheapest go/no-go gate (>=70 safe). USE WHEN: CI gating or pkg already screened for malware/typos. NOT a first screen — run check_malicious + check_typosquat first. For a verbal verdict use get_package_prompt. RETURNS: {score, verdict}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, idempotent read. Description adds return shape ({score, verdict}) and cost hint ('cheapest'), which are helpful but not contradictory.
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 efficiently structured sentences with clear sections (purpose, usage, returns) and zero wasted words.
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, but description explains return value. Lacks detail on score computation or edge cases, but adequate for a simple gate tool given annotations.
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 0% schema description coverage, description must compensate but it adds no parameter guidance. Names and enum in schema are somewhat clear, but description misses opportunity to clarify needed inputs.
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?
Clearly states it returns a 0-100 health score as a go/no-go gate, distinguishing it from sibling tools like check_malicious and check_typosquat by emphasizing it is a cheap, final check.
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?
Explicitly specifies when to use (CI gating or after malware/typosquat screening) and when not to use (not a first screen), and recommends alternatives (check_malicious, check_typosquat, get_package_prompt).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Non-CVE known bugs for a specific package version. USE WHEN: unexpected behavior that is NOT a security issue; a pinned version misbehaves. RETURNS: {bugs[]: {title, fixed_in, workaround}}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes | ||
| version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by detailing the return format with field names. The description's 'non-CVE' qualifier further clarifies behavior beyond annotations.
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 with three sentences covering purpose, usage, and return format. Every sentence is necessary 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?
The description provides sufficient context for a simple tool, including when to use and return format. However, it lacks details on potential pagination or filtering, but this is acceptable given the tool's simplicity and the annotations providing basic safety information.
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 0%, and the description only mentions 'package version' without explaining individual parameters like ecosystem or that package is required. It provides only minimal guidance on the version parameter, leaving the agent to infer the rest.
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 it retrieves non-CVE known bugs for a specific package version, and the 'USE WHEN' clause further clarifies its scope. It effectively distinguishes from sibling tools like 'get_vulnerabilities'.
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?
Explicit 'USE WHEN' conditions are provided: unexpected behavior that is not a security issue or a pinned version misbehaves. While it doesn't explicitly state when not to use, the context strongly implies it's for non-security issues, which is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest published version + deprecation flag — the cheapest call. USE WHEN: only a version string matters (pinning a dep, answering 'what version of X'). If you also need health/vulns use check_package. RETURNS: {latest, deprecated, published_at}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds 'cheapest call' cost hint and specifies the exact return fields, exceeding annotation info. No contradiction.
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 concise sentences, front-loaded with purpose, no wasted words. Every sentence adds value.
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 version-check tool, the description fully covers purpose, usage, return format, and cost. No output schema needed as returns are described. Guidance on sibling tool check_package provides 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?
Schema description coverage is 0%, so the description should compensate. It does not describe parameters beyond what the schema shows (ecosystem enum, package string). The parameters are self-explanatory but no additional semantics provided.
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 it retrieves the latest version and deprecation flag, distinguishing it from siblings like check_package which also provide health/vulnerability data.
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?
Explicitly states when to use (only version string matters) and when not to (use check_package for health/vulns), providing a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prescriptive migration plan between DIFFERENT packages — rationale + literal code diff + breaking changes + effort minutes. USE WHEN: replacing request→axios, moment→dayjs, flask→fastapi, etc.; both endpoints known. RETURNS: {rationale, diff, breaking_changes[], estimated_minutes}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| from_package | Yes | Deprecated/legacy package to migrate away from. | |
| to_package | Yes | Modern replacement package. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by specifying the return structure: {rationale, diff, breaking_changes[], estimated_minutes}, which goes beyond what annotations provide. No contradictions with annotations.
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 plus a structured 'RETURNS' line. Every sentence provides essential information: what the tool does, when to use it, and what output to expect. No redundancy, front-loaded with the core action.
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 has 3 required parameters, no output schema, and annotations covering safety/idempotence, the description covers key aspects: purpose, usage examples, return fields. It lacks details on the exact structure of the diff or whether additional context (e.g., package versions) is needed, but it is largely sufficient.
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 describes 2 of 3 parameters (from_package, to_package), achieving 67% coverage. The description adds the context that packages must be 'DIFFERENT' (emphasized) and that 'both endpoints known'. This provides some additional meaning but does not fully compensate for the undocumented ecosystem parameter. 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 clearly states it provides a 'Prescriptive migration plan between DIFFERENT packages' and lists the outputs: rationale, code diff, breaking changes, and effort minutes. It distinguishes itself from sibling tools like get_breaking_changes and compare_packages by focusing on a full migration plan.
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 includes a 'USE WHEN' section with concrete examples (e.g., replacing request→axios) and mentions that both endpoints must be known. It does not explicitly mention when not to use it or name alternative tools, but the guidance is clear enough for an agent to identify appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LLM-optimised package brief — plain text ~300 tokens (~75% cheaper than JSON). Verdict (SAFE/AVOID/URGENT/MALICIOUS) + health + vulns + alternatives + maintainer alerts. USE WHEN: you want to reason over a package and drop the output directly in context; 'is X safe'. PREFER THIS over check_package in 95% of LLM cases. RETURNS: plain-text brief.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds numerous behavioral details beyond the annotations: it outputs plain text (~300 tokens), is 75% cheaper than JSON, includes a verdict and specific fields, and is tailored for LLM reasoning. This fully discloses what the agent can expect without contradicting the read-only and idempotent hints.
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, using only three sentences to convey purpose, usage guidance, and return type. It front-loads the key benefit (LLM-optimised, cheaper, verdict) and avoids any redundant or filler sentences. Every phrase adds value.
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?
The description adequately covers output and usage for a tool with two simple parameters, but it lacks any parameter documentation. Given the high number of siblings and the tool's specific niche, the missing input guidance leaves a gap that could cause misuse. An output schema is absent, but the description describes return fields sufficiently.
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% description coverage and the description provides no guidance on the parameters ('ecosystem' and 'package'). Despite two required parameters with an enum, the description focuses solely on output, leaving the agent to infer parameter meaning from the schema alone.
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 it produces an 'LLM-optimised package brief' with specific verdict types (SAFE/AVOID/URGENT/MALICIOUS) plus health, vulnerabilities, alternatives, and alerts. It distinguishes itself from the sibling 'check_package' by noting it is text-based and cheaper, making its unique purpose unmistakable.
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?
Explicit instructions: 'USE WHEN: you want to reason over a package and drop the output directly in context; 'is X safe'. PREFER THIS over check_package in 95% of LLM cases.' This clearly defines when to use this tool versus the sibling, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live trending packages with rank-delta and weekly growth %. USE WHEN: 'what is rising in npm/PyPI/Cargo right now'; recommendation not biased by training-data cutoff. RETURNS: {items[]: {name, rank, rank_delta, weekly_growth_pct}}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | No | Optional. If omitted returns cross-ecosystem trending. | |
| scope | No | Time window. Defaults to week. | |
| limit | No | Max results, 1-50. Default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds return structure and emphasizes live, unbiased data, providing useful behavioral context beyond annotations.
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 plus return structure; every sentence serves a purpose, front-loaded with purpose, no wasted words.
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 but description provides return fields; all 3 optional parameters covered; simple tool is fully described.
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% and description does not add extra meaning to parameters beyond schema explanations; 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?
Clearly states 'Live trending packages with rank-delta and weekly growth %', uses specific verbs and resources, and distinguishes from sibling tools that focus on package checks and compatibility.
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?
Provides explicit USE WHEN scenario ('what is rising right now') and highlights benefit of no training-data bias; lacks explicit when-not-to-use but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call aggregate of ALL non-CVE supply-chain trust signals: maintainer trust (bus factor, ownership changes), OpenSSF Scorecard, quality (criticality, release velocity, publish security), and SLSA/Sigstore provenance. USE WHEN: deep-vetting a package beyond CVEs (hardened/regulated env, SBOM/compliance, small-pkg ownership review, choosing between healthy candidates). Runs 4 backend endpoints in parallel. RETURNS: {maintainer, scorecard, quality, provenance} — each may be null if its backend call failed.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds useful behavioral context: it runs 4 backend endpoints in parallel and returns fields that may be null if a backend call fails. No contradiction.
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, using 'USE WHEN' and 'RETURNS' to organize usage and output. Every sentence adds value without redundancy.
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 output schema, the description fully explains the return structure (maintainer, scorecard, quality, provenance) and notes potential nulls. It addresses the tool's complexity and backend parallelism, making it complete for an AI agent.
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 0%, so the description carries the burden. It mentions 'ecosystem' and 'package' as inputs but does not explain them beyond what the schema provides (ecosystem has enum in schema). The description lacks additional parameter details like format or examples, so it compensates only partially.
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 aggregates all non-CVE supply-chain trust signals, listing four categories (maintainer trust, OpenSSF Scorecard, quality, SLSA/Sigstore provenance). It distinguishes itself from sibling tools like get_vulnerabilities or check_package by focusing on trust signals beyond CVEs.
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: deep-vetting a package beyond CVEs' with specific scenarios (hardened/regulated env, SBOM/compliance, etc.). It does not provide when-not to use or explicitly name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CVE/OSV advisories affecting the latest (or specified) version. USE WHEN: security-sensitive project; user asks 'any CVEs in X'; you already know the pkg exists. RETURNS: {vulnerability_count, vulnerabilities[]: {id, severity, cvss, fixed_in}}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (read-only, idempotent). Description adds return format but contains a misleading mention of 'specified version' while input schema has no version parameter, causing confusion.
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?
Compact two sentences plus a return block, well-structured with USE WHEN and RETURNS. However, the inaccurate version mention wastes space.
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?
Despite providing return structure, the description introduces an unsupported version concept and does not fully address the tool's capabilities given the schema. Missing explanation of how to use for latest vs. specific version.
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 0%, and description fails to explain the 'ecosystem' or 'package' parameters. The mention of 'specified version' is incorrect given the schema, adding no value and causing harm.
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?
Description clearly states it retrieves CVE/OSV advisories for a package, with specific usage conditions. It distinguishes from siblings that check other aspects like maliciousness or typosquatting.
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?
Provides explicit 'USE WHEN' conditions (security-sensitive, user asks about CVEs, package exists). Lacks explicit when-not-to-use or alternatives, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Canonical install command(s) across every package manager of the ecosystem (npm/pnpm/yarn/bun, pip/uv/poetry, cargo, go, composer, maven+gradle, nuget, …). USE WHEN: emitting an install line and you want correct flags. RETURNS: {primary, variants[]}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes | ||
| version | No | Optional explicit version; defaults to latest. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the agent knows it's a safe query. The description adds that it returns {primary, variants[]}, providing behavioral insight beyond annotations. No contradictions.
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 front-loaded purpose and clear sections for USE WHEN and RETURNS. No wasted words, every sentence adds value.
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, the description covers its purpose, usage context, and return value. It lacks details on error handling or edge cases, but these are minimal in a query-only tool. The lack of output schema is mitigated by describing the return shape.
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 33% with only 'version' having a description. The description mentions ecosystem examples like 'npm/pnpm/yarn/bun' but does not detail the parameter semantics for 'ecosystem' or 'package' beyond the schema. Given low coverage, it partially compensates but could do more.
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 it provides canonical install commands across many package managers, with a specific verb and resource. It distinguishes itself from sibling tools which are mostly about checking or comparing packages.
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?
Explicitly states 'USE WHEN: emitting an install line and you want correct flags.' This tells the agent when to invoke it. It does not explicitly mention when not to use or alternatives, but there are no sibling tools with similar functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Boolean registry existence check. USE WHEN: about to emit a package name in an install command but unsure it exists; verifying a name generated from training data. RETURNS: {exists}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety and idempotency. Description adds return format ({exists}) but no further behavioral traits. With annotations present, the description provides some additional context without contradiction.
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 with no fluff: purpose, usage guidance, return type. Front-loaded and efficient. Every sentence 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?
For a simple boolean check tool with clear schema and annotations, description covers all needed aspects: what it does, when to use, what it returns. No gaps given the tool's complexity.
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 0%, yet description offers no explanation of ecosystem or package parameters. The schema itself with enum for ecosystem is clear, but description fails to add any value beyond what schema provides. Missing guidance on how to format or interpret 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?
Description clearly states 'Boolean registry existence check', specifying verb and resource. It distinguishes from sibling tools like check_bulk, check_compatibility by focusing on simple existence. The use cases (pre-install verification, training data validation) further clarify purpose.
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?
Provides explicit 'USE WHEN' conditions: before install command and when verifying training data. This gives clear context for when to invoke. Does not explicitly mention when not to use or name alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Highest version below the chosen CVE severity tier, respecting a semver constraint. USE WHEN: writing a package.json/requirements.txt line; resolving dependabot by lowest-risk patched version. RETURNS: {recommended_version, walk_log[]}.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | Yes | ||
| package | Yes | ||
| min_severity | No | Lowest severity to exclude. Default: high (excludes critical+high). | |
| constraint | No | npm-style constraint: ^X.Y.Z, ~X.Y.Z, >=X.Y.Z, or exact X.Y.Z. | |
| include_prerelease | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return format ({recommended_version, walk_log[]}) and implies read-only behavior, which aligns with annotations. It adds value beyond annotations by describing the output structure. Missing details on error conditions (e.g., no safe version found) keep it from being a 5.
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 very concise: three sentences covering function, usage, and return. No redundant information. Front-loaded with the key action, making it easy for the agent 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 complexity (5 params, no output schema) and the presence of sibling tools, the description provides enough context for basic usage. However, it lacks edge case handling and does not explain how it differs from similar tools. Annotations partially compensate for safety and idempotency.
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 only 40% (min_severity and constraint have descriptions). The overall description does not explain individual parameters like ecosystem, package, or include_prerelease. It fails to compensate for the low coverage, leaving the agent with incomplete 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 function: pinning the highest safe version below a severity tier with semver constraints. It provides specific use cases (writing package.json/requirements.txt, resolving dependabot). However, it does not explicitly differentiate from sibling tools like get_latest_version or get_vulnerabilities, which could also be relevant.
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 includes explicit 'USE WHEN' guidance for two specific scenarios, which helps the agent choose this tool. However, it does not mention when not to use it or provide alternative tools for different contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map error OR free-text query to a verified fix. USE WHEN: user pastes a concrete error/stack (ENOENT, ImportError, build failure) — pass error. OR user describes a symptom ('webpack slow', 'pip stuck') — pass query. Always prefer this over guessing a fix. RETURNS: exact-match {status, solution, confidence, source_url} or search results [{title, summary, source_url}].
| Name | Required | Description | Default |
|---|---|---|---|
| error | No | Concrete error message / stack trace. Triggers exact-match lookup. | |
| query | No | Free-text symptom description. Triggers KB search. | |
| context | No | Optional context for error-mode calls (ecosystem, package, version). | |
| limit | No | Max search results (query mode only). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds return format details and contextual behavior, surpassing 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?
Very concise: 4 sentences covering use cases, parameters, and return structure without redundancy, front-loaded with key purpose.
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?
Despite no output schema, description fully explains return values (exact-match or search results) and covers both modes with context and limit. No information 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 coverage is 100%, but description adds critical context: error triggers exact-match, query triggers search, context for error-mode, limit for query only, enhancing schema meaning.
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 maps errors or queries to fixes, with specific verbs and resources, and differentiates from siblings by being the go-to error resolution 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?
Explicitly tells when to use (concrete error or symptom) and when-not (guessing), with examples and a preference statement over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full dep-list audit with per-package health+vulns and prioritized actions (REMOVE NOW / URGENT / REPLACE / REVIEW). Accepts EITHER {ecosystem, packages:[name@ver, …]} (up to 100, returns JSON) OR {packages:[{ecosystem, package}, …]} (up to 50, mixed ecosystems, returns text brief). USE WHEN: user pastes package.json/requirements.txt; 'is my stack OK'. Unlike check_bulk this fetches full health/vulns. RETURNS: JSON or text per shape.
| Name | Required | Description | Default |
|---|---|---|---|
| ecosystem | No | Required when packages is a string array. | |
| packages | Yes | Either ['express','lodash@4.17.0'] (single ecosystem, up to 100) or [{ecosystem, package}, …] (mixed, up to 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, destructive, idempotent hints. Description adds input format variants, return types, and action labels—valuable beyond annotations. No contradiction.
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?
Concise at ~4 sentences, with bold-like emphasis. No wasted words, but could be better structured (e.g., bullet points). Still efficient.
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?
Covers input/output, limits, and use cases. No output schema exists, but description explains return types. Missing error handling details, but adequate for the tool's purpose.
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% but description clarifies dual input shapes, max counts, and return formats. Adds significant meaning beyond the schema's field descriptions.
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?
Clearly states 'full dep-list audit' with specific actions (REMOVE NOW, etc.) and distinguishes from sibling check_bulk by noting it fetches full health/vulns. Verb+resource+scope is explicit.
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?
Explicitly states use cases (pasting package.json, checking safety) and differentiates from check_bulk. Lacks explicit exclusions for single-package checks, but the context is clear.
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.
v0.1.0check_bulkcheck_compatibilitycheck_maliciouscheck_packagecheck_typosquatcompare_packagescontact_depscopefind_alternativesget_breaking_changesget_health_scoreget_known_bugsget_latest_versionget_migration_pathget_package_promptget_trendingget_trust_signalsget_vulnerabilitiesinstall_commandpackage_existspin_saferesolve_errorscan_projectEach tool has a clearly distinct purpose: checks for typosquatting, malware, compatibility, health, vulnerabilities, etc. Even similar tools like `check_package` and `get_package_prompt` are differentiated by output format (JSON vs text) and use case.
Most tools follow a verb_noun pattern (e.g., `check_malicious`, `get_latest_version`), but a few like `package_exists` (noun_verb) and `install_command` (verb_noun but combined) deviate slightly. The pattern is mostly consistent with lowercase underscores.
With 22 tools, the server covers a wide range of dependency analysis needs. While slightly above the typical 3-15 range, each tool serves a specific, non-redundant purpose, making the count appropriate for its comprehensive scope.
The tool set covers nearly the entire lifecycle of package evaluation: existence, health, security, compat, migration, alternatives, trending, error resolution, and project audit. No obvious gaps for the intended domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
check-package: block malicious npm/PyPI deps before your AI agent installs them. Free, no key.
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.
Protects AI coding agents from installing malicious open source packages. Every npm and PyPI package is checked against SafeDep’s real-time threat intelligence before installation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cuttalo/depscope'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
