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

With no annotations, the description carries the burden, and it does indicate that the tool performs an addition and returns a description rather than just a raw number. However, it says nothing about side effects, edge cases, or the exact nature of the 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?

Eight words and fully front-loaded. Every word contributes: the action, the operands, and the form of the result.

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 such a simple operation, the description plus the schema and output schema may be enough for basic invocation, but the lack of parameter semantics and any usage context keeps it from being fully 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% and the description only says 'two numbers,' which barely adds to the schema's numeric types and uninformative names a and b. The parameter meanings remain under-specified.

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

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

The description clearly states a specific verb ('Add') and resource ('two numbers'), so an agent knows exactly what operation to perform. A tiny bit of ambiguity remains in 'describe the result,' which is not further specified.

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 guidance is given about when to use this tool versus any alternative, and no conditions or exclusions are mentioned. The intended use is implied only by the tool name and the verb 'Add.'

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 carries the burden. It adds the useful behavioral trait 'deterministic', but it does not disclose whether the operation has side effects, requires permissions, or handles edge cases such as too few matching heroes.

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 that delivers the action, target, criterion, and determinism guarantee without any wasted words. Every element earns its place.

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

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

For a low-complexity tool with an output schema, the description covers the core purpose and main input well. The missing 'size' semantics and lack of alternative guidance keep it from being fully complete, though the schema's default and parameter name make the gap recoverable.

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 define both parameters. It explains 'threat' via 'described threat', but never mentions 'size', which is an optional but significant input. The agent must infer size means team size from the parameter name and default.

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

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

States a specific verb ('Pick'), a clear resource ('heroes'), and a precise selection criterion ('whose powers best fit a described threat'). The added 'deterministic' qualifier further distinguishes it from search-oriented siblings like find_heroes_by_power and list_heroes.

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 clearly implies when to use the tool: when there is a described threat and the agent needs to assemble a fitting hero team. It does not explicitly name alternatives or state when not to use it, but the threat-based framing gives enough context for correct selection.

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 of behavioral disclosure. It does state the aggregation sources and the verdict categories, but it does not clarify whether the operation is read-only, what time window is used, or how failures in the underlying data sources are handled.

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, tightly worded sentence that front-loads the core behavior and output. Every word adds value, and there is no redundant restatement of the title or schema.

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

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

The description covers the purpose and output verdict categories, and an output schema exists to document return values. However, the lone parameter is not explicitly documented, and there is no guidance on prerequisite service state or when this tool is the right choice, so completeness is only moderate.

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 never explains that the required 'name' parameter is the service name. The agent must infer this from the tool title and sibling tools, which is a meaningful gap for the only input 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 uses a specific verb ('roll up') and resource ('synthetic metrics, SLOs, and open incidents') to produce a clear health verdict. It differentiates itself from sibling tools like get_service and error_budget by emphasizing an aggregated healthy/degraded/down outcome rather than raw service data.

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 this tool is for getting a high-level health verdict, but it never states when to prefer it over alternatives like error_budget, get_service, or list_incidents. No when-not-to-use or alternative routing guidance 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 provided, so the description carries the full burden of behavioral disclosure. It clearly states the core behavior: the input message is returned to the caller. Echoing is inherently a non-destructive, read-only operation, so there are no hidden side effects or safety concerns to disclose.

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?

One short sentence that front-loads the verb and object with zero waste. Every word earns its place, and no redundant phrasing or repetition exists.

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 single-parameter echo tool with an output schema present, the description is complete. An agent can invoke it correctly with no additional information, and the return value is covered by the output schema rather than needing description-level detail.

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 refers to the 'input message,' which maps directly to the single required message parameter, but it adds no constraints, formatting rules, or examples beyond what the schema's title and type already convey.

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

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

The description uses a specific verb (Echo) and resource (the input message), clearly stating that the tool returns the same message back to the caller. It is unambiguous and inherently distinct from the sibling tools, none of which perform an echo operation.

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 explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. However, for a trivial echo operation, the intended usage is implied by the description itself: an agent needing to mirror a message would select 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?

With no annotations provided, the description must carry the behavioral burden. The verb 'compute' implies a read-only analytical operation rather than a mutation, but the description does not disclose details such as authentication needs, data freshness, edge cases, or failure 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 front-loads the action and core resource. Every word contributes meaning, with no padding or 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?

