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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: output is 'sanitized' (privacy handling) and 'deterministic' (no model inference), which shapes what the agent should expect. It omits latency, response shape, and the openWorldHint implication.

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 compact sentence with zero waste; the output nature is front-loaded and the constraint ('no AI root-cause claim') is appended where it belongs. Nothing redundant with the name or annotations.

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

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

One simple required parameter, no output schema, and rich annotations mean the description's burden is light, and it does explain the deliverable (evidence + investigation areas, not a diagnosis). It would be stronger if it hinted at the structure of 'investigation areas' or where the messageId comes from.

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 messageId, its format, or where to obtain it. The schema constrains the value (pattern, maxLength 256) but does not explain what a messageId refers to, so the description fails to compensate for the coverage 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?

States a specific verb+resource: it gathers 'sanitized diagnostic evidence and deterministic investigation areas' rather than making a root-cause claim. This is clearly different from the sibling reads like get_error_details or get_recent_failures, though no sibling is named. The phrase 'deterministic investigation areas' is slightly abstract but still conveys a distinct output goal.

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 only implied: an agent infers this is the tool you call on a failure message when you want evidence rather than a diagnosis. No alternatives (get_error_details, get_recent_failures) are named and no conditions or prerequisites are given. The 'no AI root-cause claim' note functions as a when-not, which is why this is not a 2.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds 'sanitized' (suggesting redacted/safe output) and 'deterministic indicators' (suggesting consistent results), which are useful but vague and do not disclose auth needs, rate limits, or 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?

A single front-loaded sentence with no filler or repetition. However, its vague terms ('sanitized', 'deterministic indicators') do not fully earn their place by conveying actionable meaning, keeping it from a 5.

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 retrieval tool with one required parameter and no output schema, the description is too thin. It should at least clarify the messageId parameter's role and what the returned error information or indicators look like, given that no output schema exists to explain the return 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 description coverage is 0%, so the single required messageId parameter has no schema-level explanation. The description does not mention messageId at all, nor does it say what kind of message identifier to supply or where to obtain it. The parameter name is somewhat self-explanatory, but the description adds essentially no semantic meaning beyond the schema.

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

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

States a specific verb ('Retrieve') and resource ('error information'), but 'sanitized' and 'deterministic indicators' are vague jargon, and the description never mentions that it operates on a specific message. It does not differentiate this tool from siblings like get_message_details or analyze_failure, so an agent cannot tell its scope apart from related 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?

Provides no when-to-use guidance, no prerequisites, and no alternatives. Siblings such as get_message_details, get_failed_messages, and analyze_failure are never mentioned, leaving the agent to infer when this specific retrieval 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds only that package filtering is unsupported, but does not explain return shape, pagination, time-range behavior, or how failures are scoped; it also contradicts the schema's package parameter.

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. However, its two clauses are not well structured around the tool's actual invocation needs, since the unsupported-package claim is not connected to the 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?

For a tool with five optional parameters and no output schema, the description is insufficient: it does not explain time filtering, result limiting, integration flow scoping, or what metadata is returned. Annotations cover safety, but the description leaves important invocation details 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% for five parameters, so the description must carry parameter meaning. It mentions only 'package' and says its filtering is unsupported, while the schema still exposes a package parameter, leaving limit, startTime, endTime, and integrationFlow completely undocumented and the package behavior confusing.

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 clear verb and resource, 'Retrieve failed message metadata,' so the operation is identifiable. It does not distinguish this from adjacent siblings such as get_recent_failures or analyze_failure, so it is clear but not sibling-differentiating.

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 only usage-like statement is that package filtering is unsupported, which is a limitation rather than guidance on when to choose this over search_messages, get_recent_failures, or get_message_details. No explicit when-to-use or alternatives are provided.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds a modest behavioral detail that an unavailable result can be returned explicitly, but omits auth, rate limits, and what 'status' actually contains.

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?

It is a single short sentence with no filler, and the retrieval verb is front-loaded. However, the cryptic 'runtime artifact' phrasing means brevity comes at the cost of precision.

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 getter with no output schema, the description should explain what status values mean and what an unavailable result looks like. It does neither, and it also leaves the required parameter undocumented, so it is incomplete for correct invocation.

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

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

Schema description coverage is 0% and the sole required parameter 'integrationFlow' is not mentioned in the description at all. No meaning, format, or pattern guidance is added to compensate.

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 gives a verb ('Retrieve') and a resource ('runtime artifact status'), but 'runtime artifact' is vague jargon that is not clearly tied to the integration flow concept in the tool name or parameter. It also fails to distinguish this tool from sibling health/failure/message 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?

