get_defect_agingAnalyze open defects by age bucket and priority, and surface every defect past its SLA (Critical 2d, High 7d, Medium 30d, Low 90d), sorted worst first.
Open defects right now: age buckets, open count by priority, and every defect past its SLA (Critical 2d, High 7d, Medium 30d, Low 90d), worst first.
| Name | Required | Description | Default |
|---|---|---|---|
| priority | No | ||
| component | No | Limit to one service/component, e.g. 'checkout' |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value beyond that by disclosing the SLA policy thresholds, the "worst first" ordering, and that only open defects are included. It does not say whether the SLA-breach list is truncated or paginated, which matters given "every defect past its SLA" could be a large result.
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?
A single front-loaded sentence with zero filler: scope, three output components, SLA thresholds, and sort order are all packed into one clause chain. Every element earns its place and nothing is repeated from the schema or annotations.
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 output schema, the description carries the burden of describing returns and does so adequately by naming the three result sections and the ordering. The remaining gap is bucket definition (what the age buckets actually are) and result-size behavior, which an agent would want to know before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: component carries its own description and priority is a self-explanatory four-value enum, so the schema does most of the work. The description never mentions filtering at all, leaving the agent to infer from "open count by priority" that the priority parameter scopes results, which is a weak but non-zero contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and scope: currently open defects, broken into age buckets, counts by priority, and an SLA-breach list with the exact thresholds (Critical 2d, High 7d, Medium 30d, Low 90d). That is far more concrete than the sibling get_defect_metrics, but the description never explicitly contrasts itself with that sibling or get_mttr, so differentiation is left to inference.
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?
"Open defects right now" implies a point-in-time snapshot rather than a historical trend, which is a usable usage cue against trend-oriented siblings like get_kpi_trend. However, no alternative tool is named and no when-not-to-use condition is given, so the guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.