An output schema exists, so return-value details are less critical, and the tool is relatively simple with two parameters. Still, the description is thin on parameter semantics and usage context, so it is not fully complete for an agent choosing and invoking it correctly.

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

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

Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter explanations. The phrase 'for a service' weakly clarifies the required name parameter, but the optional window_days parameter is not described at all, leaving its meaning and effect on the calculation unclear.

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 action: compute the remaining SLO error budget and current burn rate for a service. It is clear about the resource (service) and the outputs, though it does not explicitly differentiate itself from related sibling tools like get_service or check_service_health.

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 when to use the tool: when a caller needs SLO error budget or burn rate numbers for a service. However, it provides no explicit guidance about when not to use it or how it compares to alternative service-related 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 carries the burden of behavioral disclosure. It clearly states substring matching rather than exact matching and that every matching hero is returned, which also implies a read-only operation. It does not cover case-sensitivity or edge cases, but these are minor for a simple query.

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?

One concise sentence conveys the verb, resource, matching behavior, and an example. There is no filler or redundant detail.

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 single-parameter lookup tool with an output schema, the description is largely complete: an agent knows what the tool does, what the parameter means, and what kind of result to expect. It could be improved by naming alternatives or clarifying matching case-sensitivity, but these are not blockng 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?

The input schema provides only a 'Power' field with no description (0% coverage). The description compensates by explaining that the parameter is a substring matched against hero power lists, with the example 'flight'. This adds meaningful semantics, though it does not specify case sensitivity.

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?

Uses a specific verb ('Return') with a clear resource ('hero') and a precise matching rule ('power list matches the given substring'). This distinguishes it from sibling tools like list_heroes or get_hero, even without naming them.

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

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

The description implies when to use the tool: when you need heroes by a power substring. However, it does not explicitly mention alternatives or state when not to use it, leaving routing to inference among siblings like list_heroes and get_hero.

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. 'Return content blocks' implies a read-only operation, but the description does not explain how message_type affects results, what include_image changes, or what happens when no annotations exist. This is a meaningful transparency gap for an unannotated 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 with no wasted words and starts with the operative verb 'Return'. It is concise, though it could have used its brevity to include parameter or usage context without becoming bloated.

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 is structurally simple (two scalar parameters, no output schema, no nested objects), so the required effort is modest. The schema supplies the required enum and default, and the description names the return content, but the lack of any usage guidance and the 0% parameter coverage leave an agent with only partial context for invoking it well.

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 needed to compensate, but it mentions neither message_type nor include_image. The parameter names and enum values are somewhat self-explanatory, but the description adds no nuance about filtering by message type or the image inclusion behavior.

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

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

The description names a concrete verb (return) and a specific resource (content blocks with priority and audience annotations), so the core purpose is clear. It does not explicitly position itself against sibling tools like get_resource_reference or get_resource_links, so it falls just short of full differentiation.

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

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

The description gives no guidance on when to use this tool instead of siblings, and it does not state any exclusions or alternative tool names. An agent must infer usage entirely from the name and schema.

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 discloses that the operation is a non-mutating lookup returning the full record, but it does not describe behavior for unknown codenames, case sensitivity, or error conditions. This is adequate but not rich.

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, front-loaded sentence with no filler. Every word contributes meaning, and the example is useful without bloating the text.

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 single-record getter with one parameter and an output schema, the description is mostly complete. It clearly tells the agent what input to provide and what to expect. A small gap is not noting how to discover valid codenames (e.g., via list_heroes), but this is not essential for calling 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%, but the description compensates by explaining that the only parameter, codename, is the hero's identifier, and provides a concrete example. This adds real meaning beyond the schema's bare 'Codename' title.

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

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

The description states a specific verb ('Return'), a specific resource ('full record for one hero'), and a clear identifier ('by codename'). It distinguishes itself from siblings like list_heroes (which would return multiple) and hero_bio (which implies a focused bio, not a full record).

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 clearly implies this tool is for fetching a single hero when the codename is known, giving an example ('spider-man'). It does not explicitly state when to use alternatives such as list_heroes or find_heroes_by_power, but the context is clear enough for an agent to select it appropriately.

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 disclosure burden. It communicates that the operation is read-only and describes the outputs (on-call person and escalation order) and the team-vs-service resolution. It does not mention error cases, permissions, or response details, though an output schema likely covers return shape.

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?

One concise, front-loaded sentence says what the tool returns and the key input distinction. No filler or redundant material.

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

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

