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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by disclosing that the tool navigates to the Calls tab and scrapes the visible call list, including the limitation that only visible entries are returned. This is useful beyond what annotations convey.

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, front-loaded with the core purpose, and every sentence earns its place. The Args section is redundant with the schema but harmless, and the Returns section is valuable because there is no separate output schema. The layout is clear and scannable.

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 is complete: it states what is scraped, what data each entry includes, the max_calls limit, and the full return shape including the call_type enum. Since there is no output schema, documenting the return contract here is essential and done well.

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 coverage is 100% and the single max_calls parameter is fully described in the schema. The description repeats the default and bound information, reinforcing it but not adding meaning beyond the schema. The baseline of 3 applies because the schema carries the semantic weight.

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 and resource: 'Read recent call history from Phone Link's Calls tab.' It clearly distinguishes itself from sibling tools like phonelink_get_messages or phonelink_get_photos by naming the Calls tab and the data domain. Further detail about call types and display text reinforces exactly what is returned.

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 makes the usage context clear: use this tool when call history is needed. It does not explicitly name alternatives or state when not to use it, but the sibling list and the focused phrasing provide enough context for an agent to select it appropriately.

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 non-destructive, and the description adds meaningful behavior beyond that: the dual-mode behavior, the fact that navigate_to_tab will click the Messages tab first, and the return shape for each mode. It also warns that the contact name must match the UI exactly, which is valuable 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 well-structured with a purpose line, two modes, Args, per-mode return shapes, and Tips. Each section serves a clear function, and the front-loaded purpose sentence immediately tells the agent what the tool does. The length is justified by the dual-mode complexity.

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 provides return shapes for both modes, which matters because there is no output schema, and it gives practical lookup tips. However, the return shapes use '...' placeholders and the description does not cover failure cases such as a conversation name not being found or Phone Link not being connected, so it is strong but not 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?

Schema coverage is 100%, so the baseline is 3. The description adds a few genuinely useful nuances beyond the schema: the contact name must match what is displayed in the Phone Link UI, and max_messages applies to either conversations or messages depending on the mode. Most of the Args section repeats schema details, so it does not deserve a 5.

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 'Read SMS messages from Phone Link's Messages tab', a specific verb, resource, and UI location. It also defines two distinct modes, listing conversations vs reading a specific conversation, which clearly separates it from sibling tools like phonelink_get_calls or phonelink_get_photos.

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 mode-level guidance: leave conversation_name empty to list conversations, provide a contact name to read that conversation, and 'Use list mode first to discover available conversations.' It does not explicitly compare this tool to sibling tools or state when not to use it, so it falls just short of full marks.

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 this as read-only and non-destructive. The description adds meaningful behavioral detail: it navigates to the Notifications section and scrapes visible entries, implying the result set is limited to UI-visible mirrored notifications. It does not mention connectivity prerequisites or loading behavior, but the safety profile is already covered.

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?

Well-structured and front-loaded: purpose first, then mechanism, a single use-case sentence, and an Args/Returns breakdown. The Args section is redundant with the schema, and the return example's '...' is vague, but overall it remains compact and scannable.

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?

This is a low-complexity read tool with no required parameters and read-only annotations. The return-shape sketch partially compensates for the missing output schema. It does not fully specify the notification fields beyond text and control_type, but it provides enough for an agent to understand the tool's output at a general level.

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 parameter max_notifications is fully documented in the input schema with default, minimum, and maximum. The description's Args section merely restates those constraints without adding new meaning, so the baseline 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 opens with 'Read phone notifications from Phone Link's Notifications panel' — a specific verb, resource, and UI location. It clearly distinguishes this tool from siblings like phonelink_get_messages, phonelink_get_calls, and phonelink_get_photos by focusing on notification entries.

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?

