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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about the result shape (boolean vs. status object), whether the check makes a network request that can fail or time out, or how a logged-out state is reported. It also never states that it is a side-effect-free read, which cannot be assumed given the sibling gv_login mutates session state.

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 zero filler. Nothing could be removed without losing meaning, and the purpose is stated first.

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 no annotations, the description should at minimum describe what the check returns so the agent can branch on it; that information is entirely absent. The tool is simple enough that an agent can still invoke it correctly, but interpreting the result is left to guesswork.

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 there is no parameter semantics to explain; the schema is trivially complete. Baseline 4 is appropriate for a zero-parameter tool.

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 ('Check') and a specific resource ('whether the user is currently logged into Google Voice'), so an agent knows exactly what question the tool answers. It does not explicitly distinguish itself from the sibling gv_login, which is the obvious point of confusion, keeping it from a 5.

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 call this versus gv_login, nor any stated prerequisite or typical workflow (e.g., check before SMS operations, call gv_login if false). Usage is only inferable from the tool name and purpose, not from the description.

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?

No annotations are supplied, so the description carries the full behavioral burden. It discloses the returned fields, which is useful, but says nothing about authentication prerequisites, ordering/recency definition, pagination beyond the limit, or whether the call has side effects (e.g., does listing mark anything read?).

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, front-loaded with the action and resource, followed by the return shape. 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?

For a zero-required-parameter read tool with no output schema, listing the returned fields covers the main gap. However, the presence of gv_login/gv_check_login siblings implies an auth prerequisite that the description never mentions, leaving a real operational 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 100%, with both limit and filter fully documented including the enum values and defaults, so the baseline of 3 applies. The description adds no parameter-level meaning beyond what the schema already provides.

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 ("List recent SMS conversations from Google Voice") plus the returned fields, so an agent knows this is the conversation-level listing tool rather than a message-body reader. It never names gv_read_sms or the other siblings, so differentiation is inferred rather than explicit.

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 only implied: "list recent conversations" plus "last message snippet" signals this is for scanning the inbox, not reading full threads. There is no explicit when-to-use, no routing to gv_read_sms for full content, and no mention that a prior gv_login/gv_check_login may be required.

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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: it spawns a local Chrome process with remote debugging, the human must connect via SSH tunnel and chrome://inspect, and 2FA is completed manually. It omits details an agent may need, such as which port is opened, whether the call blocks until login finishes, and the security implications of enabling remote debugging.

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, each earning its place: what is launched, how the user completes login, and the mandated follow-up call. The action is front-loaded 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 zero-parameter tool with no output schema, the description covers the essential mechanics and the handoff to gv_check_login. It is slightly incomplete in not indicating what the call returns or how the agent should wait for the human step to finish before verifying.

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 there is nothing for the description to disambiguate beyond what the empty schema already shows. Baseline for a parameterless tool 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 description names a specific action and resource: launching system Chrome with remote debugging specifically for Google login. It also distinguishes itself from the sibling gv_check_login by assigning that tool the verification role, so an agent can place this tool in the flow 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?

It states the use case (Google login, including 2FA) and the explicit next step: call gv_check_login afterward. It does not state when this tool should NOT be used or what to do if Chrome is already running with a debugging port, so it stops short of full routing 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?

No annotations are supplied, so the description carries the full disclosure burden for a state-changing operation. It does not say whether the change is idempotent, whether it requires an authenticated session, whether it applies per-conversation or globally, or what happens if the conversation ID is invalid or already read.

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 or redundancy. The action is stated first and nothing extraneous is included.

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 one-parameter tool with a fully documented schema, the definition is minimally sufficient to invoke correctly. But as an unannotated mutation tool it omits side effects, authentication expectations, and the relationship to gv_read_sms, leaving real gaps an agent would want covered.

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 single parameter is documented as 'The conversation ID to mark as read.' The description adds no format hints, sourcing guidance (where to obtain a conversation_id), or constraints, so it sits at the baseline for a fully documented 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 names a specific verb and resource: 'Mark an SMS conversation as read.' An agent can understand the action immediately. However, it does not distinguish this tool from the sibling gv_read_sms, which plausibly also touches read state, so the boundary between the two is left ambiguous.

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 call this versus gv_read_sms or gv_list_sms, no prerequisites (e.g., login state, conversation ownership), and no stated exclusions. The agent must infer the workflow context entirely.

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?

