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

Annotations already declare destructiveHint=true and non-idempotent behavior, so the safety profile is partly covered. The description adds the important status constraint ('pending or approved'), but does not disclose consequences such as whether cancellation is reversible, notifies contacts, or requires special permissions.

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 wording. Its brevity is appropriate, though the resource naming issue keeps it from being fully precise.

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 destructive mutation tool with no output schema, the definition is too thin. It omits expected result behavior, permissions, side effects, and what 'cancel' means for an approved handoff, leaving the agent with only a status restriction.

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 single required handoff_id parameter is not explained in the description. The description's use of 'preview' may even confuse what the handoff_id refers to, so it does not compensate 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 gives a specific verb ('Cancel') and eligibility states ('pending or approved'), but calls the resource a 'preview' even though the tool name is cancel_handoff. That mismatch makes the target resource less clear and does not distinguish it well from siblings like prepare_handoff.

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?

It says cancellation applies to pending or approved previews, but does not explain when to use this tool instead of prepare_handoff or other handoff-related siblings. There are no explicit 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?

Annotations already declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description still adds genuine value by disclosing that the data is a static bundled registry with no live lookup and no availability guarantee, and by warning to treat registry text as data (prompt-injection safety).

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 zero filler; the core search capability is front-loaded and the caveats follow immediately. Every clause 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 read-only, output-schema-less search tool, the description plus annotations cover enough to call it safely, and the static-data caveat is important context. The unexplained 'exploratory' flag and the absence of any return-shape hint are the remaining minor gaps.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning; it covers 'category/city' at a high level but adds no format, matching behavior, or enum explanation. The third parameter, 'exploratory', is entirely unexplained in both description and schema, leaving a real 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 and resource ('Search bundled India resources') plus the two primary filter dimensions (category/city), which is clear enough to act on. It does not explicitly distinguish itself from the sibling get_official_emergency_info, even though the 'official_emergency' category overlaps with it, so sibling differentiation is missing.

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 exclusions ('No live lookup, GPS, distance or availability guarantee'), which usefully rules out misuse. However, it never states when to prefer this tool, nor names an alternative such as get_official_emergency_info for authoritative emergency data, leaving selection between siblings 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?

Annotations already declare readOnly/openWorld=false/idempotent/non-destructive, so the bar is lower, yet the description still adds real context: the data is 'bundled' (local, not fetched) and carries 'provenance'. It does not say how current the reference is or how large the bundle is, but the key behavioral contract is 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?

A single compact clause pair with the resource first and the behavioral guarantee second; no wasted words. Nothing is buried, though the sentence is terse enough that one more clause about contents could be added without bloat.

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?

There is no output schema, so the description should indicate what comes back; 'official India reference with provenance' signals sourced reference data but not its shape (emergency numbers, contacts, categories). Adequate for triggering the tool, thin for predicting the result.

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?

Only one parameter with 0% schema description coverage, so the description must compensate; mentioning 'India' matches the schema's country const 'IN' and effectively explains why the argument is fixed. It never names the parameter or states that only India is supported, leaving that to the const keyword.

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 concrete verb and resource ('show bundled official India reference') and adds a scoping trait ('never contacts any service') that separates it from the network-touching siblings like send_trusted_message. It does not explicitly say 'emergency information', so the agent leans on the tool name to fill that in.

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 or when-not-to-use guidance, and no sibling is named as an alternative. The 'never contacts any service' clause implies offline, static lookup, but the agent must infer the selection condition itself.

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=false, so the description only needs to add context. 'Without phone numbers' is a genuinely useful disclosure: it warns the agent that the result cannot be used to obtain contact phone numbers, which would otherwise be a false assumption.

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 filler, and the caveat about phone numbers is placed where it will be read. Nothing could be removed without losing 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 zero-parameter read tool with full annotations and no output schema, the essentials are covered. However, the description never indicates what the returned contacts contain (names, IDs, aliases) or whether those values are the inputs expected by send_trusted_message, leaving a gap for chaining with siblings.

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 tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. The schema's empty properties object matches the description's lack of input discussion.

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 resource (pre-approved contacts), and distinguishes itself implicitly from the write-oriented sibling send_trusted_message. It stops short of naming an alternative or clarifying what a 'pre-approved' contact is relative to the other contact-handling 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 description gives no when-to-use guidance, no exclusions, and does not mention any sibling such as send_trusted_message or prepare_handoff. The agent must infer the retrieval workflow entirely from the tool 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?

