Utility Matrix

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

No annotations provided; description only describes the calculation and outputs. It does not disclose side effects or safety profile, but for a calculator tool this is acceptable but minimal.

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 for usage, second for inputs and outputs. No wasted words, front-loaded with when-to-use.

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?

Covers purpose, usage, and key inputs/outputs. Lacks example or return format, but for a simple calculator without output schema, it is sufficiently 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 description coverage is 0%, but the description explains all four parameters in natural language (weekly alert volume, actionable %, engineer count, avg resolution time), adding meaning despite no schema details.

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 explicitly states the tool calculates alert fatigue metrics for specific queries about alert noise and on-call burden. It clearly distinguishes from sibling calculators by focusing on alert fatigue.

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?

Description provides clear when-to-use guidance ('Use when a user asks about alert noise...'). It does not mention when not to use or alternatives, but the context is well-defined.

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 discloses it takes counts and returns score/rating, but does not mention input validation or edge cases (e.g., satisfied+tolerating > total). Basic transparency is present but could be better.

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 usage context. No redundant information; every word adds value.

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

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

No output schema, so description mentions return (Apdex score 0–1 and rating) but lacks specifics like format or possible ratings. For a simple calculator, it is adequate but incomplete.

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

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

Schema coverage is 0%, so description adds essential meaning: 'satisfied, tolerating, and total request counts'. This clarifies the purpose of each numeric parameter beyond their names.

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 that the tool calculates an Apdex score from three input counts and returns a score and rating. It specifies the verb 'use' and resource 'Apdex score', distinguishing it from sibling calculator tools.

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

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

Explicitly states when to use: 'when a user asks about their Apdex score or wants to measure user satisfaction with response times'. No when-not-to or alternatives provided, but context is specific 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?

No annotations are provided, so the description carries full burden. It explains that the tool outputs downtime budgets across multiple time periods (annual, monthly, weekly, daily), which is sufficient behavioral context for a calculator 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 consists of two focused sentences with no wasted words, efficiently conveying purpose and output.

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 calculator with one parameter and no output schema, the description provides sufficient context: it specifies the input and the output format (downtime budgets in multiple periods). The clarity is high despite minor implicit assumptions about units.

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 the parameter already described well. The tool description does not add additional semantics beyond what is in the input schema, so baseline score of 3 applies.

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

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

The description clearly states it converts availability percentages to downtime budgets in various time periods, using a specific verb and resource. It distinguishes itself from sibling tools which are different calculators.

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 says 'Use this when a user asks what a specific availability percentage means in downtime minutes per month or year,' providing clear context for when to invoke this tool.

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 full burden. It states what the tool detects but does not disclose whether it makes network requests, requires permissions, or has side effects. The behavior is partly transparent but lacks depth.

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

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

The description is a single sentence of 14 words, front-loaded with the action verb. No redundant information; every word adds value.

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 or annotations, the description covers the tool's purpose and detection capabilities but omits the return format or what happens after audit. Adequate but could be improved with output details.

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 each parameter described. The description adds context about the audit result types but no additional semantics for the parameters themselves. Baseline of 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 clearly states the tool audits a page URL against its canonical tag and lists specific issues it detects (missing canonical, self-referencing, relative URL issues). The verb 'Audit' and resource are explicit, and it easily distinguishes from siblings which are calculators/checkers for other domains.

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?