States concrete use cases: 'checking app notifications, system alerts, and other phone notifications mirrored to PC.' This gives an agent clear context for when to call it, though it doesn't explicitly name sibling tools or state when not to use it.

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 readOnlyHint and destructiveHint annotations, the description discloses meaningful behavior: it navigates the UI, scrapes the visible grid, and returns only visible metadata. The explicit no-download clarification is valuable and prevents false expectations. No contradiction with the annotations was found.

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 well-structured and front-loaded: a one-sentence purpose, a behavior note, a useful caveat, and compact Args/Returns sections. It avoids unnecessary fluff, though it does repeat parameter information already present in the schema and restates return information slightly.

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-complexity tool with one optional parameter and no output schema, the description provides the key invocation and return-shape details: max_photos bounds, photo_count, photos array, name, and bounds. It could be slightly more complete by elaborating on the 'type' field or potential failure modes when Phone Link is not connected, but nothing essential to calling the tool 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 input schema already describes max_photos fully with minimum, maximum, default, and a descriptive sentence. The description's Args section repeats the same information without adding new semantic context such as edge cases, performance implications, or how max_photos interacts with the visible grid. With 100% schema coverage, the baseline of 3 is appropriate.

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, resource, and scope: 'List recent photos from Phone Link's Photos tab.' It further clarifies the tool's exact behavior with 'Navigates to the Photos tab and scrapes the visible photo grid' and explicitly distinguishes itself from a downloader with 'This does NOT download photos.' This makes it easy to differentiate from sibling getters like phonelink_get_messages and phonelink_get_calls.

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 how the tool works and what it is limited to: it scrapes the visible photo grid and lists only visible entries. The 'does NOT download photos' note is an explicit non-usage signal. However, it never names alternatives or states a direct decision rule such as 'use this when you only need metadata' versus another tool for downloading.

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 readOnly, idempotent, and non-destructive behavior, and the description adds concrete context: the exact boolean fields returned and the specific failure mode (connected=false when Phone Link is not running). This goes beyond the annotations to set accurate expectations.

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 front-loaded with purpose and usage, then organized into a return block and error handling section. Every sentence earns its place, with no filler or redundant explanation.

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 present, the description fully documents the return payload and failure behavior. It also covers prerequisites, fallback action, and what to expect, making the tool completely self-contained for an agent to call 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 input schema has zero parameters and the description confirms 'No parameters required.' With no parameters to elaborate, the baseline of 4 is appropriate; the description doesn't need to add extra parameter detail.

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 'Get' and resource 'connection status of Phone Link (MyPhone) and basic phone info', clearly differentiating it from sibling tools like phonelink_get_photos and phonelink_get_messages. The scope is explicit and leaves no ambiguity about what this tool returns.

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 to use this as the first tool call to verify Phone Link availability before using other tools. It also names phonelink_launch_app as the alternative when the app isn't running, giving clear when-to-use and fallback guidance.

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=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. It adds useful behavioral context beyond the annotations: it is a diagnostic dump, the depth parameter trades completeness for speed ('Higher = more elements but slower'), and it returns a JSON structure. This is sufficient for a non-destructive inspection tool.

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 well-structured with a one-line summary, a use-case paragraph, and clearly separated Args/Returns sections. It is slightly longer than necessary because the Args and Returns sections echo schema and output details, but each part is organized and front-loaded with the core purpose. No filler content is present.

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, the description provides a return type sketch with element_count, window_name, and elements fields, plus parameter bounds and defaults. It gives an agent everything needed to call the tool correctly, understand what it returns, and decide when it is appropriate, especially with the annotations covering the read-only/idempotent nature.

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%, so the schema already documents both parameters thoroughly. The description's Args section mostly repeats the schema (max_depth, filter_control_type) with only a minor addition about depth affecting speed. This matches the baseline of 3 for high schema coverage; the description adds little new parameter meaning.

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 and resource: 'dumps the Phone Link UI automation tree as JSON'. It also explains the tool is a debug tool for discovering UI element names, automation IDs, control types, and bounding rectangles, which clearly distinguishes it from the data-retrieval and action siblings like phonelink_get_messages and phonelink_send_message.

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: 'Use this to discover UI element names, automation IDs, control types, and bounding rectangles' and frames it as 'Helpful for troubleshooting when other tools can't find expected elements.' This provides clear context, though it does not explicitly name alternatives or state when not to use it.

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 (idempotentHint=true, destructiveHint=false), the description discloses the protocol handler used ('ms-phone:'), the timing behavior ('wait a few seconds'), and the return shape. These add valuable context for an agent deciding whether and how to call 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 compact and front-loaded, stating the main action first, then mechanism, timing advice, and return format. Every sentence earns its place and there is no redundant phrasing.

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 zero-parameter launcher with no output schema, the description covers the action, the underlying mechanism, the wait-before-other-tools caveat, and the response structure. Nothing an agent needs to invoke 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 tool has zero parameters and the schema description explicitly states 'No parameters required,' giving 100% coverage. With 0 params, the baseline is 4; the description adds no unnecessary parameter detail, and none is needed.

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: 'Launches the Phone Link app if not already running.' This clearly distinguishes it from sibling tools, which are getters or messaging actions. The title and description align 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 gives sequencing guidance: 'Wait a few seconds after calling this before using other tools,' which implies this should be called before other Phone Link tools. It does not explicitly name alternatives or state when not to use it, but the launch is a clear prerequisite for the sibling operations and the 'if not already running' condition provides 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?