For a one-parameter read-only tool, the description is largely complete: it explains the input disambiguation and the output components. The lack of explicit usage boundaries is a minor gap, but the output schema helps cover the return 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?

The single required parameter, team_or_service, has 0% schema description coverage, but the description compensates by stating it can be a team or a service whose owning team is resolved. This adds clear meaning beyond the property title, though concrete identifier formats or examples are not given.

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: finding who is on call for a team or for the team owning a service, and includes escalation order. This is specific, distinguishes it from sibling tools like get_service or check_service_health, and uses a clear resource and scope.

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 usage context is implied: use this when you need the current on-call person or escalation chain for a team or service. However, there are no explicit when-not-to-use statements, alternatives, or prerequisites.

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 adds behavior not present in structured data: the result is a bounded collection of 1 to 10 resource_link blocks pointing at dynamic resources. However, with no annotations, it carries the full burden, and it does not explain boundary handling for invalid count values, error behavior, or what 'dynamic resources' implies for result stability.

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 no filler. Every phrase earns its place: the action, resource type, and output bound are all stated.

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 is minimal but workable: an agent knows the output kind and rough count range. It is incomplete because there is no output schema, no definition of what a resource_link block contains, and no error or boundary behavior.

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 only provides a default for count with no property description, so the description must compensate. It partially does by tying the output to a 1-10 range and resource_link blocks, from which the role of the single count parameter can be inferred, but it never explicitly defines valid count values or behavior for extreme 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 action ('Return'), the resource type ('resource_link blocks'), and an output bound ('between 1 and 10'), so an agent can tell what the tool does. It does not, however, explicitly distinguish itself from sibling tools such as get_resource_reference.

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?

There is no guidance on when to use this tool instead of alternatives. The description offers no conditions, exclusions, or references to sibling tools, so an agent receives no help with tool selection.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. 'Return' implies a read operation, but the description does not explain what 'embedded resource content block' means, whether there are side effects, or what failure modes exist.

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 one concise sentence with no filler and starts with the action, making it easy to parse. It loses a point only because the phrasing 'for a dynamic resource' is vague and not defined.

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 undocumented parameters, this single-sentence description is not enough for an agent to call the tool confidently. The agent would still need to guess how kind and resource_id map to the returned resource block and what output format to expect.

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 never mentions kind or resource_id. The agent receives no explanation of how these parameters affect the returned content block, so it cannot infer meaningful values beyond the schema defaults and enum.

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

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

The description names a specific verb ('Return') and an object ('embedded resource content block for a dynamic resource'), so the agent has a basic idea of what the tool does. However, it does not explicitly contrast itself with get_resource_links or other resource-related siblings.

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 guidance is given about when to call this tool instead of alternatives. It neither states a recommended use case nor mentions any exclusions, and the sibling list is not leveraged to clarify selection.

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 the full burden. It conveys that the tool returns data and supports optional narrowing by symptom, which is useful. However, it does not disclose error behavior, whether the operation is strictly read-only, or what happens when no runbook entries match.

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, front-loaded sentence with no wasted words. It conveys both the core purpose and the optional narrowing behavior efficiently.

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 getter with an output schema present, the description covers the essential call context: what resource is retrieved and what optional filtering is available. It is slightly incomplete in that it does not mention behavioral edge cases or compare against related tools, but this is a minor gap for such a low-complexity tool.

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 does clarify that 'service' is the target of lookup and that 'symptom' narrows results. Yet it provides little additional detail about acceptable values, formatting, or the meaning of null beyond what the schema already implies.

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

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

The description clearly states a specific verb ('Return'), resource ('runbook entries'), and scope ('for a service') with an optional filter. It is unambiguous about what the tool does, though it does not explicitly distinguish itself from sibling tools such as get_service or get_resource_links.

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 intended use is implied: an agent would call this when it needs runbook entries for a service, optionally filtering by symptom. However, there is no explicit 'when to use' or 'when not to use' guidance, and no alternatives are mentioned despite a large sibling tool list.

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 carries the burden of behavioral disclosure. It transparently describes the core action and the data returned, which is adequate for a read-only getter. It does not cover error behavior for unknown service names or access requirements, but these are not critical for this simple operation.

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 that names the action, the target, and the returned fields. There is no filler, and every word contributes to understanding the tool's purpose.

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 low-complexity getter with an output schema, the description covers the essential return payload and the input's role. It omits explicit guidance against listing use cases, but the word 'one' and the catalogue focus make the selection context sufficiently clear.

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 only a 'name' string with no description (0% coverage). The description indirectly clarifies that 'name' identifies the service whose catalogue entry is returned, adding some meaning. It does not specify exact-name matching, case sensitivity, or format, so it only partially compensates for the schema gap.

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

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

