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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the description's main addition is 'Irreversible,' which adds meaningful risk context beyond the generic destructive hint. It does not discuss auth, errors, or response behavior, but the annotation coverage lowers the burden. The description is consistent with the destructive annotation.

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 deliver the operation type and the critical safety warning with no filler. Front-loading 'DELETE' and 'Irreversible' makes the risk immediately visible. This is concise without sacrificing necessary 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?

For a three-parameter generic wrapper with no output schema and an openWorldHint, the description is minimally adequate: it states the operation and warns of irreversibility. It does not mention how to discover valid paths or when to prefer it over specialized sibling operations, though the schema and sibling tools partly cover that gap. More guidance on using this as a low-level fallback would improve completeness.

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

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

Schema description coverage is 100%, and the schema already explains path templates, query repetition, and path_params substitution, so the description need not repeat parameter details. The description does not add any extra semantic context about parameters, but none is required at this coverage level.

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 identifies this as a DELETE operation against any All Quiet API endpoint ('DELETE through any All Quiet API operation'), which clearly distinguishes it from call_read and call_write by HTTP method. It is not tied to a specific resource, but that is appropriate for a generic wrapper. The bare title 'call_delete' is amplified by the description's explicit verb and irreversibility warning.

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 conveys that the tool is the generic DELETE path for All Quiet API operations, implying it should be used when a destructive endpoint must be called. It does not explicitly say when to prefer call_delete over the specialized incident operations or describe preconditions such as first resolving the path via list_operations. No exclusions or alternative selection conditions are 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description only needs to add context beyond that. The phrase 'GET any All Quiet API operation' conveys the tool's generic pass-through nature. It does not disclose error handling or auth requirements, but given annotation coverage, the added context is acceptable.

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 redundant filler. The core purpose is front-loaded, and the workflow instruction is concise.

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

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

For a generic read proxy, the description plus schema covers the essentials: what to provide (path/query/path_params) and how to discover operations. Since there is no output schema, exact return depends on the specific All Quiet operation, which is implied by 'any operation' and openWorldHint. This is adequate, though it could mention that the response format varies.

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

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

Schema description coverage is 100%, with detailed descriptions for path, query, and path_params including examples like '/team/{id}' and repeated key syntax. The description itself adds no parameter-specific information, but the schema fully documents the parameters, so the baseline of 3 applies.

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

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

Description states a specific verb 'GET' and a resource 'any All Quiet API operation', clearly distinguishing this read tool from call_write and call_delete. The reference to list_operations further clarifies its role as a generic dispatcher.

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 instruction 'Find it first with list_operations' gives an explicit workflow for when to use this tool. It implies that call_read is for read-only GET operations, but does not explicitly state when not to use it or name call_write/call_delete as alternatives.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's 'Create or change' is consistent. It adds the useful JSON-body-only constraint, but does not disclose responses, auth needs, rate limits, or side-effect details.

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. It is concise and readable, though it could have used additional structure to explain the generic pass-through behavior.

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-level generic API caller with five parameters and no output schema, this description is incomplete. It does not explain how to assemble path_params, query, and body together, nor what a successful write call returns or how to discover operation-specific details.

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

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

Schema description coverage is 80%, so most parameter meaning is already documented. The description adds minimal value beyond 'JSON bodies only,' which clarifies the body parameter but does not compensate for the vague 'see describe_operation' reference.

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 phrase, 'Create or change,' and identifies the tool as a generic write path through All Quiet API operations. It is distinguishable from siblings like call_read and call_delete by its write focus and method enum.

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 explicit guidance about when to use this tool versus call_read, call_delete, or the higher-level CRUD tools. The agent is left to infer that this is for write operations not covered by specific sibling tools.

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

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

