Agent Provider Depot

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

The annotations already establish that this is a read-only, non-destructive, idempotent, non-open-world operation. The description adds useful return-shape details and a failure mode ('Depot doesn't cover X yet'), but it does not cover permissions, rate limits, or other behavioral context beyond output 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?

The description is short and avoids wasted prose, but it is densely compressed into cryptic fragments and output-field lists. It is not front-loaded with a clear purpose, which makes the compactness work against readability.

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?

This is an 11-parameter tool with no output schema, so the description needs to carry significant explanatory burden. It partially describes the return shape and one volume behavior, but it leaves most parameters and the overall usage context incomplete.

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 64% across 11 parameters, so the description must compensate, but it only gestures at 'task,' 'stack context,' and 'volume.' It leaves compact, pricing, sender, existing, framework, maxMonthly, noUsageBilling, and maxPriceAgeDays unexplained in prose.

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 implies the tool takes a task in words and returns a recommendation with pick, runner-up, price, free option, and rationale, but it never states the core purpose in a clear verb+resource form. It is more an output-shape sketch than a purpose statement, and it does not distinguish itself from siblings such as decide, compare, or quote.

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?

There is no explicit guidance on when to use this tool instead of alternatives. The title calls it a 'front door,' but the description does not say when this one-call answer is preferred over sibling tools or what circumstances should route elsewhere.

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, closed-world behavior, so safety is covered. The description adds useful payload context ('< 3 KB') and that results are mapped to live Depot Picks, but it omits what the response looks like and the important edge case that a call with no inputs at all has undefined behavior.

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 no filler; the version/token examples earn their place by making detection concrete. The long parenthetical package list makes it slightly dense to scan, but nothing is redundant.

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 5-parameter tool with a nested object (packageJson) and no output schema, the description should clarify what the audit returns and how multiple input modes combine. It covers what is detected but not the result shape or input precedence, leaving a real gap.

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 each of the five parameters is already documented with examples. The description's package/model lists overlap with the schema examples rather than adding new semantics (e.g., precedence when both packages and packageJson are supplied) — 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 ('repository manifest auditor') plus concrete detection targets: deprecated npm/pip packages, retired model SKUs, and .env keys. The enumerated examples (request, bull, gpt-4-0613, text-embedding-ada-002) make the scope unambiguous and distinguish it from generic siblings like check or stack.

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?

'One-call' implies this is the single entry point and no alternatives are needed, and the input types hint at when it applies (you have manifests or a dependency list). But it never says when to prefer this over check, stack, changes, or coverage, nor what happens if all inputs are omitted given 0 required parameters.

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds useful details about compact contexts and unit-scoped pricing, but does not explain result ordering, per-job failure behavior, or output shape.

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 short sentences with the primary purpose front-loaded, followed by compact-context and pricing-unit details. Every sentence carries useful information, and there is 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?

For a composite tool with six parameters and no output schema, the description covers the main purpose, the 10-item limit, compact mode, and unit-scoped pricing. It leaves important context unexplained, including the 'constraints' parameter, the 'jtbd' alias, and what the returned bundle structure looks like.

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 50% schema description coverage, the description adds meaningful semantics for key parameters: 'up to 10 JTBDs' for jtbds, 'compact=true for small context windows' for compact, and the maxUsd/maxUnit relationship. It does not explain the 'constraints' comma list or the 'jtbd' alias, so some gaps remain.

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 composite operation over JTBDs: decide, quote, free, and failures in one call, with a clear limit of up to 10. It distinguishes the batch tool from individual sibling tools implicitly, but does not explicitly name when to use it instead of decide/quote/free/failures.

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 'for up to 10 JTBDs in one call' implies the batch usage context, and 'compact=true for small context windows' gives one parameter-level usage cue. However, it does not explicitly state when to use this tool versus the individual sibling tools, nor when not to use it.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful scope by saying only CHANGELOG entries and rows with stored dates on or after since are returned, but it omits ordering, limit defaults, and pagination behavior.

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 a single front-loaded sentence with no filler. It communicates the data scope and the inclusive date filter efficiently.

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 read-only tool with annotations covering safety, this is minimally adequate. However, it omits the limit parameter's default or purpose and provides no output schema or description of result ordering, so an agent lacks some invocation-relevant 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?

The required since parameter is already described in the schema, and the description only adds that filtering is inclusive (on or after). The optional limit parameter has no description in the schema and is not mentioned in the description, leaving half the parameters semantically undocumented.

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 resource and filter: CHANGELOG entries and rows with stored dates on or after a given date. It does not differentiate this tool from similar siblings such as freshness, audit_repo, or stack_delta, so an agent must infer the boundary from the name alone.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling alternative is named. The date filter implies a usage scenario, but the agent is left to infer when this tool is preferable to freshness or audit_repo.

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?

Beyond the annotations, the description explains the flag vocabulary, the meaning of ok=false, the default failOn values, and that an unknown provider is status unknown rather than an error. It also clarifies that retirement_announced is warning-only and that require checks sourced security records, which is substantive behavioral context.

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 dense but front-loaded and contains no obvious filler; each clause carries flag or gating semantics. Its long single-paragraph enumeration of flags makes it less structurally scannable than it could be.

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, but the description explains the key return semantics: per-provider flags, ok=false behavior, default failOn, and unknown handling. The main remaining gap is the undocumented jobs parameter.

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, the description must carry parameter meaning. It successfully explains failOn, require's enum values, and the provider context, but it never directly documents the jobs parameter, so coverage is only partial.

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 action ('Flags for each provider in a stack') and a clear gate outcome ('ok=false when a provider has a flag in failOn'), so the core purpose is legible. It does not explicitly distinguish this tool from close siblings such as stack, coverage, or compare, which keeps it below 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 title and the failOn/ok=false behavior imply this is a CI gate, giving an agent an implied usage context. However, the description never explicitly says when to use this versus siblings, nor does it name alternatives or exclusions.

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 and closed-world, so the safety profile is fully covered. The description usefully names what the comparison returns (scores, unit price, free rows), but does not say anything about ordering, missing data, or what happens with invalid provider ids.

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, front-loading the core action and the comparison dimensions. Density of domain jargon ('JTBD', 'job-unit price') is the only mild cost to readability.

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 does partially compensate by enumerating the returned rows (scores, price, free). However, weighting mechanics and the shape of the result are left implicit for a tool whose whole purpose is producing a comparison output.

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 50%: `jtbd` only says 'optional JTBD id', and the description improves on that by explaining it drives weighting. The '2–5 providers' phrasing repeats the schema's min/max rather than adding meaning, and the comma-separated string alternative for `providers` is left 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 action (side-by-side comparison) and resource (2–5 providers) plus the dimensions compared: stored scores, job-unit price, free rows, optional JTBD weighting. It is clearly a comparison tool, though it never names a distinguishing sibling (e.g. 'free' or 'quote') that could otherwise be mistaken for it.

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 mention of 'optionally weighted for one JTBD' implies the comparison use case, but there is no explicit when-to-use or when-not-to-use guidance. Siblings such as 'free' and 'quote' overlap in domain and the description gives no rule for 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 this as read-only, idempotent, non-destructive, and closed-world. The description adds the returned boolean fields and filtering behavior, but it does not explain response structure, interpretation of the booleans, or deeper behavioral context.

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 short and front-loads the coverage output before the optional filter. It is efficient, though the telegraphic phrasing makes it slightly less clear than it could be.

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 carry more of the return-value burden. It names the boolean fields but does not explain their meaning, the overall response shape, or how coverage is determined, leaving gaps for 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 100%, so q is already fully documented in the schema. The description repeats the same filter semantics without adding new parameter-level detail, which matches the baseline for high 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 identifies the resource and output shape: coverage booleans per agent class need, naming the specific fields returned. It is understandable but does not explicitly state a verb such as 'returns' or distinguish itself from the many sibling 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?

It explains only that q is an optional filter; there is no guidance on when to use this tool versus siblings like free, kit, or search. The agent must infer its role from the purpose alone.

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 establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds useful behavioral detail beyond annotations: compact output under 4 KB by default, full=true for full plan tables, and how constraints are matched against whenNotTopPick.

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 a single dense sentence with the key output components front-loaded and the compact-versus-full behavior in parentheses. It is efficient and appropriately sized, though the jargon makes it slightly less readable than it could be.

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 does useful work by listing return components and the compact/full size tradeoff. It still leaves gaps around when to choose this tool versus alternatives and what a 'Depot Pick' decision card fundamentally represents, so it is adequate but incomplete.

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 meaning beyond the schema: it clarifies that jtbd identifies one JTBD, that full switches from compact output to full plan tables, and that constraints are matched against whenNotTopPick. The schema documents the fields, while the description explains their behavior in the decision-card 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 names the artifacts returned — Depot Pick, runners-up, whenNotTopPick skip rule, and cite string — and scopes them to one JTBD, so the agent can infer this is a decision-card tool. However, it uses a noun phrase rather than a clear verb and leans on domain jargon ('Depot Pick', 'whenNotTopPick'), so it does not crisply distinguish the tool from siblings like compare or quote.

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 gives no explicit when-to-use guidance, no exclusions, and no named alternatives. The only implied usage is that it operates on one JTBD, and the constraints note explains matching behavior rather than selection context.

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/closed-world, so the safety bar is met. The description adds genuine context beyond that: it returns list prices only, it never mutates a selection, and on failure it returns null with a reason rather than erroring — all useful for an agent's planning.

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 that lead with the return value and then the input format; nothing is padding. The telegraphic style ('workload: metric=value pairs...') is efficient though slightly clipped.

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: monthly cost, arithmetic string, or null with a reason. Combined with a fully described two-parameter schema, an agent has enough to call it correctly; only explicit sibling routing 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. The description goes further by defining the workload grammar beyond the schema's examples — 'metric=value pairs or a bare number in the job's primary metric' — which tells the agent a shorthand form the schema does not document.

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 computed resource: monthly cost per candidate from plan limits (base + included + overage), including the arithmetic string or a null with reason. It is clearly distinguishable from listing tools like quote/bundle, though it only gestures at the decision siblings with 'never changes a pick' rather than naming them.

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?

'List prices only; never changes a pick' implies this is an informational estimate rather than a decision step, and 'or null with a reason' signals the failure path. But no alternative sibling (e.g. quote, compare, decide) is named with a condition that selects it, so the when-to-use guidance remains implied.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered without the description. The description contributes one useful behavioral fact beyond that — that each entry is paired with detection guidance, i.e. the payload is prescriptive, not just a name list — but says nothing about scope, ordering, or how many modes appear.

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?

One short sentence with zero padding and the key content (detection guidance) front-loaded. It is slightly under-specified rather than over-long — adding a verb such as "lists" would cost no words but gain clarity.

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-parameter, read-only tool with annotations carrying the safety profile, the description covers the essentials and hints at return contents. With no output schema, a clearer statement of what a caller actually receives (a reference list vs. diagnostic output) would close the remaining gap.

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, and the description correctly implies a single unfiltered catalog with no arguments. Baseline 4 applies for a no-parameter tool; nothing in the text misleads about 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?

"Agent failure modes with how to detect each" conveys the resource and its content shape (detection guidance per item), but it is a bare noun phrase with no verb, so the agent must infer that this enumerates/returns a catalog rather than taking an action. It also gives no cue distinguishing it from the sibling rescue_failure, which is the closest adjacent concept.

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?

There is no when-to-use guidance, no prerequisites, and no routing hint to alternatives. With rescue_failure sitting in the sibling list, an agent could plausibly invoke either and gets no help from the description.

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=true, idempotentHint=true, and destructiveHint=false, so "never changes a pick" largely restates what is structured. It does add a small domain hint that picks are a separate concept unaffected by this tool. Return shape and result volume are not described, though the read-only profile is covered by 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 short sentences with no padding, and the scope claim comes first. However, the compression is so aggressive that key terms ("Sourced", "jtbdIds", "pick") are undefined, so brevity costs comprehension rather than buying it.

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 two-parameter read tool with no output schema, the description is minimally sufficient to attempt a call. It omits the return shape and the meaning of the free/kind categories, which an agent would need to interpret results. Annotations cover the safety profile, so the remaining gap is moderate rather than severe.

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 both parameters (jtbd, kind) carry schema descriptions, so the schema handles the semantics. The description adds nothing beyond the schema about the jtbd id format or what values "kind" accepts, and notably neither parameter is required despite the lookup seeming to need a jtbd.

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 implies a filtered lookup of $0/OSS resources matched by jtbdIds, but the verb is never stated and the wording is dense jargon ("Sourced $0 / OSS rows", "jtbdIds"). Compared with siblings like search, kit, and stack, nothing distinguishes when this narrow lookup is the right one.

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?

There is no statement of when to use this versus search, bundle, stack, or kit, and no prerequisite or exclusion information. The only guidance-like sentence, "Free never changes a pick," is a side-effect claim rather than a usage rule. An agent must infer the scenario entirely.

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/closed-world, so the safety profile is covered. The description still earns credit by adding that it will not re-score or trigger a re-fetch, and by enumerating the three things it reports (ages, latest re-check, stalest picks). It omits how many items come back and whether results are ordered.

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 dense sentence with the payload front-loaded and the key exclusion ('Never re-scores') placed last for emphasis. It is tight, though the stacking of Depot-specific jargon (ageDays, staleAfterDays, Depot Picks) makes it slightly hard to parse on first read.

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 documentation, the description has to carry the return shape, which it does partially by listing what is reported. The gaps are the `limit` semantics and the absence of any cue about ordering or defaults. Adequate to call correctly, but not 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?

There is one parameter, `limit` (1-198), and the schema provides zero description coverage for it. The description mentions 'stalest Depot Picks' but never explains that `limit` controls how many of those picks are returned, nor what happens when it is omitted. With no schema text to fall back on, this gap is left entirely unaddressed.

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 the specific resource (Depot's scores, prices, free rows, source re-check timestamps, stalest Picks) and frames it around ageDays vs staleAfterDays, which is more concrete than the bare name 'freshness'. It also states the negative ('Never re-scores'), which separates it from tools like check or changes. It stops short of a clean verb+object framing, but an agent can tell what it gets back.

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?

'Never re-scores' implies this is a diagnostic/inspection call rather than a verification or refresh, which is useful inference. However, no sibling is named and there is no explicit condition for choosing this over coverage, check, or changes, so the agent must infer when staleness reporting is the right call.

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 establish that this is a read-only, idempotent, non-destructive, closed-world call, so the safety profile is covered. The description usefully hints at the response composition ('quoting', 'free rows', 'failures', 'studies'), but the terms are undefined jargon that do not let an agent predict the payload. 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?

A single front-loaded sentence with no filler; the class list is compact. The ambiguity comes from under-specification rather than verbosity, so conciseness itself is good.

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 aggregation tool with no output schema, the description should explain what the kit contains and how the cost filter changes the result. It leaves both unanswered, so an agent cannot confidently predict the response or when the 'free' variant differs.

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 partially covers 'class' by listing example values already present in the enum, but adds nothing about 'cost' (enum 'free') – the agent cannot tell what filtering by cost actually does.

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 the resource ('a kit for an agent class') and enumerates contents ('picks, quotes, free rows, failures, studies'), but never states the verb or the return shape, so it is unclear whether this assembles, retrieves, or summarizes. It is distinguishable from most siblings only through the per-class scoping, not through an explicit contrast with tools like 'bundle' or 'stack'.

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?

There is no guidance on when to call this versus the many overlapping siblings ('bundle', 'stack', 'quote', 'free', 'failures', 'compare'). Usage can only be inferred from the parenthetical list of agent classes; no prerequisites or exclusions are given.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds non-obvious behavioral constraints: 'Input/output never blended; units never converted,' which is useful context beyond the 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 short sentences with no wasted text, and the unit/blending constraint is compactly stated. However, it starts with an output fragment rather than a clear action, and the jargon slightly reduces front-loaded clarity.

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 and annotations cover safety, but there is no output schema, so the description should carry more responsibility for explaining return values. It gives a high-level sense of the quote contents but not the shape, count, or error behavior.

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?

There is only one parameter and schema description coverage is 100%, with 'jtbd' documented as 'JTBD id' in the schema. The description adds no further meaning about the parameter, so the baseline for fully covered schemas 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 indicates output composition (sourced SKUs, cheapest SKU) and a unit constraint, but it lacks a clear action verb and does not distinguish the tool from sibling tools such as estimate. An agent can infer it returns a quote, but only after parsing domain-specific phrasing like 'Depot Pick'.

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?

There is no guidance on when to use this tool versus alternatives, despite sibling tools like estimate and bundle that could plausibly overlap. The description gives no prerequisites, exclusions, or routing cues.

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, non-destructive, and closed-world, so safety is covered. The description adds that the tool is a lightweight (< 2 KB) interceptor returning a fix plus a 'verified fallback route,' which is useful output context, but it never explains what 'verified' means, whether the fix is deterministic, or what happens when no match is found.

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 that front-loads the core concept and then enumerates the covered failure classes; no filler sentences. It is dense and jargon-heavy ('search-at-failure interceptor'), but nothing is wasted.

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 four all-optional parameters, no output schema, and no annotations gaps to fill on safety, the description should explain the relationship among 'q', 'sku', 'jtbd', and 'provider' and what the returned fix looks like. It gives a high-level answer (fix + fallback route) but leaves the multi-parameter invocation model and no-match behavior unaddressed.

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 already documented, including examples for 'q'. The description only reinforces that error messages, HTTP statuses, and deprecated SKUs are valid inputs, without clarifying how the optional 'sku', 'jtbd', and 'provider' fields combine with or override 'q'. 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?

The description names a specific verb-and-resource combination ('resolves ... into an immediate fix and verified fallback route') and enumerates concrete error classes (429/402/529, Cloudflare 1020/WAF, SDK import errors, deprecated SKUs). It is clear what the tool consumes and produces, though the coined label 'search-at-failure interceptor' is opaque and it never distinguishes itself from the sibling 'failures'.

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: an agent can infer 'call this when you hit one of these error strings,' but there is no explicit when-to-use, when-not-to-use, or comparison to the closely related 'failures', 'check', or 'search' siblings. The error-class list does most of the routing work by implication.

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, closed-world, so the safety profile is covered. The description adds the return-shape fact (ids, not records) which matters for chaining. It says nothing about result ranking, pagination beyond the schema's limit cap, or what happens when no match is found.

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 scope statement front-loaded before the return-value note. 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?

No output schema exists, but the description covers the return shape (ids) and the searchable corpus, which is most of what an agent needs. It leaves the type-filtering capability and result-size behavior unexplained, which is a real 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 coverage is only 33%: `limit` and `types` have no descriptions at all. The description lists the entity categories but never tells the agent that `types` can restrict the search to a subset, which is the single most valuable hint it could give. Only the `q` example carries semantic weight, and that lives in 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 ('full-text search') and enumerates the resource universe (providers, JTBDs, free resources, failure modes, case studies, agent classes, benchmark tasks), which is meaningfully broader than the single-domain siblings like `free` and `failures`. It stops short of explicitly saying how it differs from those siblings, but the cross-domain scope is inferable.

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?

'Returns ids to pass to other tools' implies the lookup-then-act workflow, which is useful routing context. However, it never says when to use this versus the dedicated `free` or `failures` tools, nor any exclusion or prerequisite.

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 safety (readOnly, idempotent, non-destructive, closed-world), so this is a read-only deterministic lookup. The description adds genuinely useful context beyond that: matching is deterministic alias-based rather than generative, guardrails are derived from negated phrases in the input, and a bundle URL comes back. It stops short of saying what happens when no alias matches.

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 dense sentence with zero filler, front-loading the input-to-output transformation before the secondary outputs. Every clause (alias match, negated phrases, bundle URL) 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 one-parameter read-only tool with rich annotations, the description covers the input meaning, the matching method, and the shape of the return (ids, guardrails, bundle URL) even without an output schema. The remaining gap is failure semantics — no match, partial match, or multiple matches — which an agent would need before relying on 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?

With one parameter and 100% schema description coverage (including an inline example), the schema already does the work, so 3 is the baseline. The description does add one small signal the schema lacks — that the task string may contain negated phrases which become guardrails — but it gives no guidance on phrasing a good multi-job description.

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 transformation: a multi-job task description becomes existing JTBD ids, with a deterministic alias-match mechanism, plus guardrails and a bundle URL. That is specific verb+resource behavior. However, it never distinguishes itself from the sibling 'stack_delta', which an agent could plausibly confuse with it, and the name 'stack' alone carries none of this meaning.

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 'multi-job task description' implies the input precondition for calling this, and describing the output as 'existing JTBD ids' hints it is a lookup against a known catalog rather than free generation. But there is no explicit when-to-use, no when-not-to-use, and no mention of stack_delta, bundle, or search as alternatives.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the payload-size claim ('< 1.5 KB') and the retention posture, which are genuinely useful, but it never says what the response contains or how 'no delta' is signalled.

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 no filler. It is dense but not padded, though the unexpanded acronyms compress meaning out rather than in.

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?

All parameters are optional and documented, and annotations cover the safety profile, so nothing critical is missing for invocation. The gap is behavioral: whether this returns a boolean heartbeat, a list of deltas, or per-provider breakdowns is left entirely to inference, and there is no output schema to fall back on.

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 parameters carry examples, so the baseline is 3. The description only echoes the 'since YYYY-MM-DD' semantics and adds nothing about how jtbds/providers interact or what happens when both are omitted.

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 verb ('checks whether') and the resource (watched providers/JTBDs with alerts, price changes, picks, receipts, gotchas) are specific, and the delta framing separates it from pure-state tools. However, coined terms like 'Zero-IP retention', 'E3/E4 outcome receipt' and 'pick update' are undefined, so an agent can't fully map them to sibling tools such as changes or freshness.

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?

'Heartbeat' and the 'since' framing imply a recurring polling use case, but no explicit when-to-use guidance is given. Siblings named changes, freshness, and check plausibly overlap and are never mentioned as alternatives or exclusions.

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