endoflife.ai — Software Lifecycle Intelligence

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuinely useful behavioral context beyond annotations: the returned fields (lifecycle status, EOL date, days remaining/past, latest release) and the semantics of eol_date_source with its five provenance values and associated source URL. 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?

Three sentences, with the purpose front-loaded and no filler. The second sentence packs the return-field disclosure, including the inline eol_date_source enum explanation, which earns its length given the value it adds. Nothing repeats what the annotations already state.

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 only two well-documented parameters, strong safety annotations, and an output schema that can carry return-value structure, the bar for the description is modest. It covers the core use case and data provenance semantics. The main gap is not pointing toward sibling tools (e.g., list_products for valid slugs, get_upcoming_eol for future dates), which would make routing fully self-contained.

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

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

Schema description coverage is 100%, with both parameters already documented via concrete examples ('postgresql', 'nodejs', 'ubuntu' for product; '14', '18', '20.04' for version), so the baseline is 3. The description maps parameters to the supported question form ('X version Y') but does not add new semantic detail beyond the schema.

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

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

The description uses a specific verb+resource: 'Check whether a specific version of a software product is end-of-life (EOL).' This clearly separates it from siblings like get_upcoming_eol (future dates) and get_product_lifecycle (broader lifecycle scope). The closing 'Use this for...' phrasing reinforces exactly what question the tool answers.

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 an explicit invocation context: 'Use this for "is X version Y still supported?" questions.' This is concrete guidance on when to call the tool. However, it does not name sibling alternatives or state when not to use it, so the routing guidance stops short of being fully explicit.

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?

Goes well beyond the readOnly/idempotent/closed-world annotations by disclosing rate limits per tier, the honest handling of unmatched components (listed, not guessed), version-to-release-family resolution, and exactly what happens when an SBOM exceeds the cap. These are the operational facts an agent needs before invoking.

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

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

Front-loads the purpose and keeps every sentence information-bearing (formats, matching, version resolution, tier limits). The 'Pass the SBOM as a JSON string or object' line mildly duplicates the schema, which keeps it just short of a 5.

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?

An output schema exists, so return shape needn't be described, and the description still covers input formats, matching semantics, truncation behavior, and quota limits. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% and both parameters are documented there, including the note that the tier cap applies before max_items. The description largely restates the sbom parameter ('JSON string or object') and adds no new semantics for max_items, so baseline 3 applies.

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

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

States a specific verb (audit/check) and resource (CycloneDX or SPDX JSON SBOM), plus what the tool does with it: map components to tracked products and score EOL risk. No sibling takes an SBOM document as input, so the resource alone separates it from check_eol and scan_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?

The description supplies usage-relevant constraints (tier caps of 5/25/50, truncation behavior on large SBOMs) but never states when to choose this tool over check_eol or scan_stack, nor any exclusions. Usage is implied by the input type rather than explained.

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 destructiveHint, and the description's 'Query' wording is consistent with those. It adds useful behavioral context about the returned data, such as KEV summary, vendor-stated successor, and provenance. 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?

The description is front-loaded with the resource and scope, then efficiently covers filter options, result content, and a usage example. Each sentence adds value 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 read-only tool with all-optional parameters and an output schema, the description provides enough scope, filtering guidance, result-content expectations, and a canonical use case for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents the model, status, and platform parameters. The description restates filtering by platform/vendor/status/model and the BOD 26-02 status vocabulary, but adds little genuinely new semantic 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 identifies a specific verb and resource: 'Query the EOS Edge Device Intelligence feed' with a well-scoped subject of edge-device end-of-support status in CISA BOD 26-02 vocabulary. It does not explicitly contrast with sibling tools such as check_eol or get_upcoming_eol, so it lacks full sibling differentiation.

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 provides an explicit canonical use case: 'which of our edge devices are past support or expire within 12 months?' and names the filter dimensions. It does not state when not to use the tool or reference alternatives, but the use-case framing gives clear 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 readOnlyHint, idempotentHint, and destructiveHint=false, lowering the bar. The description adds real behavioral context beyond them: the two-feed composition, verbatim inclusion of CISA's required-action text, and the conditional support-status join when a version is passed. No contradiction with annotations; only data freshness is left unstated.

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, front-loaded with the core purpose ('The exploited-vulnerability record for a product') before the detail. The parentheticals are dense but each earns its place — EOL relevance and the unpatchable definition — though the single long sentence is somewhat hard to scan.

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 an output schema present and safety annotations supplied, the description needn't explain return values or read-only behavior. It covers data provenance, the optional version join, and the EOL nuance; only minor items like data freshness or empty-feed behavior are absent.

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 both parameters are already documented. The description's 'Pass an optional version to include its support status alongside' largely restates the schema's 'Optional version/cycle to check support status for,' adding no new parameter-level meaning.

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

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