No explicit when-to-use or when-not-to-use guidance is given. Usage is implied by the tool name and description: if you need to check canonical URL issues, use this tool. Siblings are very different, so confusion is unlikely, but no alternatives are mentioned.

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 fully explains the output behavior: it returns a risk level based on the days remaining threshold. It is transparent about the logic (30, 7, 0 days). No contradictions.

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 fluff. Front-loaded with verb and resource, followed by output details. Every sentence adds value.

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 values. Input parameters are fully described in schema. Missing error handling or domain validation info, but for a simple calculator this is sufficient.

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 already provides descriptions for both parameters (100% coverage). The description adds minimal extra meaning beyond restating the parameter roles. The baseline 3 is appropriate as the schema does the heavy lifting.

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 assesses certificate expiry risk for a domain with days remaining, and specifies the return risk levels (OK, WARNING, CRITICAL, EXPIRED). This distinct purpose separates it from sibling tools like vulnerability checkers or cost calculators.

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 no guidance on when to use this tool versus alternatives. It does not mention exclusion criteria or when not to use it. Given the many sibling calculators, explicit usage context is missing.

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 carries the burden. It accurately describes that the tool accepts two inputs and returns a percentage and tier. It implies a non-destructive calculation, which is appropriate for a calculator. No contradictions.

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 usage trigger. Every word adds value, with no redundant information. It efficiently conveys purpose, inputs, and outputs.

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 calculator, the description covers inputs and outputs adequately. It mentions the DORA tier, which aligns with the tool's domain. However, it lacks output format details (e.g., percentage precision) but is sufficient given no output schema.

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 explains the parameters in natural language ('total and failed deployments'), adding meaning beyond the schema's numeric types and constraints. The parameter names are self-explanatory, and the description ties them to the output, compensating for the 0% schema description coverage.

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

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

The description clearly states the tool calculates change failure rate and DORA tier from deployment counts. The name and sentence directly convey the purpose, but it does not explicitly differentiate from the sibling 'dora-metrics-calculator' which might compute all DORA metrics.

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 says 'Use when a user asks about change failure rate or DORA CFR,' providing a clear trigger. However, it does not mention when not to use it (e.g., if the user asks for multiple DORA metrics, the broader tool might be preferred), nor does it offer alternatives.

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

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

No annotations are provided, so the description carries the full burden. It states the tool returns a 'waste estimate and tier' but doesn't specify the output format, units, or range. It also omits behavioral traits like being read-only or needing authentication. For a calculator, this is adequate but not thorough.

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-loading the usage condition, then stating inputs and outputs. Every part adds value, with no redundant or vague language.

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 4 parameters and no output schema, so the description must provide context. It gives a high-level purpose and parameter intent but lacks specifics on the output 'tier' meaning, the formula for waste estimation, or whether unattached_volumes_count is optional. It is minimally 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 description coverage is 0%, so the description compensates by mapping parameters to concepts: 'idle/oversized percentages' correspond to idle_pct and oversized_pct, and 'unattached storage' maps to unattached_volumes_count. It explains the meaning of each input in the tool's context, though it does not detail allowed ranges 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's purpose: estimating cloud waste from monthly bill and idle/oversized percentages. It explicitly ties to specific user intents ('cloud waste, idle resources, unattached storage') and distinguishes from sibling calculators by focusing on waste estimation rather than cost optimization or rightsizing.

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 begins with 'Use when a user asks about cloud waste...', providing an explicit usage condition. While it does not list when not to use or alternative tools, the context from sibling tool names suggests differentiation (e.g., ec2-cost-calculator is more specific). The guidance is clear enough for most scenarios.

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 full burden. It states the tool returns 'cluster utilization and headroom' and implies a read-only calculation, but does not explicitly confirm it has no side effects, requires no authentication, or any other behavioral details. It is adequate 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?

The description is very concise: three sentences with no wasted words. The first sentence immediately states usage context, the second lists inputs, the third states output. It is front-loaded and efficient.

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 has 6 parameters (3 required), no output schema, and is a calculator, the description provides enough to understand when to use and what inputs are needed. However, the return value description ('cluster utilization and headroom') is vague, missing units or format, which could be improved for completeness.

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 has 0% description coverage, but the description briefly explains the purpose of nodes, node_cpu, node_memory_gb, pods, and resource requests. However, it does not specify the units for pod_cpu_m (millicores) or pod_memory_mb (MB), nor does it explain the optional pod parameters thoroughly. The description adds some value but leaves gaps.

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 specific purpose: calculating Kubernetes cluster capacity and headroom when a user asks about capacity or pod scheduling. It distinguishes this tool from sibling calculators by naming the specific resource (Kubernetes cluster) and action (capacity calculation).

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 tells when to use the tool through the phrase 'Use this when a user asks...', providing clear context. It does not mention when not to use it or suggest alternatives, but given the sibling tools are all calculators, the usage scope is well-defined.

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 description carries full burden. Clearly states inputs and outputs (recommended pool size per instance with utilization ratio). As a calculator tool, it likely has no side effects, but does not explicitly confirm it's computational and read-only.

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-load the use case and then specify inputs/outputs. No redundant or filler words; every sentence adds value.

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 3-parameter calculator with no output schema, the description is largely complete: it describes inputs, outputs (pool size and utilization ratio), and the scenario. Could be improved by noting parameter types (e.g., positive numbers) or example values.

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 0%, so description must add meaning. It lists parameters (CPU cores, app instances, max_connections) but lacks units, constraints (e.g., must be positive integers), or examples. Provides basic semantic value but not enough for complete disambiguation.

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's purpose: calculating database connection pool size and troubleshooting connection exhaustion. It differentiates from sibling calculator tools by specifying the exact use case and inputs.

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 instructs when to use (questions about connection pool configuration or PostgreSQL connection exhaustion). Does not state when not to use or provide alternatives, but the context among sibling calculators makes the usage clear.

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 present, so the description must disclose behavioral traits. It does not mention that the tool is read-only (likely safe), what it returns, or any requirements (e.g., valid inputs). The description focuses only on use cases, not behavior.

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

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

