Verify npm packages before your AI agent installs them: hallucinations, advisories, API drift.
Scored across 15 tools
Tools have largely distinct purposes and descriptions explicitly cross-reference each other (e.g., verify vs evaluate, usage vs resolve_surface vs diff_surface), reducing misselection. However, some pairs like evaluate/verify and the three surface/diff tools could still be confused by name alone, though their boundaries are clarified in text.
Tool names mix single-word verbs/nouns (audit, compare, verify) with snake_case compounds (diff_surface, mcp_drift, report_outcome), and there is no consistent verb_noun pattern throughout. The names are still readable and all lowercase, but the convention is mixed.
15 tools is at the high end for this domain but each tool appears to serve a distinct function across package health, compatibility, API surfaces, MCP analysis, policy, audit, and feedback. There is no obvious redundancy, though the set is slightly heavy.
The surface covers package health/security, compatibility, API surfaces, MCP server inspection, policy, audit, and feedback comprehensively. Minor gaps include no dedicated package search/discovery or license inspection tool, and no mutation/update actions, though these may be intentionally out of scope.
Assess an entire project's dependencies in ONE call: which packages are outdated, deprecated or carry advisories for the exact installed version, and which configured MCP servers have drifted, need credentials, or cannot be observed at all. Send the inventory you read locally (names and versions only — never source). Returns a per-item verdict plus an explicit coverage count: how many were answered, how many are queued because the index has not seen them, and how many were skipped and why. An item lurq could not assess is reported as unassessed, never as clean.
| Name | Required | Description | Default |
|---|---|---|---|
| packages | No | npm dependencies read from package.json + lockfile | |
| mcpServers | No | MCP servers read from .mcp.json / agent configs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds real behavioral depth: the privacy contract ('names and versions only — never source'), the coverage accounting (answered vs queued vs skipped-and-why), and the failure semantics ('an item could not assess is reported as unassessed, never as clean'). The last point in particular prevents an agent from misreading silence as a pass.
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?
Four dense sentences, front-loaded with the scope and output of the call, with the privacy constraint and coverage semantics compactly packed. No filler sentences, though the third and fourth sentences could be tightened slightly.
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 carries return-value explanation, and it does so well by describing the per-item verdict and the answered/queued/skipped coverage counts. It does not break down the verdict fields themselves, which is the one remaining gap for a tool this complex with nested array inputs.
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% — name/range/installed and the mcpServers fields (kind, alias, version, endpoint, packageName) are all documented at the schema level. The description reinforces what the payload should be ('names and versions only') but adds no syntax or format meaning beyond the schema, so the baseline of 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?
The description names a specific verb and resource — 'Assess an entire project's dependencies' — and enumerates the exact findings it produces (outdated, deprecated, advisory on the installed version, plus MCP drift/credential/observability states). It clearly scopes itself as the whole-project batch operation ('in ONE call'), but it never names a sibling such as mcp_drift or compat that an agent should pick for narrower checks.
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?
It gives concrete invocation guidance — send the inventory you read locally, names and versions only, never source — which tells the agent what input to marshal and what not to send. It also implies the batch-use case via 'ONE call,' but it stops short of explicit when-not conditions or named alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up which lurq tool answers a situation, and what to run next. Call when you're unsure whether lurq covers something (an upgrade, a licence rule, a version's exact exports, publishing a package) instead of guessing or skipping it. Returns matching capabilities with the tool or command to use.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | What you are trying to do, in plain words. Omit for the full menu. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the useful return behavior, that it yields matching capabilities plus the tool or command to use, which matters since there is no output 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?
Three tight sentences, front-loaded with the purpose followed by the when-to-call and the return value. No filler; every sentence carries distinct 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 zero-required-param, read-only lookup with no output schema, the description supplies purpose, trigger context, and return content. Nothing critical is missing, though it could note that omitting the query returns the full menu as the schema does.
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 single query parameter is fully documented in the schema (plain-words intent, omit for the full menu), so the schema does the heavy lifting. The description only implicitly describes querying by situation and adds no syntax or formatting detail beyond that.
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 verb and resource: look up which lurq tool answers a situation and what to run next. It is a routing/discovery tool, which cleanly distinguishes it from the functional siblings (audit, compare, diff_surface, etc.) that actually perform the work.
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?
It gives explicit triggering conditions with concrete examples (an upgrade, a licence rule, a version's exports, publishing a package) and a contrast against the failure mode ('instead of guessing or skipping it'). It stops short of naming sibling tools as alternatives, so it falls just under fully explicit routing guidance.
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 of 2–5 npm packages you are choosing between, ranked by health score. Untracked names are fetched on demand; one still being scored comes back under pending (retry shortly), and a name not on npm under notFound.
| Name | Required | Description | Default |
|---|---|---|---|
| packages | Yes | 2–5 npm package names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses the on-demand external fetch for untracked names (consistent with openWorldHint) and three distinct result states: normal ranking, `pending` with a retry hint, and `notFound`. That state vocabulary is genuinely useful and not derivable from the 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?
A single sentence with no filler, and the core purpose (side-by-side comparison ranked by health) is front-loaded. It is dense with three semicolon-joined state clauses, which slightly taxes readability but every clause 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 one-parameter read-only tool with no output schema, the description covers purpose, ranking behavior, and the key response states an agent must handle (`pending`, `notFound`). It omits any hint at the comparison payload's fields, but the state handling is the operationally important part.
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 already enforces the 2–5 count and npm name pattern, so the baseline would be 3. The description adds semantic value by explaining what happens to names passed in (untracked fetched on demand, in-progress scoring returns `pending`, unknown names return `notFound`), clarifying the accepted value domain.
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 ("Side-by-side comparison of 2–5 npm packages") plus the ordering rule ("ranked by health score"), which distinguishes it from a single-package inspect tool. However, it never names or contrasts itself with siblings like `audit`, `evaluate`, or `compat`, so the sibling-differentiation bar for a 5 is not met.
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 phrase "packages you are choosing between" implies the decision-support context, which is a reasonable usage cue. It gives no explicit when-not guidance and does not route the agent to alternatives such as `evaluate` for a single package or `compat` for interoperability checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a set of packages forms a coherent stack. Resolves the whole set the way npm would and returns a definitive verdict: compatible, conflict (with the exact clashing constraints), or unknown. Checks peer-dependency and engine ranges from declared metadata, plus any recorded sandbox conflicts. Read-only: never installs or executes package code. Not always instant: a set checked before answers immediately, but a new set is resolved live from registry metadata, which can take up to ~25 seconds. Call once with the whole stack before committing to it.
| Name | Required | Description | Default |
|---|---|---|---|
| node | No | Optional target Node runtime (e.g. "20" or "20.20.2") for engines.node checks | |
| packages | Yes | The full candidate stack to check together, 2–30 npm package names — a whole package.json dependency list is the intended input. Pass every package in one call: conflicts routinely appear only across the whole set (a peer range three packages deep), so checking pairs separately misses them and costs a round trip each. | |
| versions | No | Optional exact versions keyed by package name, e.g. {"react":"19.0.0"} (use when not checking latest). Must be exact semver versions, not ranges. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond readOnlyHint/openWorldHint by disclosing that it never installs or executes package code, that results are definitive rather than advisory, and that a cold set resolves live from the registry and can take ~25 seconds while a previously checked set answers instantly. That latency/caching behavior is exactly the kind of context annotations cannot express.
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-loads the purpose and verdicts, then layers constraints and latency. Five sentences, each carrying distinct information, though the note about checking pairs separately is slightly redundant with the schema's packages description.
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 still names the return shape (compatible / conflict with exact clashing constraints / unknown) and covers the peer-dep, engine, and sandbox-conflict checks. Given a 3-parameter tool with full schema coverage, nothing an agent needs 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% and the schema already documents the node, packages, and versions parameters in detail, including exact-version semantics and the 2-30 bound. The description reinforces the whole-set constraint but adds no syntax or format detail beyond the schema, so the 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 ("Check whether a set of packages forms a coherent stack") and immediately enumerates the verdict space (compatible, conflict, unknown). An agent can distinguish this from file-level siblings like audit or verify without opening any 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?
Gives explicit usage context: call once with the whole stack before committing, because conflicts routinely span the full set. It does not name an alternative sibling tool or state when not to reach for this one, which keeps it short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emit a reference-architecture Mermaid diagram for a stack you have already chosen (package names). A labeled starting point keyed by layer, not a validated architecture, and not an architecture designer.
| Name | Required | Description | Default |
|---|---|---|---|
| stack | No | Package names that make up the stack; omit or empty to get usage guidance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, openWorldHint=false) already establish the safety profile, so the description's job is to add output expectations. It does: the result is 'a labeled starting point keyed by layer', explicitly not validated, which correctly sets the agent's trust level in the artifact. It does not mention determinism, size, or failure behavior for malformed package names.
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, no filler, with the concrete output named first and the caveats trailing. Every clause carries information an agent would otherwise have to guess.
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 single-optional-parameter, read-only emit tool with no output schema, the description covers what is produced (a Mermaid diagram), the input expectation (already-chosen package names), and the trust caveat (starting point, not validated). Nothing critical is missing, though the shape/granularity of the emitted diagram remains unspecified.
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 the single 'stack' parameter is fully described in the schema, including the omit/empty behavior, so the baseline is 3. The description only echoes '(package names)' without adding format, ordering, or layer-mapping semantics 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 (Emit), a specific artifact (reference-architecture Mermaid diagram), and the input basis (a stack you have already chosen). It also draws a boundary against a plausible neighbor (an architecture designer), so an agent can tell it apart from design/validation 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?
Gives the precondition for use ('a stack you have already chosen') and explicit exclusions ('not a validated architecture, and not an architecture designer'), which tells the agent when this is the wrong tool. It never names an alternative sibling to use instead, so it stops short of a full when/when-not/alternative statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What changed in a package's runtime surface between two versions: symbols removed, added, and arity changes, plus renames the package itself proves (a removed name that shared one declaration with a name the new version still exports). Removals break node; type-only removals are returned separately because they break tsc instead. Answers "when did this stop working" from static comparison, with no install required. Use before an upgrade, and to explain a break after one.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | npm package name | |
| toVersion | Yes | Version you are moving to | |
| fromVersion | Yes | Version you are on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety (readOnlyHint, openWorldHint); the description goes well beyond by disclosing the analysis method (static, no install), the classification rules (runtime removals break `node`, type-only removals break `tsc` and are returned separately), and the conservative rename heuristic (only renames the package itself proves). That is exactly the extra context an agent needs to interpret results.
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 core purpose, then qualifiers; every sentence carries information and nothing is filler. The clauses are dense and long, but they earn their length by explaining result categorization.
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 must carry the return semantics, and it does: removed/added symbols, arity changes, provable renames, and separately bucketed type-only removals. Combined with the 'no install required' note, an agent has everything needed to call and interpret it.
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 all three params (package, fromVersion, toVersion) are documented there, so the baseline is 3. The description adds no syntax, version-range, or format 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?
Names a precise verb+resource: the runtime surface diff of a package between two versions, and enumerates exactly what the diff contains (removals, additions, arity changes, provable renames, type-only removals). It also distinguishes itself from other comparison siblings by scope ('static comparison, with no install required').
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 it: 'Use before an upgrade, and to explain a break after one.' That covers both the pre-flight and post-mortem context, though it never names a when-not case or points to a specific alternative sibling such as compat or verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full evidence read for one npm package: health and quality scores and the signals behind them, advisories, the shared safety verdict, a summary and a usage guide. Use it when a choice needs more than verify's install gate. Enforces the account's dependency policy. A package lurq has never tracked is fetched and scored on demand, waiting up to ~4 seconds; if scoring takes longer the result is tracked: false with a note to retry in a few seconds, which is not an answer about the package.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | npm package name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the dependency-policy enforcement, the on-demand fetch-and-score behavior for never-tracked packages, the ~4 second wait budget, and the meaning of a `tracked: false` response including that retrying is required. This is exactly the operational context an agent needs for a potentially slow, open-world call.
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 purpose followed by selection guidance and the timeout/tracked-false caveat; every sentence carries information. Slightly dense, but no filler or repetition.
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 artifacts (scores, signals, advisories, verdict, summary, usage guide) and by explaining the failure/timeout mode and its retry semantics. Nothing essential to calling or interpreting the tool 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?
A single parameter with 100% schema description coverage, so the schema already carries the full contract (name pattern, length bounds). The description adds no format or syntax detail about the package argument, so the baseline of 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?
Names a specific verb ('full evidence read') and resource ('one npm package') and enumerates the concrete outputs: health/quality scores, signals, advisories, safety verdict, summary, usage guide. It also distinguishes itself from the sibling 'verify' by positioning itself as the deeper read beyond verify's install gate.
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 the selecting condition: 'Use it when a choice needs more than verify's install gate,' naming the alternative tool and the threshold that favors this one. It does not rule out the other siblings (audit, compare, policy), so it is clear context rather than a complete when/when-not matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What moved in an MCP server's tool contract between two versions: tools removed, parameters that became required, types narrowed, and annotation flips. Two findings here have no npm equivalent and are why this exists. SILENT DRIFT is a schema that changed while its description stayed byte-identical, invisible to anyone reading a changelog. PRIVILEGE WIDENING is a tool that stopped being read-only or started being destructive, which does not break anything and is worse than a break. Use before upgrading a server an agent depends on.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | npm package name of the MCP server | |
| toVersion | Yes | Version you are moving to | |
| fromVersion | Yes | Version you are on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent with a safe read. It goes beyond annotations by explaining the semantics of the two highest-value findings — schema changed with byte-identical description, and read-only-to-destructive flips — which tells the agent why output matters, though it says nothing about rate limits, inputs' fetch behavior, or result shape beyond finding categories.
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 core purpose and the use case are front-loaded, and the finding definitions earn their place by justifying the tool's existence. Slightly long — the 'no npm equivalent' aside is persuasive rather than operational — but no sentence is pure 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?
With no output schema, the description compensates by naming the categories of findings returned, which is the essential return-value context. It stops short of describing the response structure or ordering, but for a three-param read-only diff tool this is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with three required params, so the schema already documents server, fromVersion, and toVersion. The description adds no syntax or semantic detail beyond what the schema provides, matching the baseline 3 for fully-covered schemas.
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 opening clause states a precise verb (drift detection) plus resource (an MCP server's tool contract) plus scope (between two versions). The two named finding types (SILENT DRIFT, PRIVILEGE WIDENING) sharpen what this tool uniquely produces and differentiate it from generic siblings like compare or compat.
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?
It gives a clear trigger: 'Use before upgrading a server an agent depends on.' That is actionable timing guidance, but it offers no explicit when-not condition or named alternative among the many sibling tools (compat, compare, diff_surface), leaving the agent to infer disambiguation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a set of MCP servers can be wired into one agent together. The npm question does not apply — servers are separate processes with nothing to resolve between them. They clash in the single flat TOOL NAMESPACE the agent assembles from all of them: two servers exposing the same tool name leave the agent unable to express which it means, and nothing errors, one simply shadows the other. Also reports the standing context cost, since every tool's schema rides in every request. Pass tools for a server when you already hold its tool list (any server: remote, PyPI, Docker, private) and it is analysed as-is; otherwise the npm server's probed surface is used, and one that has not been probed makes the answer UNKNOWN, never clean.
| Name | Required | Description | Default |
|---|---|---|---|
| servers | Yes | The servers configured into one agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and closed-world, but the description adds substantial non-obvious behavior: collisions fail silently with shadowing instead of erroring, context cost is accumulated per request, and an unprobed server yields UNKNOWN 'never clean'. Those are exactly the traits an agent cannot infer from 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 core question and free of filler, but it is a dense single paragraph packing four distinct ideas (namespace clash, context cost, tools override, UNKNOWN semantics). Slightly heavier than it needs to be, though every sentence 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?
Single required parameter with full schema coverage and no output schema, so the burden on the description is modest. It covers the decisive edge case (UNKNOWN vs clean) and the reported context cost, though it never sketches the shape of the returned result.
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 already 100%, so the baseline is 3; the description adds real meaning on top by explaining that `tools` can be passed for any server type (remote, PyPI, Docker, private) and is analyzed as-is rather than probed.
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 precise verb and resource — 'Check whether a set of MCP servers can be wired into one agent together' — and immediately scopes the concern to the flat tool namespace rather than npm dependency resolution. An agent can tell this apart from surface/diff/compat-style siblings 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?
It gives a clear operative scenario (multiple servers destined for one agent) and an explicit branch for supplying `tools` versus relying on a probed npm surface. It does not, however, name a sibling alternative or state when a different tool would be the better pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What an MCP server ACTUALLY exposes: every tool, its required and optional parameters, and its behaviour annotations, read from a live tools/list handshake in a sandbox rather than from a README or the model's memory. Call before wiring an agent to a server, or when a tool call is failing for reasons the error does not explain. Also returns requires — the API keys and settings the server declares it needs — and configRequest, a ready-made line to put in front of your user when something is missing, so 'it needs a token' never presents as 'it is broken'. A miss returns UNKNOWN and queues a probe; UNKNOWN never means the server has no tools.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | npm package name of the MCP server | |
| version | No | Exact version; omit for the latest probed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint, openWorldHint), and the description adds real behavioral context beyond them: the sandbox handshake source, the additional requires and configRequest fields returned, and the miss semantics — UNKNOWN plus a queued probe, with the explicit warning that UNKNOWN never means the server has no tools.
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 core purpose, then usage, then return details. Dense and generally earns its length, though the closing 'it needs a token' framing is slightly rhetorical rather than informational.
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 must carry the return contract — and it does, naming tools/parameters/annotations plus requires and configRequest. Combined with the UNKNOWN miss semantics, an agent has everything needed to call and interpret it.
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% across both parameters, so the schema already documents server and version. The description implies versioning ('before wiring') but adds no format or default semantics beyond what the schema states, 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+resource with scope: returns every tool, its required/optional parameters, and behaviour annotations, read from a live tools/list handshake in a sandbox. This clearly distinguishes it from siblings like capabilities or resolve_surface that would otherwise look similar to an agent.
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?
Gives explicit when-to-use conditions: 'Call before wiring an agent to a server, or when a tool call is failing for reasons the error does not explain.' No named alternative sibling or explicit when-not, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The rules this account's selection policy enforces on which packages you may add: denied packages (with the reason), license allowlist, confidence, advisory, adoption, staleness and bundle-size floors. Read it once before choosing dependencies so you pick an allowed package first; evaluate already enforces it. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description's trailing 'Read-only' largely restates it. It does add genuine context beyond the annotations: the policy is account-scoped and is advisory for selection while 'evaluate' performs actual enforcement. It does not mention caching, freshness, or what an empty result means.
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 core statement of what the policy governs, followed by a dense but necessary enumeration of the policy dimensions and then the usage cue. The single multi-clause sentence is economical, though the middle list is packed tightly enough that it reads as a run-on.
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 and does so by naming the fields an agent will get back (denials with reasons, allowlist, assorted floors). Combined with the usage cue, an agent has everything needed to decide whether and when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case: there is no argument surface an agent could get wrong. The description correctly implies a parameterless read of account-wide policy rather than a per-package query.
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 (read) and resource (the account's selection policy), then enumerates exactly what the policy contains: denied packages with reasons, license allowlist, and confidence/advisory/adoption/staleness/bundle-size floors. It also distinguishes itself from the sibling 'evaluate', which enforces the same policy, so an agent can tell the two apart without opening anything.
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?
Gives an explicit when: read it once before choosing dependencies so the first pick is already allowed. It also gives the implicit when-not by noting that 'evaluate already enforces it', so re-reading purely to gate a single evaluation is unnecessary. Both the trigger and the alternative are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opt-in feedback after you act on lurq's evidence about a package (verify, evaluate, compare, compat): whether you went with it and whether it built. No source code, only the coarse decision + a build signal. Helps lurq learn which packages agents actually succeed with; safe to skip.
| Name | Required | Description | Default |
|---|---|---|---|
| need | No | What you needed the package for, in plain words (no source code) | |
| package | Yes | The package you decided on | |
| accepted | Yes | Did you go with this package? | |
| buildSignal | No | Coarse post-install result, if known |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as a non-read-only, non-idempotent, non-destructive, closed-world write, which is already informative. The description adds that no source code is sent, only a coarse decision and build signal, and that it helps learn which packages succeed. However, it doesn't discuss privacy, storage, or side effects beyond the coarse data, and the non-idempotent annotation suggests repeated calls may duplicate data, which is not mentioned.
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 compact sentences, front-loaded with the trigger and scope, then the data-minimization and value proposition. No filler, every clause 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 four-parameter opt-in feedback tool with full schema coverage and no output schema, the description is nearly complete: it covers purpose, timing, data limits, and optionality. It could mention whether a response is returned or what happens after submission, but the core needs are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are fully documented in the schema with descriptions, patterns, and an enum for buildSignal. The description does not add any parameter-level details beyond 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 verb (report) and a specific resource (feedback on a package outcome), and it precisely scopes what is being reported: 'whether you went with it and whether it built.' It also names the sibling tools whose evidence it follows up on (verify, evaluate, compare, compat), distinguishing this tool from those.
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 'Opt-in feedback after you act on lurq's evidence about a package (verify, evaluate, compare, compat)' and 'safe to skip.' This tells the agent exactly when to use it (after acting on evidence from those siblings) and when it is not required. The condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a package version ACTUALLY exports at runtime, extracted from its shipped JavaScript rather than from documentation or the model's memory: names and arity, not type signatures (use usage for those). Call before writing code against a package whose API may have moved. Runtime existence is what decides whether an import throws; a removed type breaks tsc, a removed runtime symbol breaks the program. A miss returns UNKNOWN and queues extraction, UNKNOWN never means the symbol is absent.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | npm package name | |
| version | No | Exact version; omit for the latest extracted |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: the extraction source (shipped JavaScript vs. documentation/memory), the distinguishing concern (runtime existence vs. type existence affecting tsc vs. program), and importantly the miss behavior ('A miss returns UNKNOWN and queues extraction, UNKNOWN never means the symbol is absent'). Annotations only cover read-only/open-world; the description supplies the semantic behavior an agent needs to interpret results correctly.
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 dense sentences, front-loaded with what the tool returns and immediately followed by the alternative-tool distinction and the call-timing recommendation. Every sentence carries informational weight, though the runtime-vs-type explanation is slightly elaborate.
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 read-only extraction tool with a small 2-param schema and no output schema, the description covers purpose, source of truth, sibling routing, and result semantics (UNKNOWN handling). No output schema means the description's note about names/arity and UNKNOWN is valuable, though return shape is only partially implied.
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 both parameters fully described ('npm package name', 'Exact version; omit for the latest extracted'). The description adds no parameter syntax or format beyond what the schema provides, so the 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?
States a specific verb+resource combination — what a package version actually exports at runtime, extracted from shipped JavaScript. It explicitly distinguishes itself from the sibling tool 'usage' ('names and arity, not type signatures (use usage for those)'), so an agent can route correctly without opening both schemas.
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 clear context for when to use it — 'Call before writing code against a package whose API may have moved' — and names the alternative ('usage') for type signatures. No explicit when-not-to-use beyond the usage distinction, but the routing condition is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A package version's TYPED API: exported symbols and their signatures from its shipped .d.ts (or DefinitelyTyped), exact to the version, none of it in the model's training data. Use before writing code against a package whose API may have moved. For whether a name exists at RUNTIME (what decides if an import throws) use resolve_surface; for is-it-safe-to-install use verify. Pass knownVersion (e.g. the version you were trained on) to get the precise delta: added, removed, renamed, changed. Also returns the version's declared engines (Node/runtime floor). Large surfaces are paged, 80 symbols per call: totalSymbols is the size, query filters by name, offset pages. shallow: true means the API lives on an interface's members that are not listed, and the note says where to read them. For framework file/convention changes (not exported symbols), consult the official migration guide / Context7 instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Part of a symbol name (case-insensitive); returns only matching symbols | |
| offset | No | Index of the first symbol to return, to page past the first 80 | |
| package | Yes | npm package name | |
| version | No | Target version (defaults to latest) | |
| knownVersion | No | A version you already know; returns the API delta from it to the target |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say read-only and open-world; the description adds substantial behavior beyond that — the data is version-exact and absent from training data, the return includes declared engines (runtime floor), surfaces are paged at 80 symbols per call, and `shallow: true` signals API hiding on interface members with a pointer to where they live. This is exactly the kind of operational context annotations cannot carry.
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 core value ('A package version's TYPED API ... exact to the version') then progressively adds routing, delta, paging, and escalation guidance. Dense but each clause carries information; the routing and paging sentences could be tightened slightly.
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 still names the response fields an agent needs (totalSymbols, query, offset, shallow) and explains the delta semantics and engines output. Nothing required to call it correctly or interpret the result 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: knownVersion yields a precise delta classified as added/removed/renamed/changed, query filters by symbol name, offset pages past the first 80, and totalSymbols reports full size. It stops short of explaining the default of version beyond the schema's note.
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: the TYPED API (exported symbols and signatures) of a package version, sourced from shipped .d.ts or DefinitelyTyped. The title reinforces it and the description explicitly distinguishes itself from the sibling resolve_surface (runtime existence) and verify (install safety).
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?
Gives an explicit trigger ('Use before writing code against a package whose API may have moved') and routes the agent to named alternatives with the exact condition selecting each: resolve_surface for runtime/import behavior, verify for install safety, migration guides/Context7 for framework conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm an npm package is real, healthy, and not risky before installing: guards against hallucinated or typosquatted names, deprecations and known advisories, and returns a safety verdict with its reasons and what was not checked. Checks the live registry. The cheap gate to call before every install; use evaluate when you need the full scores.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | npm package name to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description goes further by stating it checks the live registry (network implication), that it is the cheap/lightweight gate relative to evaluate, and that the verdict includes both reasons and what was NOT checked. The last point is unusually honest about limitations. It stops short of describing verdict values or failure behavior, so 4 rather than 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?
Front-loaded with the purpose and risk coverage, then closes with the usage rule and alternative in a short final clause. The opening sentence is compound and dense, but every clause (risks, live registry, verdict contents) earns its place. Minor trimming possible, no real 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?
With no output schema, the description carries the return-value burden and does so: a safety verdict with reasons plus explicit disclosure of what was not checked. Combined with the live-registry note and the cheap-vs-full distinction against evaluate, an agent has everything needed to call it 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?
A single parameter at 100% schema description coverage, so the schema already defines the npm package name and its pattern/length constraints. The description adds no syntax, scoping, or scoped-package guidance beyond the name itself. 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?
States a specific verb (confirm/verify) and resource (an npm package), then enumerates the exact risks it screens for: hallucinated/typosquatted names, deprecations, and advisories. It also explicitly names the sibling it is not (evaluate), so an agent can route between them without opening either 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?
Gives a concrete cadence ('the cheap gate to call before every install') and names the alternative with the condition that selects it ('use evaluate when you need the full scores'). No exclusions are left to inference.
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.
report_outcome2 fields changedInput schema / properties / need / descriptionPrevious value: -"The original need this was recommended for (no source code)"New value: +"What you needed the package for, in plain words (no source code)"Input schema / properties / package / descriptionPrevious value: -"The package that was recommended"New value: +"The package you decided on"usage2 fields changedInput schema / properties / offsetAdded value: +{
+ "description": "Index of the first symbol to return, to page past the first 80",
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / queryAdded value: +{
+ "description": "Part of a symbol name (case-insensitive); returns only matching symbols",
+ "maxLength": 100,
+ "type": "string"
+}auditcapabilitiescomparecompatdiagramdiff_surfaceevaluatemcp_driftmcp_stackmcp_surfacepolicyreport_outcomeresolve_surfaceusageverifyBlocks typosquatted or hallucinated npm/PyPI packages before an AI agent installs them.
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.
Add one secure layer between your agents and this server.