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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description usefully discloses that a remote OSV querybatch is executed (consistent with openWorldHint) and that licence summarisation happens, but it is silent on precedence when both path and text are supplied, network failure behavior, size limits, and what the response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two tight sentences with no filler, front-loading the accepted inputs before the processing behavior. Slightly dense in the format list, but every clause carries information an agent needs.

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 and no parameter descriptions, the description should say more about what comes back (vulnerability findings plus licence summary, and in what shape). It covers inputs well but leaves the return contract and the path/text interaction implicit, which is a meaningful gap for a 3-parameter 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?

Schema description coverage is 0%, so the description carries real burden and it does add value: it maps the four enum values to concrete lockfile formats and notes constraints such as package-lock v2/v3 and pinned requirements.txt. It also glosses 'text or a local path' for the two string inputs, but never states mutual exclusivity, precedence, or that all three parameters are optional.

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 specific verbs and resources: parses named lockfile formats from text or a local path, then runs an OSV querybatch and summarises licences. That is far more specific than a restatement of the name, but it does not differentiate itself from siblings like check_vulnerabilities or license_check, which appear to cover overlapping ground.

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?

No when-to-use guidance and no mention of the obvious alternatives. An agent cannot tell from the description whether to call audit_lockfile or to call check_vulnerabilities and license_check separately, nor when a whole-lockfile audit is preferred over those narrower tools.

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

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

The annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds useful context that partial source failures are reported per source, which is meaningful behavior beyond the annotations, though it does not mention rate limits or output structure.

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 short sentences with no wasted wording, and the primary usage mode is front-loaded before the partial-failure note.

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 should explain what a vulnerability query returns, but it only mentions per-source partial failures. It also omits details about the ecosystem parameter and batch constraints, leaving significant gaps for an open-world query 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?

Schema description coverage is 0%, so the description must carry parameter semantics. It distinguishes the name/version path from the packages batch path but says nothing about the ecosystem parameter, enum values, batch limits, or the fact that top-level parameters are technically not required.

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: query OSV.dev for a single package@version or a batch. It clearly distinguishes the single-package and batch modes, though it does not explicitly differentiate itself from siblings like audit_lockfile or get_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?

It implies when to use the tool by naming OSV.dev and the two supported input modes, but it gives no explicit guidance about when to choose this over audit_lockfile, license_check, or get_package.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds a genuinely useful trait beyond the annotations: partial-failure isolation, meaning one bad package won't drop the rest. It stops short of describing output structure or rate/limit behaviors, so it is good but not rich.

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 short sentences, front-loaded with the core action and cardinality, with the failure-tolerance note second. Every sentence earns its place; nothing is padded.

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 should convey what a comparison returns and which attributes are contrasted; it says nothing about that. Combined with 0% parameter description coverage, an agent knows what the tool does but not what it will get back or how to shape the input beyond the schema's structural hints.

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 carries the burden for a nested parameter object with name, version, and ecosystem. The phrase '2 to 5 packages' mirrors minItems/maxItems from the schema rather than adding new meaning, and it does not clarify that version is optional or what ecosystem values mean. Baseline adequacy, but a real gap given zero 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?

States a specific verb (compare) and resource (packages) with a clear cardinality constraint of 2 to 5, which distinguishes it from single-package siblings like get_package. However, it never says what dimensions are actually compared (versions, vulnerabilities, licenses, scores), leaving the resource's scope partly underspecified.

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 2-to-5 range implies usage constraints, and naming partial-failure tolerance gives some context. But there is no explicit guidance on when to use this versus calling get_package or get_scorecard individually, and no exclusions or prerequisites are stated.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds genuinely new facts: the graph is depth-limited, the default is 2, and the data comes from an external service (consistent with openWorldHint). It says nothing about what 'resolved' entails, pagination, or failure modes when a package is unknown.

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 short sentences, front-loaded with the action and resource, and the depth constraint is packed into the same breath. No filler, no restatement of the title.

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 and zero parameter coverage, an agent still cannot tell what the graph looks like (node/edge shape, how resolution conflicts are reported) or what the version/ecosystem parameters require. For a four-parameter, network-backed tool, the definition is too thin to call reliably without guessing.

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 must carry parameter meaning, but it only explains depth (default 2, cap 4) — the one piece of information the schema does not already give. The three required parameters (ecosystem, name, version) and their expected formats/relationship are left entirely unexplained.

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 ('Return a ... resolved dependency graph') plus the data source (deps.dev), which clearly separates it from metadata siblings like get_package and get_version. It stops short of naming a sibling or contrasting behavior, so it is clear but not fully differentiated.

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?

No when-to-use guidance at all: nothing says to reach for this over get_package, compare_packages, or audit_lockfile when the agent needs transitive dependency information. Only the name and purpose imply usage, and there are no exclusions or prerequisites stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds genuinely useful context beyond them: the upstream data source (deps.dev) and an enumeration of returned fields, which matters because no output schema exists. It omits not-found/error behavior for unknown packages, keeping it at 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two tight sentences with zero filler: the verb, ecosystem coverage and source come first, the payload second. Every clause carries information an agent cannot get from the schema.

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 lookup with no output schema, describing the returned fields is the key compensation, and it does that. The remaining shortfall is the optionality and semantics of the version parameter, which is undocumented in both schema and description.

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 carries the burden, and it partially does: the ecosystem list mirrors the enum values and "versions, latest" gestures at the version parameter. But it never says version is optional or that omitting it yields the latest, nor how name is scoped per ecosystem — a notable gap given zero schema documentation.

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 ("Look up a package") plus the backing source (deps.dev) and enumerates all seven supported ecosystems, so scope is unambiguous. It also lists what comes back (versions, latest, licences, links, deprecation). It stops short of naming the nearest siblings (get_version, search_packages) to draw the boundary, so a 4 rather than a 5.

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

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