The description goes well beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The explicit '⚠️ WARNING: This initiates a REAL phone call. Verify the number before calling.' discloses a real-world side effect with irreversible social consequences — exactly the kind of behavioral context annotations cannot express. It also reveals the step-by-step UI manipulation and the dependency on a connected phone.

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 well-organized with a front-loaded purpose, then mechanism, then a prominently placed warning, plus an explicit Returns block. The Args section is mildly redundant with the schema, but the Returns block earns its place since no output schema exists. Minor redundancy keeps 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 single-parameter tool, this is nearly complete: it provides the return shape ({ initiated, phone_number }) compensating for the missing output schema, discloses the real-call risk, and explains the internal steps. Remaining gaps are failure/edge behavior — what happens if the phone is disconnected, the number is invalid, or the call is declined — and any prerequisites for the phone link being active.

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% — the schema already documents phone_number as 'The phone number to call (with country code if needed).' The description's Args section largely duplicates this, adding no new format, validation, or edge-case semantics. Per the rubric, baseline 3 applies when the schema does the heavy lifting, and that is the case here.

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 opening line 'Initiate a phone call through Phone Link's dial pad' states a specific verb and resource, and the mechanism ('Opens the Calls tab, enters the phone number, and clicks the call button') makes the action unambiguous. It clearly distinguishes itself from sibling get_* tools (read-only), phonelink_send_message (texting), and phonelink_launch_app (app launching) — it is the only tool that places a real 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?

Usage is implied rather than stated: the description clarifies this triggers a real call from the connected phone, so an agent can infer when it applies and that it is not a simulation. However, there is no explicit when-to-use/when-not-to-use guidance, no named alternative (e.g., 'use phonelink_send_message to send a text instead'), and no prerequisites such as requiring the phone to be linked and online.

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, the description discloses that this 'sends a REAL SMS' — a real-world side effect that annotations alone do not convey — and that it operates by driving the Phone Link UI through clicks. It also specifies failure behavior ('Returns sent=false with error message if any UI element can't be found') and lists concrete failure modes. Nothing contradicts readOnlyHint=false, openWorldHint=true, idempotentHint=false, or destructiveHint=false.

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 front-loaded with the core purpose and organized into labeled sections (Args, Returns, Warning, Error Handling), making it easy for an agent to scan. It runs longer than the minimum, but the real-SMS warning and failure-mode list carry critical safety and recovery information that earns their 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?

With no output schema present, the description correctly specifies the return shape ({sent, recipient, message}). It covers purpose, mechanism, parameters, return format, real-world risk, and failure recovery — everything needed to invoke a 2-parameter side-effectful tool safely.

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%, so the schema already fully documents both parameters. The description's Args section largely restates the schema ('Contact name or phone number', max 1600 chars) without adding new semantic meaning, so the baseline 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?

The opening line, 'Send an SMS message through Phone Link's UI,' provides a specific verb and resource, and the next sentence ('Opens a new message, types the recipient and message text, and clicks Send') makes the mechanism unambiguous. The purpose is self-evidently distinct from the sibling get_* tools, phonelink_make_call, and phonelink_launch_app even without naming them.

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 a real SMS must be sent from the phone — but never explicitly contrasts it with phonelink_make_call (voice) or the read-only get_* tools. The error-handling notes (phone not connected, Messages tab not loading) give situational context about when it may fail, but explicit when-to-use/when-not-to-use guidance is absent.

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