The description is a single, concise sentence that immediately states the use case. It avoids unnecessary words, but it could be slightly expanded to improve completeness without sacrificing conciseness.

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

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

With no annotations, no output schema, and 0% parameter description coverage, the description does not adequately complete the picture. It fails to explain what the tool returns (e.g., a frequency number, a DORA rating) or how to interpret results, leaving an agent with insufficient 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 description coverage is 0%, yet the description adds no explanations for parameters like team_size, working_days, or deploys_per_month. The parameters are self-explanatory to some extent, but units or typical values (e.g., working_days per month) are not clarified, which would help an agent.

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 when to use the tool ('when a user asks about deployment frequency or DORA deploy cadence'), which identifies its purpose. However, it could be more specific about what metric is calculated (e.g., deploys per day/week) and how it differs from sibling tools like dora-metrics-calculator.

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 context ('Use when a user asks...'), but lacks guidance on when not to use it or alternatives among the many sibling calculators. No exclusions or comparisons are provided.

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 full burden of behavioral disclosure. It states the tool returns findings but does not explicitly state that it is a read-only operation or disclose any side effects. For a scanning tool, this is adequate but not exhaustive; missing safety profile disclosures.

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 core purpose, the second describes the output. It is extremely concise, front-loaded, and contains no redundant or unnecessary information. Every word 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides sufficient context: what it scans, what it finds, and what the output includes. It could mention limitations or supported secret types, but overall it is complete enough for an agent to understand the tool's capability.

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% for the single parameter 'text', and the description reinforces its purpose by mentioning file types. The description adds value by describing the return format (redacted matches, severity classification), which goes beyond the schema's description. This provides meaningful context for the agent.

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 verb 'Scan' and specifies the resource 'text (config, code, env files)' for leaked secrets. It distinguishes from sibling tools like dockerfile-linter or kubernetes-manifest-linter which have different purposes. The output is also described (findings with redacted matches and severity), making the tool's role 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 does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of when not to use it or comparison to other security-related tools among siblings. Usage is implied but not actively guided.

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 exist, so the description carries the full burden. It states the tool returns issues with suggestions, implying a read-only operation. However, it does not explicitly state that the Dockerfile is not modified, nor does it disclose any dependencies or limitations. The behavioral disclosure is adequate but not thorough.

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 concise sentences: the first states the action and lists specific issues, the second states the output. It is front-loaded with actionable information and contains no unnecessary 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 one parameter and no output schema, the description covers the input and output adequately. However, it lacks details on the format of 'issues' and 'suggestions', and it only lists three specific issues without stating if there are others. For a simple linter, it is mostly complete but could be improved.

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% for the single parameter 'dockerfile', and its schema description is 'Dockerfile content (full or partial)'. The tool description adds context that the content is linted for common issues, but this is inherent to the tool's purpose. Since schema coverage is high, baseline is 3; the description adds marginal value 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 lints a Dockerfile for specific common issues (e.g., :latest tag, interactive installs, running as root). It uses a specific verb ('Lint') and resource ('Dockerfile'), and the listed issues help distinguish it from sibling tools like kubernetes-manifest-linter. However, it could be more precise about the full scope of linting.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It implies it handles common issues but does not mention when not to use it (e.g., for syntax validation or advanced checks). Sibling tools are mostly calculators or other linters, but no comparative context is provided.

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 present, so the description must fully disclose behavior. It states inputs and output (classification tiers) but lacks details on validation, assumptions (e.g., standard DORA thresholds), handling of missing optional parameters, or whether it is read-only. The description is insufficient for an agent to fully understand the tool's behavior.

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

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

