Readout

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses what is returned (facts only), the provenance of each fact ('address of the body that published it'), and the tool's limitation ('does not say whether to install'). It is transparent enough for an agent to know the tool performs a read-only lookup with no side effects.

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 front-loaded with the call to action and maintains a dense, no-waste style. Every sentence adds value: usage timing, fact list, provenance, and boundary of the tool's scope. It is appropriately sized for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description fully compensates by enumerating the exact categories of facts returned and their source addresses. It also clarifies the tool's decision-support role. For a two-parameter tool with this clear scope, the description is 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 coverage is 50% — the 'name' parameter has a description, but 'registry' only has an enum with no explanatory text. The body description adds context about package provenance, advisories, repository status, and publication time, but does not explicitly explain how the registry enum values (npm, pypi, crates) affect the lookup or the returned facts.

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 opens with a specific verb and resource: 'Call this before adding a dependency to a project.' It clearly enumerates the exact facts returned and explicitly states what it does not do, distinguishing it from sibling tools like check_package or check_stack by focusing on pre-install dependency vetting.

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 provides strong usage guidance: 'Call this before adding a dependency' and explicitly says it 'does not say whether to install.' It implies this is a decision-support tool rather than a policy tool, but it does not explicitly name alternative sibling tools or when not to use it beyond the final clarifying sentence.

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?

Since no annotations are provided, the description carries the full burden of transparency. It discloses the data source ('read daily from endoflife.date'), the scope ('Covers about two dozen products'), and the type of output (security-fix status and migration target). It does not detail error handling or return format, but this is adequate for a simple lookup tool.

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

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

The description is two sentences, with the purpose front-loaded in the first sentence and usage rationale in the second. The second sentence is slightly verbose but remains focused and actionable. It is concise without being terse, and every sentence contributes to understanding the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only EOL check with two well-documented parameters and no output schema, the description adequately covers purpose, data source, freshness, and usage timing. It does not explicitly address invalid product names or the exact response shape, but these gaps are minor given the tool's simplicity and schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage for both parameters ('product' and 'cycle') with descriptions and examples. The tool description adds some context by framing products as 'runtime, database or framework' but does not significantly enhance the schema's parameter semantics, so a baseline score is appropriate.

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

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

The description clearly states the tool's function with a specific verb 'Check whether' and identifies the resource as 'a runtime, database or framework release' plus the outcome 'still receiving security fixes, and what to move to.' This distinctly separates it from sibling tools like check_package or check_stack, which focus on different aspects.

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 explicit usage guidance: 'Use it before recommending or accepting a version pin' and explains why (training data staleness). However, it does not name specific alternative tools or state when not to use it, so it provides clear context without full exclusion criteria.

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?

With no annotations provided, the description carries the full transparency burden. It discloses the exact fields returned (weekly downloads, OpenSSF scorecard, advisory count, licence, archived status, last push) and the edge case for uncovered packages (covered:false and 'not being judged'). This is meaningful behavioral context beyond a simple 'read' operation.

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

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

Two concise sentences that front-load the purpose and then provide a compact list of output fields plus the fallback behavior. Every clause contributes value; 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?

Given the simplicity of the two parameters and the absence of an output schema, the description is notably complete. It enumerates the return data points and the covered:false behavior, giving an agent sufficient context to understand what will be returned and how limitations apply.

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 50% (name described, registry not). The description adds no parameter-specific guidance beyond what's in the schema, but the two parameters are simple and the registry enum constrains values. The description does not clarify how to specify registry/name in tandem, so it doesn't fully compensate for the schema gap.

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

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

The description uses the specific verb 'Read' and clearly identifies the resource ('one open-source package') plus the exact data points returned. The mention of a curated watchlist and covered:false behavior distinguishes it from sibling tools like check_eol and check_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 explicit 'when to use' or 'when not to use' guidance referencing alternatives. However, the coverage limit ('curated watchlist of around 400 projects') and the covered:false fallback imply that this tool is for watchlisted packages, which gives some context but no comparison with sibling check 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?

No annotations are provided, so the description carries the transparency burden. It explicitly states the action is 'Read' (non-mutating) and adds a critical behavioral caveat that the count measures announcements, not actual breakages, and that a low number is not good. This goes beyond a simple factual statement to help interpret results 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?

The description is three sentences, front-loaded with the main purpose, then adds scope and an important interpretive caveat. Every sentence earns its place; no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool (2 optional params, no output schema), the description is fairly complete: it explains what data is returned (count, recency, titles) and includes an important caveat for interpretation. It could specify return structure more explicitly, but the provided hints and schema coverage suffice for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes both parameters (days window, provider slug) with 100% coverage, so baseline is 3. The description adds marginal context like 'how recently' and 'about twenty services', but does not significantly extend meaning 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?

The description clearly states the tool reads a provider's announced incident history, including count, recency, and titles. It specifies a distinct resource (provider incident history) and scope (~20 services), but does not explicitly name or differentiate from sibling tools like check_eol or check_package.

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

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

The description implies when to use it: to read archived provider incident history even after official status feeds stop carrying it. It also clarifies that the count reflects announcements, not actual outages, providing interpretive guidance. However, it does not explicitly mention 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?

