endoflife-mcp

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

Discloses return fields (lifecycle status, EOL date, days remaining, latest release) accurately. No annotations exist, but description conveys safe read-only behavior adequately.

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 purpose and return data, zero fluff. Efficiently earns its space.

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 tool with no output schema or annotations, the description fully covers functionality, return values, and usage scenario.

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 schema already documents both parameters. Description adds concrete examples (e.g., 'postgresql', '20.04'), providing helpful context 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?

Description clearly states the tool checks if a specific version of a product is EOL, lists returned data (lifecycle status, dates, days remaining), and differentiates from siblings like get_product_lifecycle by focusing solely on EOL status.

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 advises use for 'is X version Y still supported?' questions, providing clear context. Lacks explicit when-not-to-use, but the scenario is well-defined among 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?

No annotations provided; description must cover behavioral traits. It details the output (version history) but does not explicitly state read-only nature, required permissions, or side effects. Implied safe but not explicit.

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. First defines functionality, second gives usage. No redundancy or waste.

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?

Simple tool with one parameter. Description covers output and use case. Lacks error handling or prerequisites, but sufficient for typical use given sibling 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?

Schema coverage is 100% (only parameter 'product'). The description adds nothing beyond the schema's own description (both say 'Product slug or name, e.g. postgresql'). Baseline 3.

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 'Get the full version history for one product' with specific elements (release date, EOL date, support status, Risk Score). It distinguishes from siblings like check_eol (single check) and list_products (list).

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?

Provides a concrete usage example: 'Use for "give me the whole EOL schedule for X."'. Lacks explicit when-not-to-use or alternatives, but the example implies the 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?

No annotations present, so description must disclose all behaviors. It describes the output (score and breakdown) but does not mention auth requirements, rate limits, or side effects. Since it's a read operation, the lack of destructive hint is acceptable but could be more explicit.

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: first defines purpose and return value, second gives usage guidance. No redundant words, all information is relevant.

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 no output schema, the description adequately explains the return value (0–100 score with four-factor breakdown). The tool has only 2 parameters with 1 required, and the description covers both. No missing information.

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% with descriptions for both parameters. The description adds value by explaining the effect of omitting version (highest-risk release) and providing examples for product names, which enriches 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 gets a proprietary risk score with a specific range and four-factor breakdown, using a specific verb and resource. It also hints at distinguishing from siblings by mentioning the proprietary nature and factors.

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 'Use this to quantify how dangerous it is to keep running something' and explains when to omit the version parameter for highest-risk release. Does not provide explicit alternatives or when-not-to-use, but context from sibling tools is 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?

No annotations are provided, so the description carries the burden. It states the tool lists or searches and returns matching slugs. While not detailing pagination or limits, it is sufficient for a simple listing 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?

Two sentences, front-loaded with main purpose, followed by usage instructions and example. No extraneous 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?

Given the tool's simplicity (one optional parameter, no output schema), the description covers all needed context: purpose, usage, and return value (slugs). Works well with sibling tools.

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 description adds meaning beyond the schema by explaining the query parameter's purpose: to find the canonical slug for use with other tools. The schema already covers the parameter, and the example enhances understanding.

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 lists or searches over 459 products. It distinguishes itself from siblings like check_eol or get_product_lifecycle by focusing on product identification and slug retrieval.

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 explicitly advises using this tool before other tools to find the canonical slug, with a concrete example ('postgres' → 'postgresql'). This provides clear when-to-use 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?

No annotations provided, so the description carries full burden. It discloses behavior: scanning a list of products with optional versions, returning an EOL Risk Score, and notes tier limits. It does not mention destructive actions or error conditions, but for a read-only scan tool this is adequate.

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 purpose and resource. Each sentence adds value: first sentence states main functionality, second provides usage examples and tier limits. No wasted words.

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 low complexity (one required parameter, simple array input, no output schema), the description is fully adequate. It explains input format, expected output (EOL Risk Score), and constraints (tier limits). No missing information.

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 description adds meaningful context beyond the schema: explains that versions are optional, examples of sources (package.json, Dockerfile, SBOM), and behavior when version is omitted (highest-risk release). This helps an agent understand how to use the parameters effectively.

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 purpose: 'Audit a whole stack at once' and get an 'EOL Risk Score' for each product. It uses specific verbs and resources (audit, whole stack, products with versions) and distinguishes from siblings like 'check_eol' by emphasizing batch processing.

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 context on when to use this tool (e.g., parsing from package.json, Dockerfile, SBOM) and mentions tier limits (Free up to 5, Pro up to 50). It does not explicitly state when not to use it or name alternative tools, 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.