The description is two sentences, front-loading the usage context. It is concise with no wasted words. Could add more detail without becoming overly verbose, but it remains efficient.

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 has 4 parameters (3 required), no output schema, and no annotations, the description is incomplete. It does not specify the output format, thresholds for tiers, or behavior when restore_time_hours is omitted. For a classification tool, more detail is needed for an agent to correctly handle results.

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 should compensate. It mentions the four metrics (deploy frequency, lead time, etc.) but does not explain units, acceptable ranges, or formats (e.g., deploys_per_month as a number). This leaves ambiguity for the agent on how to provide valid inputs.

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

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

The description clearly states the tool benchmarks engineering teams against DORA metrics and returns tier classifications. It specifies the resources (deploy frequency, lead time, etc.) and the action (classify). However, it does not explicitly differentiate from sibling tools like deployment-frequency-calculator or change-failure-rate-calculator.

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 starts with 'Use this when...' providing clear usage context for benchmarking or classifying DORA metrics. It does not mention when not to use it or suggest alternatives, which could be valuable given many sibling calculators for individual metrics.

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 carries full burden for behavioral disclosure. It states the output (monthly cost and savings) but does not explain input handling (e.g., default for optional hours_per_month, os parameter usage). There is a minor discrepancy: description implies both instance type and hours are given, but hours is optional in schema.

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, highly concise with no wasted words. It is front-loaded with the usage condition and summarizes inputs and outputs effectively.

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

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

No output schema exists, so the description should explain return structure. It mentions 'monthly cost and DO-equivalent savings estimate' but lacks details like units (e.g., currency) or format. For a simple calculator, this is adequate but not comprehensive.

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 add meaning. It clarifies instance_type and hours_per_month ('instance type and hours') but does not mention the optional os parameter. This partial coverage earns a 3, as it adds some value 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's purpose: 'Use when a user asks about EC2 cost' with specific verb and resource. It distinguishes from sibling calculators by mentioning 'DO-equivalent savings estimate', making it unique among many cost calculators.

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 context ('Use when a user asks about EC2 cost'), but lacks explicit when-not-to-use or alternative tool guidance. However, given the sibling tools are all distinct calculators, the usage context is sufficiently clear.

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 alone must convey behavior. It states the tool takes volume in GB, returns estimated cost using AWS tiered pricing. This adequately discloses core behavior. Could mention pricing source or currency, but not a major omission.

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

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

The description is very concise at two sentences, no wasted words. Key information is front-loaded: use case first, then input/output details.

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

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

No output schema, but description indicates return is estimated cost. Parameter is simple. However, it doesn't specify currency or pricing tier details. For a calculator, this is reasonably complete; slightly more detail would improve completeness.

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

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

With 0% schema description coverage, the description must explain the parameter. It states 'Takes monthly transfer volume in GB,' clarifying units and context. Missing constraints like allowed range, but sufficient given a single numeric 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?

The description clearly states the tool's purpose: estimating AWS data transfer/egress costs. It specifies input (monthly transfer volume in GB), output (estimated monthly egress cost), and context (AWS). This differentiates it from sibling calculators focused on other metrics.

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 indicates when to use the tool ('when a user asks how much AWS data transfer or egress costs'). It lacks explicit exclusions or alternatives, but the sibling list implies other calculators for different areas. Good enough for clear usage 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. The description implies a non-destructive calculation but does not explicitly state read-only behavior or any side effects. For a calculator, this is acceptable but could be more transparent.

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 usage context, no redundant information. Every sentence adds value.

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 4 parameters, no output schema, and no annotations, the description covers the primary use case and outputs. It does not detail all parameters or the formula, but for a calculator tool it is reasonably 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 description coverage is 0%, so the description must compensate. It mentions SLO percentage and window, hinting at 'slo_pct' and 'window_days', but does not explain 'consumed_minutes' and 'window_elapsed_days'. The description adds some value but leaves gaps.

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 specifies the exact use case (SLO error budget, remaining budget, burn rate) and the return values (budget minutes, burn rate multiplier, status). It clearly distinguishes the tool from general calculators, though sibling 'slo-burn-rate-calculator' may overlap.

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?