The description states a specific verb ('Return'), a specific resource ('one service's catalogue entry'), and enumerates the concrete contents (tier, team, dependencies, SLOs, repo). This clearly distinguishes it from sibling tools like list_services and check_service_health.

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 usage: call this to fetch a single service's catalogue details. However, it does not explicitly explain when to prefer this over list_services or check_service_health, nor does it mention any alternatives or 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 behavioral disclosure burden. It clearly describes a read-only operation that returns a typed Weather object, which is sufficient for a simple getter. It could mention error behavior or live-data assumptions, but the core behavior is not hidden.

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 sentence with no wasted words: it states the return value and the client benefit, and the key idea is front-loaded. Nothing extraneous is present.

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 output schema covers the return shape, and the parameter schema covers location, so the main missing piece is when to use this structured tool versus alternatives like weather_report. The absence of annotations also leaves behavioral caveats unstated, though the tool is simple enough that this is a moderate gap rather than a severe one.

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 contributes nothing about the location parameter or how to choose between Zurich and Savognin. The enum and default in the schema help, but the low-coverage rule expects the description to compensate, and it does not.

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 action ('Return') and resource ('a typed Weather object'), and its emphasis on typed/schema-validateable output makes the structured nature clear. It does not name a sibling such as weather_report, so the differentiation is implied rather than explicit.

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

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

The phrase 'so the client can validate it against the output schema' gives a clear context for the structured return value, but the description never says when to prefer this over weather_report or when not to use it. Usage guidance is implied by the name and typing, not stated.

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 disclosing behavior. It reveals only that the return value is text interleaved with an image block; it doesn't mention side effects, data sources, errors, or how the content is generated. This is minimal 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 a single short sentence with no filler or redundancy, and it front-loads the expected return shape. However, it is so sparse that it leans toward under-specification rather than effective conciseness. It earns a middling-to-good score because brevity is achieved at some expense of meaning.

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 parameters, no output schema, and no annotations, the one-line description is the only source of semantics. It provides a rough idea of the return value (text plus an image content block) but leaves the actual content and purpose unexplained. For a no-argument tool this is minimally sufficient, though not rich.

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

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

The input schema declares zero parameters, and the description introduces no parameter-related ambiguity. With no parameters to document, the schema and description together are sufficient, so the baseline 4 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 uses 'Return' as the verb and describes the output shape ('text interleaved with an image content block'), so it is not a tautology. However, it never says what the 'tiny image' is or what the operation actually does, and it does not differentiate this tool from any sibling tools. It reads as a vague output-format statement rather than a clear, actionable purpose.

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 offers no information about when to choose get_tiny_image over the sibling tools (echo, add, weather_report, etc.). There are no conditions, no exclusions, and no alternatives mentioned. This is a complete absence of 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 are provided, so the description carries the full behavioral burden. It does disclose an important non-deterministic trait: the LLM is supplied by the client via MCP sampling, implying possible latency or failure if sampling is unsupported. It does not cover behavior when the codename is unknown or whether the operation has 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 one sentence, front-loaded with the main action, and contains no filler. The phrase 'pydantic-ai' repeats the title's parenthetical, which is a minor redundancy, but the description remains compact and readable.

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 is simple and an output schema exists, so return-value details are not required. However, the description lacks usage routing and failure/edge-case context, and with no annotations this leaves an agent with only a partial picture of when and how to call it safely.

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 and no explicit explanation of `codename`, the description only implies that the codename identifies the hero whose facts are used. For a single required string parameter this is partially sufficient, but the expected format or source of valid values is not stated.

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

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

The description uses a clear verb ('writes') and resource ('short in-universe bio') and identifies the source data ('hero's facts'), which separates it from sibling retrieve/list tools like get_hero or list_heroes. The pydantic-ai/sampling implementation detail slightly dilutes the purpose statement but does not obscure it.

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?

There is no guidance on when to prefer this tool over alternatives such as get_hero or find_heroes_by_power, and no exclusions or prerequisites are stated. The only implicit signal is that a bio is needed, which is not enough for confident tool selection.

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 carries the full disclosure burden, and it does real work: it reveals that generation is delegated to a pydantic-ai agent and that the LLM is supplied client-side via MCP sampling — a genuinely useful trait because the call may depend on client sampling capability and latency. It stops short of full transparency by not stating whether the draft is persisted back to the incident or how unknown incident IDs are handled, but for a zero-annotation tool this is substantive behavioral disclosure.

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 22-word sentence with the essential verb-object ('drafts a short blameless postmortem from an incident's facts') front-loaded and the mechanism clause second. No filler, and every clause adds information rather than restating the tool's name or title.

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

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

For a one-parameter tool with an output schema present, the description is close to sufficient: it explains the input's purpose and the output's nature. Remaining gaps — side effects and invalid-input behavior — are minor at this complexity, and the output schema covers return semantics, so nothing critical is missing.

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

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

Schema description coverage is 0%, so the property block offers only a type and title for incident_id; the description compensates only partially by mapping the parameter to 'an incident's facts'. It does not state the id's format, how it is obtained (e.g., via list_incidents), or what an invalid id produces — the added meaning is real but minimal.

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

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

The description states a specific verb ('drafts') and a specific resource: a short blameless postmortem produced from an incident's facts. This cleanly separates it from the operational incident-management siblings (list_incidents, open_incident, update_incident), which manage incident state rather than produce documents. The output's kind, length, and tone are all named up front, so an agent can predict the artifact without opening the schema.

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

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

The intended use is implied — call when you want a postmortem for a given incident_id — but there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. Given LLM-driven siblings like summarize and poet, the description does not tell an agent what distinguishes this from those, beyond the output being a postmortem rather than a summary.

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 must carry the burden. It clearly indicates a read-only listing operation and mentions optional filters, but it does not disclose details like the recency window, result ordering, pagination, or whether the response is limited to a certain number of deployments.

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 front-loads the core action and resource, then mentions the optional filters. There is no wasted wording or redundant repetition of the tool name.

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 list operation with an output schema and only two optional string parameters, the description is nearly adequate. Still, the lack of annotations, the vague 'recent' window, and no indication of pagination or default result limits leave some gaps for an agent deciding how 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?

The schema provides no descriptions, so the description's mention of filtering 'by service or status' adds meaningful context for both parameters. However, it does not explain accepted value formats, possible status values, or whether filters combine with AND/OR semantics.

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

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

The description states a specific verb and resource: 'List recent deployments' with optional filtering by service or status. It is clear enough to distinguish this from get_service, list_services, and rollback_deployment, though 'recent' is not precisely defined.

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 like list_services or rollback_deployment. The only usage signal is the implied purpose from the name and phrase 'optionally filtered by service or status'.

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 carries the burden of conveying behavior. It communicates a read-only listing action and a team filter, but does not disclose matching semantics for team, ordering, pagination, or any access constraints. This is acceptable for a simple list tool but not rich.

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?

One short, front-loaded sentence with no redundant or filler words. The action, resource, and optional filter are all present and each phrase earns its place.

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

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

For a low-complexity tool with one optional parameter and an output schema, the description covers the core operation and the filter. However, it omits usage routing and behavioral details such as team-match behavior and ordering, which leaves the description 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?

The schema has 0% description coverage, so the phrase 'optionally filtered by team' adds the key meaning that the single parameter restricts the result set rather than being an output field. It does not list valid team values or match rules, but for a simple optional string parameter the filter semantics are clear.

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

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

States a specific verb ('List') and a clear resource ('the Marvel heroes in the roster'), plus an optional team filter. The wording makes it distinguishable from siblings like get_hero and find_heroes_by_power, though it does not explicitly name those alternatives.

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

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

Provides no guidance about when to use this tool instead of related tools such as get_hero or find_heroes_by_power. The only usage context is implicit: to list roster heroes, optionally narrowed by team, with no exclusions or alternatives 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?

There are no annotations, so the description carries the full transparency burden. It discloses that filters are optional but does not explain how filters combine (AND vs OR), what the default result set is when no filters are provided, or whether results are paginated/sorted. The read-only nature is implied by 'List' but not explicitly stated.

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 with no wasted words. The main action ('List incidents') is front-loaded, and the optional filters immediately follow, making it easy for an agent to parse quickly.

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 is simple—three optional string parameters—and an output schema exists, so return-value documentation is likely covered elsewhere. Still, the description omits filter-combination semantics and valid values, which an agent would need to invoke the tool correctly in non-trivial cases.

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 does connect each parameter to its role as a filter, which adds meaning beyond bare parameter names. However, it provides no allowed values, formats, or examples, and the 'or' wording leaves filter combination ambiguous.

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

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

The description uses a specific verb ('List') with a clear resource ('incidents') and explicitly names the three optional filter dimensions (status, severity, service). This is immediately distinguishable from sibling mutation tools like open_incident and update_incident.

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 clear context: use this tool to list incidents, optionally narrowing by filters. However, it does not explicitly state when not to use it or name alternatives such as open_incident for retrieving a single incident, so it stops short of full exclusion guidance.

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

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

No annotations are provided, so the description bears the transparency burden. 'List' clearly implies a read-only, non-mutating operation, and the optional filters are mentioned. However, it does not disclose possible pagination, ordering, permission requirements, or how filters interact, though the presence of an output schema mitigates some return-value 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?

The description is a single focused sentence with no wasted words. The main purpose is front-loaded, and the optional-filter clause is concise. It is appropriately sized for a simple listing tool.

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 only two optional parameters, simple filter behavior, and an existing output schema, the description covers the essential calling context. It could add guidance on pagination or how multiple filters combine, but these are minor gaps for a low-complexity list tool.

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 adds the meaning that 'tier' and 'environment' are optional filters rather than required inputs. However, it does not explain acceptable values, semantics, or examples for either parameter, leaving the agent to rely on the parameter names themselves.

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

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

The description states a specific verb ('List'), a clear resource ('the application/service catalogue'), and the optional filtering behavior. This distinguishes it from sibling tools like list_deployments and get_runbook, so an agent can identify what this tool returns without opening the schema.

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

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

The description makes the intended use clear: retrieve the service catalogue, with optional tier/environment filtering. It does not explicitly state when not to use it or name alternatives, but the resource scope is specific enough that an agent can infer when this tool is appropriate.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does explicitly state 'Mutates server-side state,' which is a meaningful side-effect warning beyond the schema. However, it does not mention permissions, idempotency, or the consequences of repeated calls, leaving notable behavioral gaps.

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 short sentences, front-loaded with the primary action and followed by the mutation warning. There is no filler, no repetition, and every sentence contributes useful information.

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

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

The tool is a simple flat 3-parameter mutation with an output schema, so return values do not need deep explanation. Yet the definition omits parameter semantics and usage alternatives, and with no annotations it is only minimally adequate for reliable agent 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%, and the description only mentions 'service'; it does not explain 'summary' or 'severity' or how they relate. Since low schema coverage requires the description to compensate, the lack of parameter detail is a clear shortfall.

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

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

The description uses a specific verb ('Open') and resource ('a new incident against a service'), and the qualifier 'new' clearly distinguishes this from sibling tools like list_incidents and update_incident. The meaning is immediate and not a mere restatement of the title.

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?

There is no guidance on when to use this tool versus alternatives; it does not mention list_incidents for viewing incidents, update_incident for modifying existing ones, or any conditions that should prevent use. The only implicit context is 'against a service,' which is not enough to route an agent confidently.

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 behavioral burden. It does disclose that the LLM comes from the client via MCP sampling, which is useful, but it does not mention nondeterminism, latency, or potential client-side approval requirements.

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 one concise sentence with the core action front-loaded. It adds useful implementation context about MCP sampling and contains no unnecessary filler.

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

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

For a simple one-parameter tool, the description provides enough context to understand what the tool does and where the model comes from. It could more explicitly connect the theme parameter to the generated poem, but the overall behavior is adequately specified.

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 one required 'theme' parameter with no description and 0% schema description coverage. The tool description never mentions 'theme' or explains that the poem should be about that theme, so it fails to compensate for the missing parameter documentation.

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 a pydantic-ai agent writes a short rhyming poem, which is a specific verb plus resource. This distinguishes it from the sibling tools, none of which are poem generation 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?

The need for a rhyming poem is implied by the description, but there is no explicit guidance about when to use this tool versus alternatives, nor any stated exclusions or prerequisites.

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 the behavioral disclosure burden. It does warn that the operation is simulated and that it mutates server-side state, which is important. It stops short of explaining what the mutation does to existing state, whether it is reversible, or what side effects the agent should expect.

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 compact: two clauses cover the action, the parameter reference, the simulated nature, and the mutation warning. There is no redundancy or padding.

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 single-parameter operation with an output schema, the description is mostly adequate. The main gaps are lack of usage guidance and limited behavioral detail beyond 'mutates server-side state.'

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 for parameter meaning, but it only repeats 'by id' and adds no details about the ID format, where to obtain it, or any constraints. The property name 'deployment_id' already implies the basic meaning, so the description adds little 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 names a specific verb ('Roll back'), resource ('deployment'), and selection criterion ('by id'). This clearly distinguishes it from sibling tools like list_deployments or open_incident without requiring schema inspection.

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: call this when a deployment should be reverted to a previous state. However, it does not state when not to use it, what preconditions exist (such as the deployment being rollback-able), or that list_deployments may be needed to obtain the ID.

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?

There are no annotations, so the description carries the burden of explaining behavior. It adds useful context by calling the log stream 'synthetic, deterministic' and by indicating a non-mutating search operation. However, it does not mention ordering, pagination, or response shape, though an output schema exists.

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, well-structured sentence that front-loads the action and resource, states the search mechanism, and notes the optional filter. The parenthetical qualifier is meaningful rather than filler.

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

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

For a tool with one required parameter and an output schema, the description provides enough context to invoke it correctly: service, substring query, and optional level. The only notable omission is an explicit explanation of 'limit', which is a minor gap given the schema's default value.

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 must compensate. It effectively explains three parameters: service, query (the substring), and optional level filtering. However, the 'limit' parameter is not described at all, leaving its semantics to be inferred from the name and default value.

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

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

The description uses a specific verb ('Search') and names a concrete resource ('a service's log stream') with a clear scope (substring matching, optional level filtering). This clearly distinguishes it from sibling operations like get_service, check_service_health, or list_incidents.

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 when to use the tool—whenever you need to search a service's logs for a substring—but it gives no explicit when-not-to-use guidance or comparisons to alternative sibling tools. That is acceptable but leaves the routing decision partially to inference.

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 present, the description carries the burden of behavioral disclosure. It does usefully disclose that the LLM comes from the client via MCP sampling and that output is structured, which is meaningful. However, it does not mention side effects, failure modes, rate limits, or any constraints beyond that.

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 compact sentence with no filler. It front-loads the primary result (structured Summary) and adds the sampling detail in a second clause, making it 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?

For a one-parameter tool with an output schema, the description is close to adequate, but it misses an explicit statement that the tool summarizes the given text. It also offers no usage guidance, so an agent must rely on the tool name and schema to understand the full contract.

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 does not mention the `text` parameter at all. The parameter name is self-explanatory, but the description does not compensate for the lack of schema documentation by explaining expected format, length, or usage.

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 says a pydantic-ai agent returns a structured Summary, which hints at the action, but it never explicitly states that it summarizes the provided text. The tool name and `text` parameter make the purpose inferable, but the description itself is more about the internal mechanism than the user-facing operation.

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?

There is no guidance about when to use this tool, when not to use it, or which alternative to consider. It only describes the mechanism of structure generation and LLM sampling, not the invocation context.

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

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

No annotations are provided, so the description carries the full burden. It discloses the background-task nature, the 5-second interval, random log levels, and the start/stop toggle semantics. It does not mention return values or side effects, but the core behavior is unusually concrete.

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?

One sentence with no filler. It front-loads the action and object, and every word adds meaning.

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 zero-parameter toggle tool with an output schema, this description is complete: the agent knows what action to take, what the background task does, and how frequently it runs. Nothing essential is missing.

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

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

The schema has zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description appropriately does not invent any.

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

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

States a specific verb ('Start or stop'), a concrete resource ('a background task'), and an observable behavior (emits random-level log message every 5s). This clearly distinguishes it from sibling toggles like toggle_subscriber_updates and from trigger_long_running_operation.

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 intended usage is implied: use it to start or stop simulated logging. However, it does not explicitly discuss when not to use it or compare it with sibling tools that also manage background activity, so the guidance is not fully spelled out.

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 that the tool changes runtime state by starting or stopping a background task and that it emits resources/updated events. However, with no annotations, it omits important behavioral details such as whether repeated calls flip state, whether the task persists, and what happens with no subscribed resources.

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 that states the action and the observable effect without filler or redundant restatement of the title.

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 zero-parameter tool with an output schema, the description covers the core effect, but the toggle semantics are ambiguous: an agent cannot tell whether a call always starts, always stops, or flips the current state. It also leaves 'subscribed resource' and cross-call side effects unexplained, which matters for a state-changing tool with no annotations.

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?

There are zero parameters, so the description has no parameter meaning to add. The baseline of 4 applies because the parameter side is complete and requires no compensation.

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 names the action ('Start or stop'), the resource ('a background task'), and the effect ('emits resources/updated for every subscribed resource'). It is independently intelligible, though it does not explicitly contrast itself with sibling tools like toggle_simulated_logging.

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 guidance on when to use this tool versus alternatives. It does not state prerequisites, expected contexts, or what distinguishes this from toggle_simulated_logging or trigger_long_running_operation.

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, and it does disclose two important behaviors: the job is fabricated ('fake') and it emits a progress notification on each step. This effectively signals a safe, simulated operation. It does not detail blocking behavior, notification target, or completion effects, but the core behavioral contract is clear.

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?

One sentence with no filler; the key facts (fake, multi-step, per-step progress notification) are stated up front. This is appropriately sized for a low-complexity tool.

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, optional-parameter fake job with an output schema, the description covers the core invocation behavior. It could add a sentence about how the two parameters shape the run, but defaults and self-explanatory names plus the output schema make the definition mostly 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?

The schema has no descriptions for the two parameters and schema coverage is 0%, so the description needed to explain how 'steps' and 'step_seconds' control the operation. 'Multi-step' hints at 'steps', but the description says nothing about 'step_seconds' or how either parameter affects execution. Parameter names and titles are somewhat self-explanatory, but not enough at 0% 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 names a specific verb ('Run'), a specific resource ('a fake multi-step job'), and the observable behavior ('emitting a progress notification per step'). The word 'fake' distinguishes it from real operational tools in the sibling list, so an agent can identify what this tool is for.

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 'fake' qualifier implies the tool is for testing or demonstration rather than real operations, but the description never explicitly states when to use it or which alternatives to prefer. There is no exclusionary guidance or mention of sibling tools, leaving the usage context to be inferred.

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 the full disclosure burden. It explicitly warns 'Mutates state,' which clearly signals that this is a side-effecting operation. It also discloses the status subset and the optional note behavior, giving the agent a solid behavioral picture beyond the tool 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 two concise sentences with no filler. The primary operation is front-loaded, and the mutation warning earns its place as a separate, high-signal disclosure.

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 three-parameter mutation tool with an output schema, the description covers the key invocation details: target status and optional note. The main gap is the lack of usage guidance around interacting with incident lifecycle siblings, but the essential call semantics are present.

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 adds meaning by enumerating the intended status values and by saying the note is optional, but it does not explain the note's role or incident_id beyond what the schema already shows. This is adequate but not thorough.

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

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

The description uses a specific verb ('Move') with a clear resource ('an incident') and target state ('acknowledged/mitigated/resolved'), making the core purpose obvious. It does not explicitly distinguish this from sibling status-related tools like open_incident, but the listed statuses narrow the intent well.

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 action 'Move an incident to a new status...' implies that the tool is for status transitions, so an agent can infer when to use it. However, it provides no explicit when-not-to-use guidance or mention of alternatives such as open_incident, leaving some room for confusion.

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 behavioral burden, and it only partially fulfills it. It discloses the core transformation behavior but stays silent on the non-deterministic sampling implied by the title — outputs are LLM-generated and may vary between calls — as well as latency or possible failure modes. An agent invoking this tool has no warning that repeated calls with identical input may not produce identical forecasts.

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 19-word sentence with no filler; the core action is front-loaded. Minor quibble: the 'pydantic-ai agent' phrasing repeats implementation detail already present in the title, but nothing is bloated or redundant.

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 output schema exists, so return values need not be described. For a one-parameter tool with an output schema, the description covers the core contract, but it omits the sampling-driven behavior and sibling-usage guidance, so an agent must infer important operational context rather than have it stated.

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 never mentions the location parameter, so the description adds nothing to parameter meaning. The schema self-documents reasonably via the enum ['Zurich', 'Savognin'] and default 'Zurich', which mitigates the gap, but the 0% coverage means the description was expected to compensate and did not.

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

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

The description names a specific transformation — 'turns the structured readings for a city into a short spoken-style forecast' — with a clear verb, resource, and output form. The contrast with the sibling get_structured_weather is implicit but recognizable: this tool synthesizes a spoken-style narrative rather than returning raw structured data. It is clear, though it never explicitly names the sibling it differs from.

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. The closest signal is the implicit contrast with get_structured_weather ('structured readings' vs 'spoken-style forecast'), which an agent must infer rather than be told. There are no exclusions or prerequisite conditions stated, leaving usage context 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.