Call Me

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

Annotations (destructiveHint=true, openWorldHint=true, readOnlyHint=false) indicate a side-effecting action, and the description adds rich context beyond that: ~30s wait, ringing status requiring polling, config file path and local-vs-hosted divergence, setup_required return with App Store link, and session_token thread persistence. No contradiction with annotations — this far exceeds the lowered bar.

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?

Six dense sentences, each earning its place: core action first, then timing, follow-up protocol, config handling, setup path, and threading. No filler or repetition of schema fields.

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 complex, side-effecting tool with no output schema, the description covers the full call lifecycle: initiation, timeout, polling follow-up, setup failure mode, and session continuity. It names two return statuses but does not enumerate the complete status set or full response envelope, which would make it fully complete.

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

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

With 0% schema description coverage, the description carries the burden and covers three of four parameters: `to` (config source, local vs hosted, Call Me number, missing-value behavior), `question` (spoken aloud), and `session_token` (keeps same phone thread). Only `from_label` is left undocumented, and its default makes it 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 opens with a specific verb chain — "Ring the human's iPhone, speak the question aloud, and return what they say" — identifying the exact action, resource, and result. It also clarifies it is a Call Me app number rather than a regular phone number, and the follow-up mention of poll_result distinguishes the call flow from its siblings.

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

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

Explicitly instructs when to follow up: "if the result comes back status 'ringing', follow up with poll_result." It also gives environment-specific guidance (local client reads config, hosted server cannot) and the setup_required fallback path. It does not contrast against text/wait_for_reply or state when not to call, so it stops short of a 5.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the behavioral detail that this tool returns instructions and a link rather than performing an external action. This gives a complete, accurate picture of side-effect-free 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?

A single sentence that front-loads the action and output, then provides the usage condition. Every word earns its place; there is no redundancy or filler.

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

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

With no parameters, no output schema, and read-only annotations, the description fully covers what the tool does, what it returns, and when to invoke it. Nothing necessary for correct invocation 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 tool has zero parameters, so the baseline is 4. The description confirms that no parameter input is needed and that the 'no number' condition is a contextual state rather than an argument.

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

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

The description states a specific verb ('Return'), a concrete resource ('first-setup instructions and a clickable App Store download link'), and the triggering condition ('when no number is available'). This clearly distinguishes it from sibling tools like call or text, which would require a number.

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 explicitly states when to use the tool: when no number is available. It does not explicitly name the alternatives to use when a number is available, but the condition is clear enough for an agent to choose between setup and the calling/messaging 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?

The description adds substantial behavior beyond the annotations: it reveals the push-notification nature, the config-file dependency, the setup_required return condition with App Store link, and the threading behavior via session_token. Annotations already indicate a mutating external action, and the description enriches this without contradicting it.

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 three sentences with no filler. The core behavior is front-loaded, and the setup caveat and session guidance follow naturally. Every sentence adds operational 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 tool with no output schema and relatively simple parameters, the description covers the critical operational concerns: local vs hosted behavior, failure mode with setup_required, and session threading. It does not describe the success response format, but that is a minor gap given the annotated open-world destructive nature and the absence of an output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the meaning of `to` (from config.json) and `session_token` (thread continuity), but it does not explain `from_label` and only implicitly covers `body`. This is partial compensation, not full.

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: 'Send a one-way text to the human's phone'. It also distinguishes this from sibling tools by noting it is a push notification with 'no ring', which separates it from `call` and implies it is not a reply-waiting operation like `wait_for_reply`.

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

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

The description gives clear context on when to use the tool: for one-way phone notification. It also explains the local-client vs hosted-server distinction and warns that the hosted server cannot read the config file. It does not explicitly enumerate sibling exclusions, but the 'one-way' framing and setup guidance are enough to route an agent 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?

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.