Clearly states when to use: 'when a user asks about their SLO error budget, remaining error budget, or burn rate.' Does not explicitly mention when not to use alternatives, but the context is well-defined.

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 must carry the full burden. It states what inputs are taken and what outputs are returned, implying a read-only calculation. However, it does not disclose whether the tool modifies any state, has side effects, or requires specific permissions. Given the lack of annotations, this is adequate but leaves room for improvement.

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 long, front-loading the purpose and listing inputs and outputs succinctly. Every sentence adds value—no redundant or filler content. It could be slightly more structured (e.g., bullet points) but is efficient overall.

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, no output schema, and no annotations. The description explains the return values but only partially covers the parameters. It is adequate for a simple calculator but lacks full detail on all inputs. Given the complexity (5 params), more explanation is needed to ensure correct invocation.

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 explain all parameters. It mentions three parameters (hourly_revenue, downtime_hours, affected_pct) but omits two: 'eng_hourly' and 'responders'. These are not described, leaving ambiguity. The description partially compensates but is insufficient for complete 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 explicitly states the tool's purpose: 'calculate the financial impact of downtime'. It clearly distinguishes from sibling tools like 'cloud-waste-calculator' or 'error-budget-calculator' by specifying incident cost calculation. The verb 'use this when' directly links the action to user intent.

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 says 'Use this when a user asks what an outage or incident cost', providing clear context for use. However, it does not explicitly state when NOT to use this tool or mention alternative tools, such as other cost calculators. Still, the guidance is direct and helpful.

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 the full transparency burden. It mentions checking 'common packages' but does not specify behavior for rare packages or error conditions (e.g., package not found). Returns are partially described, but limitations and side effects are omitted.

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 main action, and contains no unnecessary words. Every sentence contributes to understanding.

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 mentions return values (vulnerability status, CVE ID, severity). However, it could be more complete by describing return format or error handling. For a simple check tool, it is nearly 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 100%, so the description adds minimal value beyond the schema. It provides helpful examples of package names, which aids understanding, but does not add new semantic information about 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 checks a package name against a known CVE database, returning vulnerability status, CVE ID, and severity. It specifies the verb 'check' and resource 'package name against known CVEs', and lists example packages, distinguishing it well from siblings like calculators or linters.

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

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

Usage is implied: check a package for known vulnerabilities. No explicit exclusions or when-not-to-use instructions are given. However, given sibling tools are unrelated, confusion is minimal, but the lack of guidance prevents a higher score.

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, but the description discloses the checks performed and the output (issue list and severity). It does not indicate destructive behavior, and as a linter it is read-only.

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

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

The description is a single 26-word sentence with the verb upfront, containing no filler 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?

For a simple one-parameter tool, the description adequately covers input and output, though the output format ('issue list and severity') could be more specific.

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 coverage is 100% with a single parameter described as 'Kubernetes manifest YAML content'. The description adds context by listing specific checks and output, adding value 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 'Lint a Kubernetes manifest (YAML) for common issues' and lists specific checks, differentiating it from sibling tools like dockerfile-linter.

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?

While no explicit when-not or alternatives are given, the description implies usage for Kubernetes manifest linting and the sibling list provides context; a clear use case is established.

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 must disclose behavioral traits. It only describes input format, omitting output, error handling, or whether the tool is read-only. For a calculator, no destructive actions are implied, but the absence of output details leaves ambiguity.

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, each essential: first states usage context, second describes input format. No filler or repetition. Front-loaded with the primary 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?

