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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail beyond annotations: unmatched components are 'listed honestly rather than guessed,' and there are explicit free vs Pro tier limits (5 vs 50 matched components). These are non-obvious constraints that help the agent set expectations.

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

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

Three tight sentences, each earning its place: the first defines the tool's action and scope, the second describes how unmatched components are handled, and the third covers input format and quota limits. There is no filler, repetition, or unnecessary qualification.

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 annotations cover safety and an output schema exists, the description provides everything needed to invoke the tool correctly: accepted SBOM formats, input representation, matching/scoring behavior, and quota limits. There are no obvious gaps for a read-only, idempotent SBOM audit operation.

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 documents both parameters well (SBOM format and max_items default 50), so the baseline is 3. The description adds value by clarifying tier-dependent behavior: free tier caps at 5 matched components while Pro allows 50, which directly affects how max_items should be interpreted. This is exactly the kind of operational nuance the schema doesn't convey.

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 ('Audit') and a concrete resource ('CycloneDX or SPDX JSON software bill of materials'), then immediately states the core value (mapping components to tracked products and scoring EOL risk). This clearly distinguishes it from sibling tools like check_eol or get_product_lifecycle, which focus on individual products rather than a full SBOM document.

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 makes the intended use obvious: pass an SBOM document to get EOL risk scoring for its components, with unmatched ones explicitly reported. It also tells the user how to supply the SBOM (as a JSON string or object). However, it doesn't name sibling alternatives or explicitly state when not to use this tool, but the context is clear enough.

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 covered. The description adds useful behavioral detail beyond that: the query is an optional case-insensitive substring filter, and the tool returns matching product slugs. 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 deliver the purpose, the optional-query behavior, the return value, and an illustrative example with zero wasted words. The main function is front-loaded and the example is compact yet clear.

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 is complete for this simple 1-optional-parameter tool. It states what the tool does, how the query works, what it returns, and why to use it before other tools. The output schema covers return values, and annotations cover safety, so nothing crucial 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?

The input schema already describes the query parameter as an 'Optional case-insensitive substring filter,' so schema coverage is 100%. The description enriches this with a concrete example ('postgres' → 'postgresql') and explicitly ties the parameter to finding a canonical slug, adding 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 a specific verb and resource: 'List or search the products endoflife.ai tracks (500+).' It also explains the tool's role as the canonical-slug lookup for other tools ('before calling the other tools'), which distinguishes it from the sibling tools that perform EOL, SBOM, and risk checks.

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

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

The phrase 'before calling the other tools' explicitly tells when to use this tool, and the example 'postgres' → 'postgresql' illustrates the intended use case. It does not list exclusions or alternative tools, but the context is clear enough for an agent to know this is the prerequisite slug-resolution step.

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 valuable behavioral context beyond annotations: the free-tier/Pro item limits (5 vs 50) and the fact that results come back per item as an EOL Risk Score. This goes beyond what annotations alone provide.

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 wasted words. The main purpose is front-loaded, the input example is embedded naturally, the alternative tool is named, and the tier limits are compactly included. 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 one-parameter tool with a complete input schema, a provided output schema, and strong safety annotations, the description covers everything an agent needs: what to pass, what to expect, when to use an alternative, and operational limits. Nothing critical 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%, so the schema already documents the 'items' array, 'product', and optional 'version' fields. The description adds minor context ('optionally with versions', parsed from package.json/Dockerfile), but it does not carry the parameter-documentation burden. 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 names the exact operation ('Audit a whole stack at once'), the input (a list of products with optional versions), and the output (an EOL Risk Score for each). It clearly distinguishes itself from check_sbom by naming that sibling explicitly, so an agent knows what this tool is and is not.

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 states when to use this tool: when you have a list of stack components, e.g. parsed from a package.json or Dockerfile, and want scores in one call. It also gives an explicit exclusion and alternative: 'For CycloneDX or SPDX documents use check_sbom instead.' This is strong routing guidance.

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