Usage is only implied: the returned-fields list hints that you call this when you need package metadata rather than dependency graphs or vulnerabilities. With nine siblings including get_version, search_packages and license_check, no explicit when-to-use-this-vs-that guidance is given, leaving real ambiguity for an agent choosing between them.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that external resolution goes through deps.dev, which is useful context beyond annotations, but it says nothing about failure behavior when a package can't be resolved, or about data freshness/caching.

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 front-loaded sentence with zero filler; both operating modes are stated compactly and nothing is repeated from structured fields.

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 rich annotations and no output schema, the description covers what is fetched and the two input routes, which is close to sufficient. The remaining gap is the parameter-to-mode mapping, which matters for a tool where all four parameters are optional and mutually dependent.

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 schema provides four opaque strings and an ecosystem enum with no meaning attached. The description partially compensates by revealing two input shapes (repo name vs. package identity), but it never maps 'name', 'project', 'version' or 'ecosystem' to those shapes, and leaves requiredness (0 required params) ambiguous.

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 ('Fetch an OpenSSF Scorecard report') and adds the scope: either a GitHub repo directly or a package resolved via deps.dev. This is clearly distinguishable from siblings like get_package or get_dependencies, though it doesn't name a sibling to route against.

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 two operating modes are implied by 'for a GitHub repo, or resolve the repo from a package via deps.dev', which hints at when each input shape applies. However, it never states which parameters select which mode, nor any exclusions or prerequisites (e.g., must supply name OR project+ecosystem).

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered; the description adds valuable payload disclosure (licences, advisories, links, SLSA/provenance) and the conditional "when present". It does not state what happens on a missing version or an unsupported ecosystem.

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 short sentences, zero waste, with the identifying constraint front-loaded and the value proposition second.

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 3-param read-only lookup with no output schema, the description covers what is returned and that some fields are conditional. The remaining gap is miss/error behavior and parameter formatting.

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 carries the burden, yet it only hints that the version must be exact rather than a range or "latest". It says nothing about ecosystem enum values, the name format, or how the three required fields combine.

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

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

States a concrete verb ("Look up") and a precise resource scope ("one exact package version on deps.dev"), and enumerates the payload (licences, advisories, links, SLSA/provenance). This implicitly separates it from search_packages and get_package, but no sibling is named.

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 "one exact package version" implies you must already know a pinned version, which hints at when to use it versus a package-level or search tool. However, no explicit when-to-use/when-not or alternative tool is named.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real value by disclosing the evaluation rule (AND requires every branch, OR requires one), but says nothing about the result shape, how failures are reported, or how operators like WITH/+ are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two dense sentences with zero padding, and the purpose is front-loaded before the evaluation rule. 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?

The tool is simple (2 required params, no output schema) and annotations carry the safety profile, but with no output schema the description should say what 'evaluate' returns (boolean pass/fail, list of failing identifiers?). That omission is the main remaining gap for correct invocation and interpretation.

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 must compensate. It does partly: 'expression' is scoped to SPDX 2.x and 'allow' to SPDX identifiers, which rules out free-form or regex matching. But it gives no format examples, case-sensitivity, or whether 'allow' may itself contain expressions, leaving gaps.

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 (evaluate) and resource (SPDX 2.x expression against an allow-list of SPDX identifiers), which is clearly distinct from the package/dependency-oriented siblings. It doesn't explicitly name a sibling or boundary, which keeps it short of a 5.

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

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

The second sentence explains AND/OR evaluation semantics, not when to reach for this tool versus e.g. get_package or audit_lockfile. There is no stated context, prerequisite, or exclusion; an agent must infer that this is the license-compliance gate.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower. The description adds genuinely new behavior: it discloses which fields are surfaced and that sensitive values are never returned, which is important for an agent deciding whether it can inspect config safely.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two tight sentences with the resource and returned fields front-loaded, followed by a single crucial non-disclosure caveat. No 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 parameters and no output schema, the description carries the burden of describing the return shape, which it does by enumerating the four kinds of information. It could note the container/format (e.g. a list of source objects), but an agent has enough 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline applies. The description correctly implies a parameterless, whole-set listing.

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?

Specific verb 'List' plus the resource and the exact fields enumerated (sources, enforced rates, terms links, PKGINTEL_CONTACT status). It reads clearly as a configuration/metadata enumeration tool and is distinguishable from data-fetching siblings like get_package or get_version.

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?

Usage is implied: an agent would call this to discover upstream registries, rate limits, and whether contact info is configured. There is no explicit when-to-use/when-not or reference to an alternative tool, so the agent must infer the trigger condition.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description usefully adds that only two of the seven enum ecosystems are searchable, but it does not say what actually happens if ecosystem='pypi' is passed (error vs. empty result), which is the one behavioral question an agent will have.

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 short sentences, zero waste, and the applicability constraint is front-loaded before the fallback instruction. 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?

No output schema exists, and the description says nothing about the return shape (list of results, ranking, fields per result), which would help an agent plan next steps. Otherwise complete for a read-only search tool whose safety profile is carried by 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies the most important parameter, ecosystem (only npm/cargo are valid despite the seven-value enum), but says nothing about query semantics or the limit cap of 25, leaving half the params unexplained.

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 (Search) with the resources it applies to (npm / crates.io) and immediately bounds the scope by naming the sibling that handles everything else. An agent can distinguish it from get_package 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?

Explicitly says where search works (npm, crates.io), where it does not (PyPI), and what to do instead for other ecosystems (exact name via get_package). This is a full when/when-not/alternative routing statement.

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