States a specific resource — the exploited-vulnerability record for a product from CISA's KEV catalog plus endoflife.ai's Exploited & Unpatchable feed — and enumerates the fields returned (CVEs, date added, federal due date, verbatim action text). This content-level specificity cleanly separates it from siblings like check_eol and get_risk_score without 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?

Gives clear context on when the data matters — the 'discontinue use' entries are flagged as the ones that matter for end-of-life versions — and explains the optional version parameter's effect ('include its support status alongside'). It stops short of a 5 because it never explicitly names alternatives or states when-not-to-use.

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 behavior is covered. The description adds useful behavioral scope: it returns every tracked version/cycle, with specific lifecycle fields. No contradiction with 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?

Two efficient sentences: the first front-loads the core action and returned data, and the second provides a realistic usage phrase. There is no filler or redundant explanation.

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 one well-documented required parameter, full annotations, and an output schema, the description sufficiently covers what the tool returns and when to use it. The phrase 'full version history' and the field list make the tool's behavior unambiguous for an agent.

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

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

The input schema fully documents the only parameter, including a slug/name example. The description adds only 'one product' as scope, which is marginal but not necessary since schema coverage is 100%.

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: 'Get the full version history for one product' and enumerates the returned fields (release date, EOL date, support status, EOL Risk Score). This clearly distinguishes it from siblings like check_eol and get_upcoming_eol.

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 'Use for "give me the whole EOL schedule for X"' clause gives an explicit, natural-language trigger for when to call this tool. It does not explicitly name alternatives or exclusions, but the usage context is clear enough among the sibling 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. It adds behavioral context by describing the 0-100 score, the four-factor breakdown, and that omitting version scores the most recently end-of-lifed release.

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

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

Three concise, front-loaded sentences with no filler. The first sentence gives the core purpose and output, the second covers a key optional behavior, and the third states the intended use case.

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-only tool with an output schema present, the description is complete: it explains what the score represents, the output range, the factor breakdown, the version-omission behavior, and when to use the tool. No critical context for invoking it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents both parameters and the omit-for-highest-risk behavior. The description adds a little nuance ('most recently end-of-lifed') but mostly restates what the input schema already says, so the baseline 3 is appropriate.

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

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

The description states a specific verb ('Get'), a specific resource (the proprietary EOL Risk Score 0-100), and the composite four-factor breakdown. It is clearly distinct from siblings like check_eol or get_kev_exposure, which address individual components rather than a composite risk score.

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 an explicit use case: 'Use this to quantify how dangerous it is to keep running something.' It also clarifies the optional-version behavior. It does not explicitly name when-not-to-use it or point to alternative tools, so it stops short of a 5.

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

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

Annotations already mark it read-only and idempotent; the description goes further by disclosing default look-ahead (90 days), sorting by date, the every-version scope, and the recent_past_days behavior for versions already EOL. This is rich behavioral context that helps an agent predict results.

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

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