Missing output description. The tool likely returns a calculated MTTR value, but this is not stated. No mention of return format, units (hours/minutes), or handling of multiple incidents. For a simple one-param calculator, output should be clarified.

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 0%, so the description fully compensates by describing the expected format: 'string lines... or array of {start,detected,resolved}'. However, it does not specify timestamp format (e.g., ISO 8601) or whether the object keys are strings or dates.

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 is for MTTR or DORA recovery time, specifying the verb implicitly via 'Use when'. It distinguishes from sibling calculators like 'dora-metrics-calculator' or 'deployment-frequency-calculator' by naming the exact metric, but could be more explicit with a verb like 'calculates'.

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 states 'Use when a user asks about MTTR or DORA recovery time', providing a clear condition. No alternatives or when-not-to-use are given, but the sibling list implies context. Lacks exclusion criteria for similar 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 bears full responsibility for disclosing behavior. It does not mention that the tool is a calculator, what it returns, or whether it has side effects. This is insufficient transparency.

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 concise (one sentence) but under-specified for a tool with 4 required parameters. It front-loads the use case but lacks supporting details, making it more under-specification than efficient conciseness.

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 absence of an output schema, annotations, and parameter descriptions, this description is grossly incomplete. It does not explain how the inputs produce output or relate to on-call burden, leaving the agent with no actionable context.

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

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

The schema has 0% description coverage, and the tool description does not mention any parameters. It fails to add meaning to the numeric inputs (engineer_count, shifts_per_month, etc.), leaving the agent to infer semantics solely from parameter names.

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 mentions 'on-call load or burnout risk' which gives a general purpose, but it is vague as it does not specify what the tool calculates (e.g., cost, score, or metric). It is not a tautology but lacks precision.

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 advises use when a user asks about on-call load or burnout risk, providing a clear trigger. However, it does not offer guidance on when not to use it or alternatives among sibling calculators.

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 full burden. It discloses inputs and output, and implies a read-only calculation with no side effects. It could mention that the tool is non-destructive, but the calculator nature is obvious.

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: first sentence states when to use, second explains inputs and output. It is front-loaded, concise, and contains 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?

Given the tool's simplicity as a calculator with 4 parameters and no output schema, the description covers the essential information: purpose, inputs, and output. It could address edge cases or error conditions, but is reasonably complete for its 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?

Schema description coverage is 0%, so the description must compensate. It lists the parameters (average job duration, jobs per run, monthly run count, runner type) and their mapping to the schema, adding some meaning. However, it does not specify units or allowed values for runner type, which limits guidance.

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: calculating monthly costs for GitHub Actions CI/CD pipelines. It specifies the use case and distinguishes from sibling calculators which cover different domains like alert fatigue or cloud waste.

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 states when to use this tool ('when a user asks how much their GitHub Actions CI/CD pipeline costs per month or wants to compare runner costs'), providing clear context. It does not explicitly state when not to use or mention alternatives, but the sibling list makes the differentiation clear.

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 should disclose behavioral traits. It mentions 'returns interpretation' but does not explain side effects, edge cases (e.g., division by zero), or that it is a read-only operation. Minimal behavioral context beyond what is obvious.

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 long, efficiently covering usage, inputs, and outputs. No redundant content. Could use bullet points for clarity, but overall very concise.

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 calculator nature and no output schema, the description provides sufficient context: it states what inputs are taken and what outputs are returned (F1, F-beta, interpretation). However, it lacks details on the interpretation format and potential errors, leaving some gaps for an AI 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?

Schema description coverage is 0%, so the description must compensate. It only restates parameter names ('precision, recall, and optional beta weight') without explaining their meaning, units, or providing examples. This adds little value beyond the schema constraints.

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 calculates precision, recall, F1, and F-beta scores for ML models. It specifies inputs and outputs, and distinguishes itself from sibling calculators (e.g., apdex-score-calculator).

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 says 'Use this when a user asks about their ML model precision, recall, F1 score, or F-beta score', providing clear context for when to use. However, it does not mention when not to use or suggest alternatives.

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

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