There are no annotations, so the description itself must convey behavior. It explicitly labels the operation as a read ('Read a whole dependency list at once'), signaling a non-destructive action, and lists the kinds of results returned. It does not mention limits, errors, or external API calls, but the read-only nature is clearly disclosed.

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 purposeful sentences, front-loaded with the core action and followed by concrete report criteria and a usage example. 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?

The description covers what the tool does, when to use it, and what it returns at a high level, and combined with the schema, an agent has enough to select and invoke it. Exact return shape and edge cases are left unspecified, but the intended use case is clearly described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema documents 'names' as package names up to 100, and registry is an enum. The description adds missing context by tying registry choices to manifest files (package.json, requirements.txt, Cargo.toml) and framing names as the parsed dependency list. This helps an agent map inputs to the appropriate values but does not fully spell out the registry-to-ecosystem mapping.

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 opens with a specific verb ('Read') and resource ('whole dependency list'), and enumerates the exact report categories (archived, advisories, source-available licence, inactivity, stack median). This clearly differentiates it from sibling tools like check_package, which presumably handles individual packages.

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

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

It gives a direct usage cue: 'Use this when reviewing a package.json, requirements.txt or Cargo.toml.' This implies the batch/stack context and maps to the registry enum, but it does not explicitly exclude single-package checks or name check_package as the alternative.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by stating that the tool 'compares only', does not rank, and does not total across incommensurate measures. It does not detail return format or side effects, but for a read-only comparison tool, the disclosed limitations are meaningful and go beyond what annotations would've conveyed.

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

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

The description is two sentences: the first states the main action and scope, the second clarifies limitations. It is front-loaded, uses precise language, and contains zero filler. Every word contributes to understanding what the tool does and what it doesn't do.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (two parameters, no output schema), the description is complete enough for an agent to select and invoke it. It lists the comparison metrics, clarifies the scope, and notes the lack of ranking/totalling. It doesn't describe the output format, but with no output schema, that is a minor gap given the obvious 'comparison' result expectation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers both parameters fully with descriptions 'Repository as owner/name.' for both 'a' and 'b'. The tool description does not add any additional parameter-specific semantics, so it does not exceed the baseline of schema coverage. The context of 'watched repositories' is implicit in the description but not tied explicitly to the parameters.

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

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

The description clearly states the tool's function: it holds two watched repositories against each other across a specific set of metrics (downloads, OpenSSF scorecard, advisories, forks, stars, findings). It uses an explicit comparison verb and resource, and distinguishes itself from siblings like search_repositories and check_package by focusing on pairwise comparison.

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 provides clear context for when to use the tool—when you need to compare two repositories across specific measures. It also includes an exclusion ('does not rank') and clarifies that measures are not totalled across different units. However, it does not explicitly name alternative tools for ranking or other purposes, so it stops short of full when/alternative guidance.

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?

With no annotations provided, the description carries the full burden. It adds valuable context about data freshness (catalogue read daily), price volatility, and the uniqueness of the data source. It does not describe return format or potential side effects, but for a read-only find operation, the key behavioral traits are covered.

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

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

The description is two sentences, front-loaded with the primary purpose and immediately followed by usage context. Every sentence earns its place, with no redundant fluff or repetition of schema 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?

The tool has 5 parameters and no output schema, yet the description provides sufficient context for selection: what it does, when to use it, and the dynamic nature of the data. It does not describe return structure, but that is arguably unnecessary for a straightforward 'find' tool and the absence of an output schema lowers the burden.

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 80%, so baseline is 3. The description adds meaningful semantic detail for the 'sort' parameter, especially 'price-per-context', explaining it as 'the right ordering when the job needs the window' and that it's 'published nowhere else'. This goes beyond the schema's enum 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?

The description explicitly states the tool's function: 'Find language models by price and context window', which is a specific verb and resource. It clearly distinguishes from sibling tools (which concern EOL, packages, providers, etc.) by focusing on model catalogue lookup.

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 explicit when-to-use guidance: 'Use this before choosing a model' and explains the rationale (prices change weekly, no dated record elsewhere). However, it does not explicitly name alternatives or say when not to use, so it misses the top criterion.

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?

With no annotations, the description must carry the burden of behavioral disclosure. It conveys that this is a read-only search/find operation and mentions the output includes 'current readings', but it does not explain what 'readings' are, whether any state changes occur, or details like pagination or sorting. This is adequate 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?

The description is two sentences with no wasted words. It front-loads the main action and follows with a clear usage directive, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description should explain return values more thoroughly. It mentions 'with their current readings' but does not specify the format or meaning of those readings, nor default limit behavior. Still, for a simple search tool, the description covers the essential use case adequately.

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 for parameter meaning. The phrase 'name contains a string' clarifies the semantics of the 'query' parameter, but the 'limit' parameter is not mentioned at all. Given only two parameters, this partial compensation is sufficient for a baseline score.

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 uses a specific verb ('Find') with a specific resource ('watched repositories') and a clear filtering criterion ('name contains a string'). It also distinguishes itself from sibling check tools by positioning itself as a discovery step, making its purpose distinct and unambiguous.

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

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

The description provides explicit guidance on when to use it: 'Use it to discover what is covered before calling the other tools.' While it doesn't explicitly name alternatives or state exclusions, the context clearly separates it from the sibling check tools, which are the 'other tools' referenced.

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