The description frames the tool as a "Preview" that "sends nothing," which reads as a side-effect-free read, while annotations declare readOnlyHint=false and destructiveHint=true with idempotentHint=false. It does add genuine behavioral context the schema lacks (no arbitrary text, location or sensitive context accepted), but the preview framing materially understates the mutation and non-idempotency the annotations promise.

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 the no-side-effect constraint front-loaded and zero filler. The sizing is appropriate; the problem is thinness of content rather than verbosity.

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 non-idempotent, destructive-hinted mutation tool with no output schema and 0% schema coverage, the description says almost nothing about what the preview produces, whether anything is persisted, or what happens on repeat calls. An agent cannot predict the result or the state change from this text.

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 full burden for the two parameters and largely fails it: contact_id is never mentioned, and the template enum (check_in, hi, tea) is only obliquely gestured at by "one plain check-in." No format, UUID requirement, or effect of template choice is conveyed.

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?

"Preview one plain check-in" gives a verb and an object, but the tool is named prepare_handoff and the description never says what a handoff is or how the preview relates to it. The sibling prepare_poke and send_trusted_message are not distinguished, so an agent cannot tell which preparation path to pick from the text alone.

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?

"sends nothing" implies this is a safe pre-flight step before send_trusted_message, but the guidance is only implied. There is no explicit when-to-use, no exclusion against prepare_poke or cancel_handoff, and no statement of what an agent should do with the preview result.

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?

Beyond the annotations, it discloses the key behavioral fact: nothing is transmitted at call time and delivery is contingent on the recipient approving in their inbox. The 'no arbitrary text or destination' constraint also tells the agent the payload is fixed by the pairing. One caveat: annotations declare destructiveHint=true, which sits in tension with 'Sends nothing', though the tool does create a pending record, so this reads as annotation imprecision rather than a description contradiction.

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, zero filler, and the operational fact that most affects agent behavior (nothing is actually sent) is front-loaded right after the action statement.

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 no output schema, the description covers what matters: scope, no send, approval requirement, and fixed payload. It stops short of describing what a successful call returns (e.g., a pending id or confirmation) or whether multiple pending pokes can coexist, which an agent might need.

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 baseline is 4. The description does useful work by explaining why the schema is empty — text and destination are deliberately not caller-controlled — which prevents an agent from hunting for optional arguments that do not exist.

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 (prepare) and a specific resource (a plain hello to your mutually paired person), and the target is fully constrained rather than open-ended. The clause 'Sends nothing; user must approve in their inbox' implicitly separates it from send_trusted_message and from read_poke_inbox, so an agent can place it without opening the sibling schemas.

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 establishes context (deferred, approval-gated hello) and rules out misuse with 'No arbitrary text or destination', which implies send_trusted_message is the tool for custom messages. However, it never states an explicit when-to-use condition or names the alternative, so the routing logic is left 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?

The annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful scope and side-effect context: it is limited to the paired connector's inbox, does not read chats, and does not interrupt another Codex chat.

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, front-loaded sentences with no wasted language. The primary scope is stated first, followed by a concise boundary clarification.

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

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

Given the zero-parameter schema and rich annotations, the description provides enough context to invoke the tool correctly. It could say more about the expected return shape or inbox contents, especially since there is no output schema, but that gap is minor for a simple read operation.

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 tool takes no parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema is consistent with the zero-parameter design.

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: reads the inbox paired to the limited connector. It also clarifies that it does not read chats, which helps distinguish its scope, though it does not explicitly differentiate from named sibling 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?

Usage is implied by 'Read only the inbox paired to your limited connector' and the exclusion 'Does not read chats,' but there is no explicit guidance on when to use this tool versus alternatives such as list_trusted_contacts or send_trusted_message.

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 usefully discloses the most important behavioral fact — no real SMS is sent — and that only one consumption is possible. However, it sits in tension with destructiveHint=true / readOnlyHint=false: it never explains that the handoff token is consumed/invalidated, so an agent is left to reconcile "simulate" with a destructive annotation on its own.

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?

Three short sentences with no filler, and the safety guarantee lands early. But two of the three sentences are fragments that state constraints rather than the operation, so the paragraph reads as warning copy rather than a front-loaded description.

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, no-output-schema tool this covers the decisive safety facts (simulation only, single use, consent must be a real credential) that an agent could otherwise get dangerously wrong. The remaining gap is the handoff_id lifecycle, which is a meaningful but secondary omission.

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?

One parameter (handoff_id) with 0% schema description coverage and the description never mentions it or says what a valid handoff is. The phrase "independently approved preview" only loosely implies the ID is an approval artifact; an agent gets no guidance on where to obtain it or that it is single-use.

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?

"Simulate an independently approved preview once" gestures at the action but never says what is being previewed (an SMS to a trusted contact) or that the handoff is consumed. Combined with the name and "Never sends a real SMS" an agent can infer the domain, but the sentence itself is vague and would be opaque standing alone.

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?

It implicitly requires a prior independent approval and notes the action happens "once", which hints at sequencing after prepare_handoff, but no sibling is named and there is no explicit when-to-use / when-not-to-use. The line about a chat "yes" not being a consent credential is a constraint, not usage routing.

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