With no annotations, the description carries the full burden. It states that the tool performs heuristic analysis (implying read-only, no side effects) and returns cost score and level. It does not mention any destructive potential or authorization needs, which is appropriate for an analysis 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 a single sentence that efficiently conveys the tool's purpose, inputs, and outputs. Every phrase adds value, with no wasted words. It is front-loaded with the main action.

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 tool with one parameter (well-described in schema) and no output schema, the description covers the essential: it returns cost score and level. It does not detail the output structure, but the tool's simplicity makes this acceptable.

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 has 100% description coverage (parameter described as 'SQL query to analyze'). The tool description adds context about what analysis will be performed (heuristics on SELECT *, JOIN count, etc.), enhancing the meaning beyond the schema alone.

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 estimates the relative cost of a SQL query using heuristic analysis, listing specific patterns like SELECT *, JOIN count, missing WHERE/LIMIT, etc. It distinguishes from sibling tools (all other calculators are for different domains, none are SQL-related).

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 (to estimate SQL query cost) but does not explicitly mention when not to use it or suggest alternatives. However, the sibling list does not contain any similar tool, so the guidance is sufficient.

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 full burden. It explains the computation and outputs, including risk levels and thresholds. It does not explicitly state that the tool is read-only or has no side effects, but the behavior is well-covered for a calculator.

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

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

The description is a single sentence that front-loads the purpose and efficiently covers inputs and outputs. No unnecessary words. It is well-structured for an AI agent to quickly grasp functionality.

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 lack of output schema, the description fully specifies all return values: utilization percentage, buffer, safety status, and risk level with thresholds. For a simple calculator with three parameters, this is complete and leaves no gaps.

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 clear parameter descriptions (limit, current_requests, window_seconds). The description adds context about the output and risk levels, enhancing understanding beyond the schema. The parameters are self-explanatory, but the description reinforces their purpose.

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 calculates API rate limit utilization using current request count and limit. It lists specific outputs: utilization percentage, buffer, safety status, and risk level with thresholds. This distinguishes it from sibling calculators like error-budget-calculator or slo-burn-rate-calculator.

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 the tool is used when needing rate limit utilization, but it does not explicitly state when to use it versus alternatives or when not to use it. It lacks guidance on prerequisites or comparisons with other calculators.

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 description discloses inputs (On-Demand and RI monthly costs plus upfront fee) and outputs (break-even month, net savings over 1yr and 3yr). As a calculator with no annotations, it adequately covers its behavior, though it could mention that it is a read-only calculation 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 three short sentences, front-loaded with usage guidance, followed by input and output. Every sentence adds value without redundancy. It is highly concise and well-structured.

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 explains inputs and outputs at a high level, but lacks details like units (e.g., dollars), or that upfront costs are optional. For a calculator tool, this is adequate but not fully complete, especially given no output schema.

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 maps some parameters to concepts ('On-Demand monthly costs', 'RI monthly costs', 'upfront fee'), but with 0% schema coverage, it should clarify which parameters correspond to which costs. It fails to specify that there are two upfront fees for 1yr and 3yr, and does not indicate that upfront parameters are optional.

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: to determine whether to buy Reserved Instances or stay on On-Demand, and to calculate break-even month. It uses specific verbs ('buy', 'stay', 'pays for itself') and resource ('Reserved Instances'), and distinguishes from sibling calculators by specifying the exact decision scenario.

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 says 'Use this when a user asks whether to buy Reserved Instances or stay on On-Demand', providing clear context for usage. It does not explicitly mention when not to use it or list alternative tools, but the condition is well-defined.

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 full burden. It does not disclose whether the tool is read-only, destructive, or requires authentication. It also does not describe what the tool returns or any side effects. The agent cannot infer behavior beyond the name.

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

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

The description is a single, well-formed sentence that conveys the essential purpose with no extraneous words. It is front-loaded and immediately useful.

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 6 parameters (4 required), no output schema, and no behavioral hints, the description is insufficient. An agent needs to know what the calculator outputs (e.g., recommended instance size, cost savings) and how the parameters interact. The current description only gives a high-level purpose, leaving critical gaps for correct invocation.

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%, meaning no parameter descriptions exist in the schema. The tool description adds no parameter-level guidance. Parameter names like 'current_vcpu' and 'p99_cpu_pct' are somewhat self-explanatory, but 'hourly_cost' and 'instance_count' are ambiguous without context. The agent must guess the role of optional 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 explicitly states the use case: 'Use when a user asks about instance rightsizing or overprovisioned compute.' This clearly identifies the verb (rightsize) and resource (instance compute), and distinguishes it from sibling calculators like 'cloud-waste-calculator' or 'ec2-cost-calculator'.

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 a clear 'when to use' directive. However, it does not specify when not to use it or mention alternative tools for similar queries. The context is sufficient for an agent to decide, but lacks 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?

