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

With no annotations, the description carries the full burden, and it does disclose the single most surprising behavior: the call may return a response_id instead of an answer, meaning results can be deferred. It does not explain what triggers the async path, expected latency, or that a paused request may need cancelling, which leaves meaningful gaps for an un-annotated 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?

A single clause with zero filler, front-loading the action and then the two possible outcomes. Nothing could be removed without losing 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 two-parameter tool with a full output schema and documented parameters, the description covers what it does and the one non-obvious outcome. The only missing piece, naming the polling sibling, belongs to usage guidance rather than making the definition incomplete.

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%; conversation_id already documents how to continue a thread. The description adds no syntax, format, or constraint detail beyond the schema, 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?

States a specific verb and resource ("Ask Marvin a question") and adds the distinctive dual return mode. It does not name or distinguish itself from siblings like get_response or list_conversations, so the agent must infer the relationship, but the core purpose is unambiguous.

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 "or a response_id to poll" implies a follow-up step exists but never names get_response as the tool to poll with, nor mentions cancel_response. Usage is implied rather than instructed, leaving the agent to guess the async workflow from sibling names alone.

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 doesn't say whether cancellation is idempotent, whether the response_id becomes invalid afterward, whether partial output is retained, what error surfaces for an unknown or completed id, or what permissions are needed — all material for a mutation tool with zero annotation coverage.

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?

One short, front-loaded sentence with no filler, and the key constraint (still running) is placed where it will be read. It is efficient rather than padded, though the brevity borders on under-specification.

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?

An output schema exists, so return values needn't be explained, but for a state-changing cancel operation with no annotations the description should cover post-cancellation state and failure modes. As written, an agent knows what the tool intends but not what to expect from it.

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 parameter is already documented as the response_id returned by ask_marvin. The description adds no extra meaning about the identifier beyond what the schema states, 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?

States a specific verb ("Stop") applied to a specific resource ("an answer that is still running"), which an agent can distinguish from the read-oriented siblings like get_response and ask_marvin. It stops short of naming the response_id linkage explicitly, but the intent is unmistakable.

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 "still running" implies the precondition for calling it, so usage is inferable. However, no guidance is given on what to do if the response already finished, whether the call is safe to repeat, or which sibling to use instead to merely read status.

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, and it discloses only ordering (oldest first). It says nothing about pagination behavior despite cursor/limit parameters, nothing about permissions or scoping, and nothing about whether the conversation must exist or what happens with an invalid id.

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 short fragment with zero wasted words, which is efficient, but the terseness crosses into under-specification rather than crisp front-loading. There is no structure to separate purpose from behavior because there is essentially only one clause.

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?

An output schema exists, so return values need not be described, and the tool is simple with three well-documented parameters. However, with no annotations and a one-line description, the agent still lacks guidance on when to call this versus its siblings and how paging behaves in practice.

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 schema itself explains limit, cursor, and that conversation_id comes from list_conversations or an earlier answer. The description adds no parameter meaning beyond that, 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 fragment 'A conversation's questions and answers' identifies the resource and implies a read, but there is no verb and no explicit differentiation from siblings like get_response or list_conversations. An agent can guess it returns transcript turns, but must infer that from the noun phrase rather than a stated 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?

The description gives no when-to-use guidance at all: it does not say when this is preferable to list_conversations (discovery) or get_response (a single answer). The only usage-adjacent detail is 'oldest first', which describes ordering, not tool selection.

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 at all, the description carries the full behavioral burden and falls short. It does not say whether the call blocks, how long it waits, what happens on timeout, whether repeated calls are safe, or whether partial results are returned — the key facts an agent needs for an async wait 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?

One short sentence with no filler, appropriately sized for a single-parameter tool. The vague 'a little longer' is an imprecision problem rather than a length problem.

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?

An output schema exists so return values need no explanation, but for a polling/waiting tool the description should cover blocking behavior, timeout handling, and expected retry pattern. Those omissions are material given complexity and zero annotation coverage.

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 response_id parameter is documented as 'the response_id ask_marvin returned.' The description adds nothing beyond that provenance, 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 description conveys that this retrieves the answer of an ask_marvin request that is still running, which ties it to a named sibling. But it never states a concrete verb-resource pair ('get the response/result') and 'wait a little longer' leaves the actual operation ambiguous — it could be a blocking wait, a poll, or a status check.

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?

Use is implied: call this after ask_marvin hands back a run that is not finished. There is no explicit when-to-use/when-not guidance, no mention of cancel_response as the abandoning alternative, and no indication of how many times to poll or whether to stop.

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 usefully discloses result ordering and that app-created conversations are included, but says nothing about read-only safety, permissions, whether results are paginated (only implied by the cursor param), or any limits on history depth.

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?

One short sentence with the resource and its ordering front-loaded and zero filler. Nothing in it is redundant or wasted.

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 read with an output schema and full schema coverage, the essentials (resource, ordering, app-inclusion scope) are present. The remaining gap is minimal: no hint about paging behavior or relationship to get_conversation.

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% — limit's 1-100 range and cursor's next_cursor semantics are fully documented in the schema. The description adds no additional meaning about either parameter, 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?

Names the specific resource (Marvin conversations) and states the ordering (most recently updated first) plus a scope nuance ('including ones from the app'). The list operation itself is only implied by the name; there is no explicit verb and no direct contrast with get_conversation or ask_marvin, 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?

No when-to-use or when-not-to-use guidance is given. An agent must infer from the name alone that this is for enumerating conversations while get_conversation fetches a single one, and nothing says whether to page through results or seed from this list before asking a follow-up.

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