Call Me

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

Beyond the annotations (non-read-only, world-open, destructive), the description discloses the timeout behavior, the 'ringing' status path requiring polling, the local config caveat, and session continuity. None of this contradicts the annotations; it adds concrete operational context.

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 but every sentence adds operational value: main behavior, wait/fallback, config handling, number format, and threading. It front-loads the primary purpose and then gives necessary caveats without fluff.

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 side-effectful tool with no output schema and four parameters, it covers the core call flow, status handling, local/hosted differences, output expectation, and session threading. The only small omission is `from_label`, but it is optional, titled clearly in the schema, and not needed 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?

With 0% schema description coverage, the description compensates well by explaining `to`, `question`, and `session_token`. It does not mention `from_label`, though its title and default provide some inference; a brief note about the caller label would make this fully complete.

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 opens with a concrete action: 'Ring the human's iPhone, speak the question aloud, and return what they say.' This names the resource, the operation, and the returned result, and clearly separates this voice-call tool from siblings like text and poll_result.

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 gives explicit workflow guidance: wait ~30s, and if status is 'ringing', use poll_result. It also states constraints around the `to` value (10-digit /call-me app number, not a real number) and the local-vs-hosted config difference, so an agent knows when and how to use it correctly.

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 annotations (readOnlyHint, destructiveHint), the description discloses waiting behavior (~25s), possible outcomes (answers, declines, missed), and that it returns a transcript. This adds valuable context without contradicting 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 compact two-sentence structure, front-loaded with the core purpose and followed by concise behavioral details. Every word 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 simple read-only polling tool with no output schema, the description covers what it does, when to use it, how long it waits, and what it returns. It is complete enough for an agent to invoke 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?

The schema has no descriptions for the two parameters (0% coverage), and the description does not compensate by explaining 'call_id' or 'session_token'. While the names are somewhat self-explanatory, the description adds no explicit semantics 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 uses a specific verb ('Check'), names the resource ('a call that was still ringing'), and clearly describes the outcome (returns final status and transcript). It distinguishes from siblings like 'call' (initiation) and 'wait_for_reply' (text reply) by focusing on polling a ringing 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 implies the usage context: use it when a call was still ringing and you need to wait for the outcome. It does not explicitly name alternatives or exclusions, but the context is clear enough relative to 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 indicate destructiveHint=true, so the description's mention of 'Name' and 'thread title' adds context that this changes a persistent label. This is consistent with the annotations and clarifies the effect without being misleading.

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 compact sentences convey the purpose and the visual context without waste. Every clause adds meaningful 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 simple setter with only two self-explanatory parameters and no output schema, the description is sufficient. It tells the agent the effect and where the title appears. Minor gaps like whether it overwrites an existing title are not essential for basic usage.

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. It does not explain session_token or title, relying solely on their names. The description adds no value beyond the schema's field names, leaving a gap for a critical token 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 clearly states the action ('Name this session's conversation thread') and specifies the resource and context ('on the human's phone', 'thread title in the app'). This distinguishes it from sibling tools like call or text, which handle communication rather than session naming.

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 it (when you want to label the current session with a project or task). It doesn't explicitly state when not to use it or mention alternatives, but the sibling tools are clearly different in function, so the context is clear.

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 annotations, it discloses that the message is one-way with no ring, that the hosted server cannot read the local config file, and that session_token maintains the same thread. These are meaningful behavioral details not captured by 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?

Three dense sentences, each providing necessary information: the core action, the configuration nuance, and threading. No filler or redundant content.

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 essential operational details including environment-specific behavior and threading. It does not mention the return value or possible failure modes, but for a simple one-way send this is a minor gap.

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 explains `to` in detail and `session_token` as a thread-continuation mechanism. `body` and `from_label` are left to inference, but their names are largely self-explanatory.

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 sends a one-way text to the human's phone, specifying push notification and no ring. This distinguishes it from sibling tools like call and wait_for_reply without ambiguity.

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 practical guidance on how `to` is obtained, including the local-vs-hosted configuration difference, and how session continuity works. It implies this tool is for asynchronous, one-way messaging, but does not explicitly say when to choose it over 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 readOnlyHint=true and destructiveHint=false, but the description adds significant behavioral context: long-polling up to wait_s (max 30s), the return shape {events, cursor}, the need to pass the cursor for delta reads, and the meaning of an empty events list. This goes well beyond the annotations and gives the agent a clear mental model of the tool's runtime 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 compact yet information-dense. It front-loads the purpose, then delivers the essential mechanics (long-poll, return shape, cursor, empty list behavior) in two sentences. Every phrase adds value with no filler 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?

Given the tool's simplicity, the description covers all key aspects: what it waits for, the polling timeout, the return structure, and the cursor-based pagination. There is no output schema, so the description's explanation of {events, cursor} is essential and complete. No major behavioral edge cases are ignored for this use case.

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 explain parameters. It does explain cursor ('Pass the returned cursor next time') and wait_s ('Long-polls up to wait_s (max 30s)'). Session_token is not explicitly described, but its name and the 'session' context make its role obvious. The description compensates well for the schema's lack of parameter documentation, though it could have been more explicit about session_token.

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 immediately states the tool's purpose: 'Wait for the human to send something back to this session.' It specifies the resource (human replies), the verb (wait), and the content (texts and voicemail transcripts). This clearly distinguishes it from siblings like 'text' (sending) and 'call' (initiating a 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 provides clear context on when to use this tool: after sending something, to wait for a reply. It explains the polling pattern ('poll again if you are still waiting') and the cursor usage. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of a full 5.

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