Three sentences with no filler: plain-language summary, precise behavioral details, and a concrete use case. The most important scope/behavior is front-loaded.

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 a complete input schema, an output schema, and annotations covering safety, the description adds the missing context: when to use it, scope, defaults, sorting, and the optional past-EOL window. Nothing needed to call it correctly is absent.

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 parameter (days, products, recent_past_days) is already documented. The description restates defaults and options but adds no meaning beyond the schema, keeping this at the baseline.

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 resource (tracked versions) and action (returns those whose EOL date falls within a window), and clarifies scope with 'every tracked version' and optional product filtering. The phrase 'what in our stack expires this quarter?' makes the aggregate calendar use distinct from singular sibling tools like check_eol.

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 an explicit use case ('Use for ... what in our stack expires this quarter?') that tells an agent when this tool is appropriate. It does not name sibling tools or state when not to use it, so it stops short of full exclusion 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful behavioral context by detailing what the tool returns, including the note about vendor successors being published only for edge appliances. 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?

Two sentences with zero waste. The opening clause states the purpose immediately, the list of outputs is dense but organized, and the usage guidance is a single conditional sentence. Every sentence earns its place.

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

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

For a tool with only two simple parameters, a rich output schema, and safety annotations, the description is largely complete. It tells the agent when to use it and what it returns. Minor gap: it does not state what happens when the optional version parameter is omitted, but the output schema and schema description mitigate this.

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 both product and version are already well defined in the schema. The description references 'current version' and implies using the version parameter but adds no additional parameter-level detail beyond that. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Where to move a product version' and enumerates the concrete outputs (support status, score, recommended target, vendor successor). It clearly distinguishes itself from siblings like check_eol and get_upcoming_eol by focusing on the upgrade destination rather than the EOL check itself.

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

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

Gives an explicit trigger condition: 'Use after check_eol says a version is EOL.' This provides a clear context for when to invoke the tool. However, it does not explicitly mention when not to use it or name alternative tools for other situations, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds dataset scale (700+ products) and the fact that results are slugs, but nothing about matching behavior beyond the schema's case-insensitive substring note.

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, front-loaded with what the tool does, then the usage directive, then the return type. No filler and no redundancy with 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 one-parameter lookup tool with an output schema, full annotation coverage, and 100% schema description coverage, the description supplies everything an agent needs: scale, lookup role in the workflow, and the canonicalization example.

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 baseline is 3, but the description adds real semantic value by showing the mapping example "postgres" → "postgresql", which clarifies that the query is a loose substring and the output is a canonicalized slug rather than a literal match.

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 (list/search products) with scope (the 700+ products endoflife.ai tracks) and the underlying intent (resolving a canonical slug). It is clearly distinguishable from siblings like get_product_lifecycle or check_eol, which consume the slug this tool produces.

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 to call this before the other tools to obtain the canonical slug, which is strong sequencing guidance. It stops short of naming a specific alternative or stating when not to use it, but the workflow context is unambiguous.

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 the description adds genuinely new behavior: per-plan item quotas (5/25/50) and the overflow behavior where excess items are returned as not checked with a note. That quota and truncation disclosure is exactly the context an agent needs before batching.

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

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

Four sentences, no filler: capability first, exclusions next, limits last. Each sentence carries a distinct decision-relevant fact.

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 an output schema present there is no need to explain return values, yet the description still names the EOL Risk Score. Quotas, the sibling alternative, and overflow semantics are all covered, leaving no gap an agent would need to guess at.

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

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

Schema coverage is 100% and the nested item/version fields are already documented. The description still adds meaning by framing items as stack components parsed from package.json or Dockerfile and restating that versions are optional, which slightly exceeds the baseline for a fully covered single parameter.

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

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

States a specific verb+resource+scope: audit a whole stack at once, returning an EOL Risk Score per item. It explicitly distinguishes itself from the sibling check_sbom for CycloneDX/SPDX documents, so an agent can route without opening either schema.

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

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

Gives a clear trigger (a list of products parsed from package.json/Dockerfile) and names the alternative for structured SBOM documents. It stops short of clarifying the single-item case versus check_eol, leaving that boundary to inference.

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