Annotations already communicate that this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the team-scoping constraint but does not disclose side effects, status defaults, or permission needs. It does not contradict the annotations.

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 filler. It is front-loaded with the core action, though the phrase 'one of the key's teams' is somewhat ambiguous and could be clearer.

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 write tool with five parameters, no output schema, and only basic annotations, this description is too thin. It does not explain return values, the role of optional parameters, required fields, or how this creation action differs operationally from update_incident.

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 only 40%, and the description does not compensate for the missing meaning of title, message, or team_ids. It vaguely suggests team scoping, but team_ids is optional with a null default, which is potentially confusing. Required parameters like title and severity are not explained beyond their schema types.

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 clear action ('Open') and resource ('incident'), and adds scope ('in one of the key's teams'). It is distinguishable from siblings like list_incidents, get_incident, and update_incident, 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?

There is no guidance on when to use this tool versus alternatives such as update_incident or the call_write/generic write tools. The one-sentence description implies a creation action but provides no exclusions or 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 mark the tool as read-only and open-world, so no side-effect warning is needed. The description adds valuable behavioral detail beyond those annotations: it discloses that $refs are inlined and that repeated schemas are represented once with a {'$see': name} placeholder, which meaningfully informs an agent about the output 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?

Two sentences with no filler. The first sentence states the core function, and the second adds a necessary, non-obvious detail about schema deduplication. Fully front-loaded.

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 adequately covers the output behavior for a read-only schema-inspection tool, especially given the annotations. However, it does not specify accepted method values or connect to list_operations as the source of valid method/path pairs, leaving a small but real gap 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 schema documents path well with an explicit format example ('/team/{id}'), but method has no description, no enum, and no format example. Since schema description coverage is only 50%, the tool description needed to compensate by explaining what values method accepts, but 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 verb ('Show') and resource ('an operation's parameters and JSON request body schema'), which clearly distinguishes it from execution tools like call_read and enumeration tools like list_operations. The $ref inlining detail further sharpens the 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 read-only inspection purpose makes it clear this is likely used before invoking a call tool, but the description gives no explicit when-to-use guidance, exclusions, or alternative routing. Usage context is implied rather than 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?

Annotations already provide readOnlyHint and openWorldHint. The description adds value by revealing the output format (markdown), the included sections, and the dynamic presence of update_incident intents, which is useful behavioral context not visible in annotations.

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. It immediately states the resource and output form, then adds the relevant update_incident context.

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 read-only tool, the description explains the return contents and links to update_incident behavior. It does not state when to use this instead of list_incidents or how to get incident_id, but annotations cover the safety profile and no output schema exists to compensate.

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 explain incident_id beyond what is inferable from the parameter name. There is no guidance on where the ID comes from, its format, or how it relates to list_incidents or create_incident.

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 and resource: retrieving an incident in full markdown form. It lists the contents (timeline, attributes, assignees) and references update_incident, which distinguishes this from sibling tools like 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 use when full incident detail is needed and hints that this output is relevant before calling update_incident. However, it does not explicitly state when not to use it or which sibling to prefer for lighter or different use cases.

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

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

Annotations already declare readOnlyHint=true, so safety is established. The description adds that results are compact summaries rather than full incident objects, which is a useful behavioral nuance. However, it does not disclose pagination behavior, defaulting, or what fields a compact summary 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?

Two short, front-loaded sentences with no filler. The core action and output shape come first, and the sibling pointer is placed second without unnecessary elaboration.

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 read-only list tool, the description plus schema is mostly sufficient to select and invoke it, and the pointer to get_incident clarifies scope. However, with 9 optional parameters, no output schema, and no explanation of pagination or compact-summary contents, some context is still 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 only 44%, and several parameters such as team_ids, user_ids, and search_term are undocumented in the schema. The description adds no parameter-level guidance, so it does not compensate for the low 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?

States a specific action ('List') and resource ('incidents'), and immediately characterizes the response shape ('compact summaries'). It also distinguishes itself from the sibling get_incident by explicitly deferring full timelines there.

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

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

Explicitly tells the agent to use get_incident when a full timeline is needed, which defines the boundary between the two incident tools. It doesn't exhaustively cover alternatives, but the relevant sibling comparison is clear and actionable.

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 and openWorldHint=true, so the description need not restate those. It does add the output format, which gives useful context about the response structure. However, it doesn't disclose any limits or pagination behavior, and the openWorldHint could imply a broad scope that the description doesn't elaborate on. Overall, it adds some value but not substantial behavioral detail.

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 packed sentence. It leads with the core action, immediately specifies the resource, and then gives the exact output format. There is zero waste, and every element adds value.

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

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

For a simple read-only tool with one optional parameter and no output schema, this description is complete. It tells the agent what the tool returns and in what format. The query parameter is already documented in the schema, and the read-only nature is covered by annotations. Nothing an agent needs to call it correctly 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 already provides a full description of the 'query' parameter (case-insensitive filter on method, path, summary) with 100% coverage. The tool description does not add any additional meaning about the parameter, so the baseline of 3 applies. No extra context is given about the query's behavior or syntax.

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' and a specific resource 'All Quiet API operations', and even specifies the exact output format (`METHOD path — summary [required key scope]`). This makes the tool's purpose unmistakable and clearly distinguishes it from sibling tools like describe_operation or call_*.

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 states what the tool does but provides no explicit guidance on when to use it versus alternatives. It doesn't mention that this is for discovering available operations, nor does it point to describe_operation for details on a specific operation. The usage context is implied but not articulated.

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 declare readOnlyHint=false and destructiveHint=false, and the description's 'record' implies mutation, consistent with those. However, the description does not disclose any additional behavioral traits such as side effects, notifications, or reversibility. It adds little beyond what the annotations already convey, so it meets the baseline but not more.

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 with no wasted words. The essential purpose is front-loaded, and the description is appropriately sized for the tool's simplicity.

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 mutation tool with 4 parameters and no output schema, the description is too sparse. It does not explain the relationship between intent and message, does not mention that allowed intents depend on current incident state (only in schema), and gives no examples of full usage. An agent would need to inspect the schema carefully to use it correctly, so the description alone is insufficient.

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 low (25%). The description mentions 'resolve, acknowledge, comment...' which partially maps to the intent parameter, and 'change severity' maps to severity. However, it does not explain the message or incident_id semantics, nor does it clarify when message is needed or how it relates to intent. It adds marginal value over the schema's existing descriptions and does not 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?

The description states a clear action (record an action) on incidents, with examples of actions and severity change. It distinguishes from create_incident by implying modification, though it does not explicitly say 'update existing', so it is clear but not perfectly specific.

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 like create_incident or call_write. It does not mention that get_incident should be checked first for allowed actions (only in the schema), nor does it provide any exclusions or conditions. The usage context is entirely implied.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the tool is known to be a safe read operation. The description adds the fact that it returns escalation tier information, which is useful context. However, it doesn't disclose return format, pagination, or any edge cases (e.g., behavior when no teams are specified). Given the annotations cover the safety profile, a score of 3 is appropriate—the description adds some value but not rich behavioral detail.

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, efficient sentence with no filler words. It is front-loaded with the core question 'Who is on call' and immediately adds the per-team and escalation-tier scope. It earns a high score for conciseness, though it could be slightly expanded without losing efficiency.

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 minimal annotations, the description carries the burden of explaining what the tool returns and how to call it. It fails to mention that team_ids and user_ids are optional filters, that timestamp defaults to now, or what the response structure looks like. An agent might mis-call the tool by providing required parameters that don't exist or missing optional ones. The tool is simple enough that a richer description could easily make it 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 only 33% (timestamp has a description, team_ids and user_ids do not). The tool description does not explain the semantics of team_ids or user_ids, nor does it clarify that they are optional filters. Since the schema is under-documented and the description fails to compensate, the agent lacks critical information about how to use the filtering parameters.

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

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

The description clearly states the tool returns who is on call, per team, and includes escalation tier. It specifies the resource (on-call personnel) and the key output dimensions, which distinguishes it from sibling tools focused on operations or incidents. However, it doesn't explicitly mention filtering options or the ability to query by user, which could add further clarity.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. There is no statement like 'Use this to check on-call coverage' or 'For incident history, see list_incidents instead.' The agent is left to infer the tool's purpose from the name and description alone.

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