There is no guidance on when to use this tool versus alternatives like summarize_integration_health or get_recent_failures. The only extra qualification concerns unavailable results, which describes output behavior rather than usage context.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds useful behavioral context by stating the response excludes business payloads, but says nothing about missing-message behavior, permissions, or what metadata fields are actually returned.

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 front-loaded sentence with zero filler; the scope qualifier is attached directly to the resource it modifies.

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 read-only lookup with rich annotations and no output schema, the description adequately signals that payloads are excluded. It falls short on what metadata is returned and on distinguishing this lookup from sibling retrieval tools.

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

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

The single messageId parameter has 0% schema description coverage and the description doesn't mention it at all. Only the schema's pattern and length constraints hint at format; the description adds no meaning beyond that.

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 (Retrieve) and resource (message processing log metadata) and clarifies scope with 'without business payloads'. However, it does not distinguish itself from siblings like get_error_details or search_messages, so an agent must infer the difference.

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 the many siblings (search_messages, get_error_details, get_recent_failures). Usage is only implied by the required messageId, with no exclusions or routing conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so safety and repeatability are covered. The description adds nothing beyond the time-window scope: no ordering, pagination, cap behavior, or what happens when the limit is hit.

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 with no redundancy and the scope constraint front-loaded. Brevity here edges toward under-specification rather than bloat, but there is no wasted verbiage.

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 three parameters, no output schema, and no annotation-level detail on returns, the definition needs to explain the limit/integrationFlow behavior and roughly what a 'failure' record contains. The single sentence is inadequate for a filtered-list tool with an undocumented filter parameter.

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 carries the burden for three parameters. It only alludes to 'minutes' and says nothing about the 'limit' cap (default 100, max 500) or what the 'integrationFlow' filter does, leaving two of three parameters semantically opaque.

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 gives a specific verb and resource ('Retrieve failures') plus a scoping constraint ('within the last N minutes'), so the agent knows the operation. However, it does nothing to distinguish this from siblings like get_failed_messages or analyze_failure, which plausibly return overlapping 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?

There is no guidance on when to choose this over get_failed_messages, get_error_details, or analyze_failure, nor any stated preconditions. Usage must be entirely inferred from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The only added claim, 'maximum 500 results', duplicates the schema's limit maximum of 500 rather than adding new behavioral context such as pagination, result ordering, or cross-flow scope.

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 short, front-loaded sentence with no wasted words or filler. It is efficient, though its brevity reflects omission rather than thoughtful prioritization.

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 7-parameter search tool with no parameter descriptions and no output schema, one sentence is far too little. There is no indication of what fields are returned, how the filters combine, or how results are ordered/paginated, leaving an agent under-equipped to call 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% across 7 parameters (status enum, startTime/endTime, messageId, correlationId, integrationFlow, limit), and the description supplies no meaning for any of them. With zero schema documentation, the description was the only place to explain these filters and it explains none.

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 ('Search') and resource ('normalized message metadata'), which is clear enough to distinguish it from get_message_details (single-message retrieval). However, it offers no differentiation from near-siblings like get_failed_messages, get_recent_failures, or get_error_details, which are also filtered message lookups.

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 when-to-use guidance, no when-not-to-use, and no named alternative. An agent cannot tell from the text whether to use this broad search or the more targeted get_failed_messages / get_recent_failures siblings.

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

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

Annotations already declare this as read-only, idempotent, open-world, and non-destructive. The description adds the 500-message cap, the 24-hour default, and a 'Check truncation' caveat, which are useful behavioral details beyond the annotations, but they are not elaborated.

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

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

Two short sentences with no padding and the core scope is front-loaded. 'Check truncation' is cryptic but the overall structure is 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?

With no output schema and no parameter descriptions, the description should do more to explain what statistics are returned and how the time parameters behave. It covers the basic scope and one caution, but leaves key details 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% for two optional date-time parameters. The description only implies a default time range ('past 24 hours') and never explains startTime/endTime naming, format, or what happens when only one is supplied. Partial compensation at best.

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 general verb+resource ('Calculate statistics from up to 500 messages'), but 'statistics' is vague and the description never mentions 'integration health' from the tool name. It does not distinguish this tool from sibling analysis or message-retrieval 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?

No when-to-use guidance or alternatives are provided. The mention of a 24-hour default and 500-message cap gives context but does not say when an agent should choose this tool over get_recent_failures, analyze_failure, or search_messages.

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