No annotations are provided, so the description carries the full burden. It states the tool returns burn rate multiple and time-to-exhaustion signal, but does not disclose whether the operation is read-only, or any potential side effects. It is adequate but lacks explicit behavioral details beyond output.

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, front-loaded with usage scenario and output. Every word adds value, no redundancy.

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 calculator with 3 parameters and no output schema, the description provides the essential purpose and outputs. However, it lacks detailed parameter explanations and behavioral caveats, making it minimally adequate.

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%, and the description only mentions 'error count and total requests' in a generic sense, completely missing explanation of the 'slo' parameter. With three parameters required, the description fails to add meaning to the input 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 computes burn rate multiple and time-to-exhaustion, used when users ask about error budget burn rate. However, it does not explicitly differentiate from sibling tools like error-budget-calculator, which may have overlapping functionality.

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 states when to use: when a user asks how fast they are burning error budget or if current error rate will exhaust the SLO window. Does not specify when not to use or alternatives, but the guidance is clear for typical use cases.

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 full burden. It fails to disclose whether the tool is a read-only computation, if it requires any authentication, or what the output format is. The description is too minimal for a calculator with 8 parameters.

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

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

The description is a single sentence, which is concise, but it under-specifies the tool. For a tool with 8 parameters, a slightly longer description that covers key aspects would be more effective.

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 complexity (8 parameters, no output schema, no annotations), the description is incomplete. It does not explain the output or provide enough context for the agent to understand the tool's purpose beyond the basic use case.

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 has 0% description coverage, and the description does not mention any parameters or their significance. With 8 parameters, the agent gets no guidance on how to populate them, severely hindering correct invocation.

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 is for risk assessment of software purchases or SaaS commitments, distinguishing it from other calculators. However, it lacks a specific verb like 'calculate' or 'assess', making it slightly vague.

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 a clear usage context ('when a user asks about risk'), but it does not specify when not to use the tool or mention alternative tools. For a calculator with many siblings, more explicit guidance would improve this.

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 must cover behavioral traits. It only states the purpose, but does not disclose whether the tool is read-only, any side effects, or how the estimation is performed. This is insufficient for a computation 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 a single concise sentence, but it lacks structure and skips important details. It is not too long, but could be more informative while remaining brief.

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 has 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what the output looks like, any prerequisites, or how parameters affect the estimate. A much richer description is needed for effective use.

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%, and the description adds no information about parameters. It does not explain the meaning of 'resource_type', 'count', or 'instance_size', nor does it provide valid values or constraints. The agent has almost no guidance for filling in 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 estimates monthly cost of a Terraform plan, which is a specific verb-resource pairing. It distinguishes from sibling cost calculators (e.g., ec2-cost-calculator) by focusing on Terraform plans.

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 a clear condition to use the tool ('when a user asks to estimate monthly cost of a Terraform plan'). However, it offers no guidance on when not to use it or alternatives, such as other cost calculators for specific resources.

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, and the description does not disclose any behavioral traits such as whether the calculator returns annual cost, breaks down components, or requires specific inputs. The description is silent on what the tool does beyond the high-level purpose.

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

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

The description is very concise with one sentence of 12 words. It is front-loaded with the usage trigger. However, it could be slightly more informative without sacrificing conciseness.

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 has 8 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what inputs are used, what the output represents, or any assumptions. The agent lacks critical information to invoke the tool 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 coverage is 0% (no parameter descriptions in the schema). The description does not mention any parameters, leaving the agent with no guidance on the meaning or usage of the 8 parameters, including the two required ones.

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 purpose: calculating TCO or multi-year SaaS costs. The verb is implied ('calculate'), and the resource is clear. It distinguishes itself from sibling calculators by specifying 'TCO' and 'multi-year SaaS'.

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 a clear when-to-use condition: 'when a user asks about TCO or multi-year SaaS cost.' It does not explicitly state when not to use or suggest alternatives, but the context of sibling tools provides implicit differentiation.

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