No annotations are supplied, so the description carries the behavioral burden. It does disclose the return shape (sender, text, timestamp, direction), which is valuable with no output schema, and 'Read' implies a non-mutating operation. It says nothing about pagination/ordering behavior beyond the schema's limit default, nor about permission or rate-limit constraints.

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 scope stated first, so it is well front-loaded and free of filler. The second sentence mildly restates 'Read messages' while adding the return-field detail, which is the only minor 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?

For a simple three-parameter read tool with fully documented schema and no output schema, the description covers what it does and what it returns. The remaining gaps — explicit differentiation from gv_list_sms and any pagination behavior — are small rather than blocking.

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 explains conversation_id provenance, limit semantics ('most recent', default 50), and the all/unread enum. The description adds no parameter-level detail beyond that, making the baseline 3 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 states a specific verb and resource — reading messages within a single SMS conversation — which is distinguishable from the sibling gv_list_sms (conversation listing) and gv_reply_sms/gv_send_sms (writes). It does not explicitly name those siblings, so it stops short of a 5.

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 only implied: the phrase 'within a specific SMS conversation' signals this is the per-conversation read, and the schema notes conversation_id comes from gv_list_sms results. There is no explicit when-to-use statement, no exclusions, and no routing advice against gv_list_sms or gv_mark_read.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a write/send operation but does not disclose side effects, authentication requirements, whether the conversation must already exist, error behavior, or whether the reply affects read state.

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. It is concise, though the brevity leaves important behavioral context unstated.

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 no annotations and no output schema, the description is too sparse. It identifies the action but omits important context such as required conversation state, side effects, failure modes, and how the reply behaves relative to existing messages.

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 input schema already documents both parameters. The description adds no meaning beyond confirming that the tool replies within a conversation, so 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 uses a specific verb and resource: 'Reply to an existing SMS conversation.' This clearly identifies the action and scope, though it does not explicitly distinguish the tool from sibling gv_send_sms beyond the implication of replying within an existing thread.

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 phrase 'existing SMS conversation' implies the tool should be used for threaded replies rather than new outbound messages, but it does not explicitly say when to use this instead of gv_send_sms or what prerequisites apply. Usage 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?

No annotations are supplied, so the description carries the full burden, yet it discloses no behavioral traits beyond the bare action. It does not say whether side effects are immediate and irreversible, what happens if one of several recipients fails, whether rate limits or per-message costs apply, or what result is returned.

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?

It is a single well-formed sentence with the action and channel front-loaded and no wasted words. It is efficient, though its brevity is partly the source of the disclosure gaps rather than a virtue of tight editing.

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 two-parameter tool with a fully described schema and no output schema, the core action is adequately covered. However, with zero annotations the definition should at least note the authentication prerequisite and the outcome of a multi-recipient send to be 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 100%, so both parameters are already documented with types and an example. The phrase "one or more phone numbers" usefully reinforces the multi-recipient semantics of the oneOf schema but adds no format or validation detail beyond it.

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 and resource ("Send a new SMS message") plus the delivery channel ("Google Voice") and the recipient scope ("one or more phone numbers"). The word "new" implicitly separates it from gv_reply_sms, but no sibling is named explicitly.

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 when-to-use guidance: nothing states that this is for starting a conversation rather than continuing one (gv_reply_sms), and no prerequisite such as authenticating via gv_login/gv_check_login is mentioned. Usage is only weakly inferable from the word "new".

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