Cleat

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

No annotations are provided, so the description carries the behavioral burden. It does disclose the empty-result case ('or nothing if none has arrived'), which is genuine value beyond the schema, but it says nothing about read-only nature, permissions, or cost/latency of the lookup.

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 that defines the resource, its recency scope, and the null case with no wasted words.

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, no-output-schema read tool, the description covers what is returned and what happens when nothing exists. The only gap is the relationship to the wait_for_code sibling, which an agent must infer.

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 (lineId) is already documented in the schema, including its provenance from list_lines. The description adds no parameter-level meaning, so 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?

States a specific resource and scope: the most recent verification code for a line, with the empty-state behavior spelled out. An agent can distinguish it from list_messages or list_lines, though the boundary with wait_for_code is not made 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 — 'most recent' hints this is a snapshot read rather than a blocking wait, which is the key distinction from the sibling wait_for_code, but that alternative is never named or contrasted. No when-not-to-use 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 provided, so the description carries the disclosure burden alone. It does add one genuine behavioral fact — results are ordered newest first — but says nothing about pagination, result limits, or whether historical/disabled numbers are included.

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 short sentence with the resource and ordering front-loaded and no filler. It is appropriately sized for a zero-parameter list tool.

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 must carry the full contract, and it only partially does. It states what a line is and the ordering, but omits return-volume expectations and whether the list is exhaustive or paginated.

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 and the schema is 100% covered, so there is nothing for the description to clarify. Baseline 4 applies since no parameter semantics are 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 names the resource specifically (phone numbers in this workspace that can receive texts) and resolves the ambiguous term 'lines' from the tool name. It clearly identifies the returned entity and excludes other sibling domains like messages or codes, though it is phrased as a noun fragment rather than an action.

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 alternatives, and no prerequisites or exclusions are stated. With siblings like list_messages and latest_code, a brief 'use this to discover which numbers can receive texts' would have removed ambiguity.

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 behavioral burden, and it does disclose two useful traits: only received (inbound) texts are returned, and results are ordered newest first. It does not cover pagination or the read-only nature, so the coverage is partial rather than rich.

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 tight sentence with no filler, and the scoping constraint plus ordering are front-loaded. It is efficient, though its brevity is close to the point of under-specification rather than maximal helpfulness.

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 list tool with fully documented parameters, the definition is adequate. However, with no annotations and no output schema, an agent gets no signal about the return shape or pagination behavior, leaving a modest 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%, so both lineId and limit are already documented in the schema. The description reinforces that the query is scoped to one line but adds no format, range, or default details beyond what the schema states.

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?

"Texts received by one line, newest first" names the resource (messages/texts), the scoping dimension (a single line), and the sort order. It is clearly distinguishable from siblings like latest_code (a single code) and list_lines (the lines themselves), though it never names an alternative 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?

No when-to-use or when-not-to-use guidance is given. The phrase "by one line" implies the tool is scoped to a single line, but there is no statement of prerequisites or of how this differs from reaching for latest_code or wait_for_code.

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 must carry the behavioral load, and it does disclose the two most important traits: the tool blocks and may return timedOut: true when nothing arrives. It does not say whether the returned code is consumed/drained from the line or how errors (e.g., an unknown lineId) manifest, leaving some behavioral ambiguity.

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, front-loaded with the core action, then the ordering rule, then the failure signal. Every sentence earns its place with no 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 two-parameter polling tool with no output schema and no annotations, the description adequately covers what comes back (the code, or timedOut: true) and how to sequence the call. It omits edge-case behavior such as repeated codes or error handling, which keeps it from being 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 description coverage is 100%, with lineId and timeoutSeconds both documented in the schema (including the 55s cap and 30s default), so the baseline is 3. The description adds only the indirect notion of a line and a timeout window, no new format or constraint detail 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?

States a specific verb and resource: it waits for the next verification code on a line and returns it. The blocking 'next code to arrive' framing implicitly separates it from latest_code, but the sibling is never named explicitly, which a 5 would require.

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?

Gives an explicit operational rule: 'Call this immediately BEFORE triggering the text, so nothing is missed,' which is genuinely actionable sequencing guidance. It does not, however, mention when to prefer latest_code instead or what to do after a timeout, so it stops short of full when/when-not coverage.

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