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

With no annotations, the description must carry behavioral weight; it discloses that the operation is offline and read/compute-oriented (word counting), which suggests no mutation. It does not, however, describe output structure, error behavior, or file expectations beyond calling the file 'saved notes'.

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; the 'Offline' qualifier and the specific section pattern are immediately visible. Every word contributes.

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 this is near-sufficient: an agent can infer that calling it with a notes file path yields per-section word counts. Still, the absence of an output schema and any mention of return format or failure modes leaves a moderate 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 coverage is 0% and the only property is 'path'. The description compensates partially by indicating the path points to a saved notes file containing `### BÖLÜM n` sections, but it omits path conventions such as relative vs absolute paths or accepted file formats.

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 states a specific behavior: counting words per `### BÖLÜM n` section of a saved notes file, offline. This is a concrete verb+resource combination and clearly separates it from the chat-oriented sibling tools.

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 'Offline' prefix implies the tool is appropriate when a local, network-free word count is needed, but it does not explicitly state when to prefer it over alternatives or provide any exclusions. Usage context 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?

With no annotations provided, the description carries the full behavioral burden. It discloses the key non-destructive behavior: the conversation remains in ChatGPT after the tab is closed. This gives the agent useful safety-relevant context beyond the bare action name.

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 filler. Every part contributes meaning, and the clarifying parenthetical adds important behavioral information without bloating the text.

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 close action with no output schema, the description is mostly complete: it states the action and its main side effect. The only notable gap is that the 'chat' parameter is left underspecified, but the tool's simplicity limits the impact.

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 the undocumented 'chat' parameter, but it does not. The parameter is only named, with no explanation of what format the chat identifier takes or where it comes from.

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 a specific verb and resource: it closes the browser tab of a chat. The parenthetical 'the conversation stays in ChatGPT' distinguishes this from ending or deleting a chat, and the action is clearly distinct from sibling tools like open_chat and new_chat.

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 this tool should be used: when the agent wants to close the tab while preserving the conversation. However, it does not explicitly say when not to use it or mention alternatives such as stop or open_chat.

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. It usefully discloses what the health check covers by listing the five checks. But it does not state whether the tool has side effects, what it returns, or how it behaves when a check fails. The diagnostic intent is clear, but some behavioral detail is missing.

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 one compact sentence with a front-loaded purpose, a clear list of checks, and a direct usage instruction. Every word earns its place and there is 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 zero-parameter diagnostic tool, the description covers what it checks and when to use it. The lack of an output schema is not fully compensated by the description, since the return shape is not stated, but the essential invocation context is present.

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 parameter semantics are trivially satisfied. The description does not need to explain parameters, and the empty schema is fully consistent with that.

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 identifies a health-check tool with a specific scope: CDP reachability, session state, file input, model names, and project existence. This is much more specific than a generic status check, but it does not explicitly distinguish itself from the sibling 'status' tool.

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 an explicit usage trigger: 'Use when something fails.' This is useful contextual guidance. However, it does not mention when not to use it or how it differs from alternatives like 'status' or 'check_file'.

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 of behavioral disclosure. It usefully discloses that the tool is non-blocking and explains index semantics and reply_format options. However, it does not describe behavior when no reply is available, whether chat refers to the active chat, or what happens with invalid indices or formats.

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 extremely compact: one action sentence followed by two terse parameter explanations. Every sentence earns its place, and the core purpose is front-loaded.

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 tool with no annotations and no output schema, the description is reasonably complete but still leaves gaps. It covers non-blocking behavior, index semantics, and output format selection, but does not define what chat should be, what happens when no reply exists, or the shape of the returned data.

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 clearly explains index ('-1 is the newest') and enumerates reply_format values, which adds meaning beyond the bare schema. The required chat parameter is left undefined, though its name suggests a chat identifier.

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 ('Read') and a clear resource ('assistant reply'), and the phrase 'without waiting' immediately distinguishes it from a blocking sibling like wait. However, it does not explicitly name or contrast with alternative sibling tools, so it stops just short of full differentiation.

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 'without waiting' gives a clear usage context: use this when you want to fetch a reply without blocking. It does not explicitly state when not to use it or mention alternatives like wait or save_reply, but the implied guidance is strong enough for an agent to decide.

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. It discloses scope (configured project), result fields (title + url), and filter behavior (optional substring on title), but it does not mention ordering, limit/pagination behavior, error conditions such as a missing project configuration, or explicitly confirm that listing has no side effects.

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 two short sentences with no filler. The action and project scope are front-loaded, the output shape is compactly parenthesized, and the filter detail is a separate clear sentence.

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 list operation with no required parameters and no output schema, the description provides enough to invoke and interpret results: scope, result fields, and filtering. Minor gaps around limit behavior and ordering keep it from a perfect score.

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 adds meaningful semantics for 'query' by explaining it as an optional substring filter on title, but 'limit' is left to its self-evident name and schema default rather than being explicitly described.

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 ('List') and resource ('conversations inside the configured ChatGPT project'), and specifies the output shape ('title + url') plus optional substring filtering. This makes the tool's purpose unambiguous and distinguishes it from siblings like open_chat, new_chat, and send.

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 establishes clear context: this tool enumerates existing conversations within the configured project and supports a title substring filter. It does not explicitly name alternatives or exclusions, but the list-only role among the sibling tools makes when-to-use reasonably inferable.

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 behavioral disclosure. It does add a useful non-obvious behavior: the handle is temporary until first send, after which a permanent chat_url is obtained. However, it does not mention prerequisites, side effects, or whether creating a new chat affects an existing active chat.

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: the main action appears in the first sentence, while the return-handle lifecycle is provided in the second. Every sentence adds useful information without unnecessary elaboration.

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 one optional parameter and no output schema, the description covers the core purpose and a key lifecycle detail. However, it leaves title_hint unexplained, does not clarify what 'configured project' and 'configured model' depend on, and lacks guidance about sending or managing the created chat. It is minimally viable but not 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?

The schema has one optional parameter, title_hint, with 0% schema description coverage. The description does not mention title_hint at all, so the agent gets no guidance on its purpose, format, or behavior. The schema only reveals it is a nullable string, which is insufficient.

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: 'Open a new conversation inside the configured project and select the configured model.' It clearly identifies this as creating a new chat rather than opening an existing one, which distinguishes it from siblings like open_chat and list_chats.

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 that this tool is for starting a new conversation, and the 'new' qualifier implies when to use it versus alternatives. It does not explicitly name sibling tools or state exclusions, but the intended usage is evident enough for an agent to select it 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?

No annotations are provided, so the description carries the full burden. It discloses the return values (turn counts and preview of last reply), which is helpful, but it does not explicitly state whether opening a chat changes the active session or affects subsequent send/get_reply calls. That side effect is implied but not stated.

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 two sentences with no redundant words. The core action and URL format are front-loaded, followed by return-value details. Every sentence 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 single-parameter tool with no output schema or annotations, the description covers invocation and expected return values well. The only meaningful gap is the lack of explicit disclosure about session-state side effects, which is relevant in the context of sibling tools like send and get_reply.

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 the bare 'chat_url' property. It does by specifying the expected URL format with an explicit example (https://chatgpt.com/c/...), giving the agent enough to construct a valid parameter value.

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: 'Open an existing conversation by URL' and connects it to a clear purpose ('so you can continue it'). It distinguishes itself from siblings like new_chat and close_chat by stating it targets existing conversations by URL, and even mentions what it 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?

The description clearly implies when to use this tool: when you have a URL for an existing conversation and want to continue it. It does not explicitly list exclusions or name alternatives, but the context is sufficiently clear given sibling tools like new_chat and list_chats.

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. It does disclose useful behavior: the largest_markdown extraction rule, fallback to full text, and return of word/section stats. However, it does not say whether an existing file is overwritten or truncated, what happens on invalid paths, or how index affects the saved reply, leaving key side effects of a write operation unstated.

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: the main verb and resource appear first, then the format option, then the return value. Every sentence carries distinct information and there is no 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 four parameters, no output schema, and no annotations, an agent still lacks enough context to call this safely: index semantics and overwrite behavior are absent, and the return stats are only vaguely described as 'word/section stats'. The description is not complete for the complexity of the tool.

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 prose must explain all four parameters. It explains reply_format's values, and path is inferable from 'file under the work dir', but chat is never defined and index's role and default of -1 are not explained at all. This is a meaningful gap for an agent deciding what to pass.

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 object: 'Write a reply to a file under the work dir' and adds detail about the save format. This differentiates it from sibling tools like get_reply and check_file, which read or inspect rather than persist a 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?

It implies a use case ('without passing the whole text through the model' and extracting markdown locally) but never states when to choose save_reply over alternatives or when not to use it. There is no explicit comparison with get_reply, send, or check_file, so the guidance is only implied.

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 it provides useful behavioral detail: the call returns immediately with status=generating, wait_sec caps at 900, and reply_format accepts a specific set of values. It does not cover failures, permissions, or irreversibility, but the async and format behavior is materially disclosed.

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 front-load the core operation, then pack the important behavioral and format details without filler. The parenthetical file limit and reply_format shorthand are efficient and directly usable.

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 five-parameter send tool with no annotations and no output schema, it covers the main call behavior, the wait mechanism, and response format choices. It omits output shape and error behavior, but sibling tools like wait and get_reply, plus the returned status=generating note, partially fill that 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 coverage is 0%, so the description must compensate. It explains wait_sec's maximum, reply_format's allowed values, and the files count/scope constraint, but it does not clarify chat or text semantics such as identifiers, format, or length, leaving those to inference from required parameters.

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 concrete action—send a message to a chat—and adds specific scope: optional files under the work dir with a maximum of 10. This clearly positions it against sibling tools like open_chat, wait, and get_reply, which focus on other chat operations.

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 conveys the core usage context: sending a message and choosing whether to wait or return immediately via wait_sec. However, it never explicitly names alternatives such as wait or get_reply for retrieving a response, so routing to siblings depends on inference from their names.

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?

There are no annotations, so the description bears the full behavioral burden. It discloses that the call is cheap, that it should be first, and what state categories it reports. It does not explicitly say the operation is read-only, but the content list strongly implies inspection rather than mutation.

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, front-loaded sentences cover content and usage guidance without any fluff. Every clause adds information, and the 'cheap; call first' guidance is easy to parse.

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 status tool with no output schema, the description adequately enumerates the expected contents: session state with possible values, model label, project, and open chat tabs. The call-first hint completes the picture for an agent deciding when to invoke 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?

The tool has zero parameters, so parameter semantics are trivially satisfied. The description adds useful context about what the status covers, and no parameter documentation 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 clearly identifies the tool as reporting session state, model label, project, and open chat tabs. Although it lacks an explicit verb, the resource and data scope are unmistakable and it is distinguished from sibling tools by being a status/state snapshot.

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 'Cheap; call first' provides clear operational guidance: this tool should be invoked early because it is inexpensive. It does not name alternatives or exclusions, but for a status tool the directive to call first is sufficient 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core effect—stopping a reply—but does not mention what happens to the partial reply, whether the action is reversible, or any side effects. This is thin for a mutating control operation.

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 words. It directly states the action and target, which is appropriate for a simple 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?

Despite the tool being simple, the lack of annotations and output schema means the description should provide more behavioral and usage context. It does not explain what happens to the partially generated reply, whether the stop is permanent, or how to identify the right chat. This leaves meaningful gaps for an agent.

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 a single 'chat' string with no description (0% coverage), so the description must compensate for parameter meaning. It only says 'in a chat,' which adds minimal context about the parameter, but it does not clarify the expected format, identifier type, or how the chat is specified.

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 'stop' and a specific resource 'the reply currently being generated in a chat,' making the core operation clear. It does not explicitly differentiate from siblings like 'wait' or 'get_reply,' but the action 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 'currently being generated' implies the tool should only be used mid-generation, which provides some usage context. However, there are no explicit when-to-use/when-not-to-use instructions or references to alternative tools such as 'wait' or 'get_reply.'

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 of explaining behavior. It discloses that this is a polling operation, that it waits for a reply to finish, that a 'generating' status means the agent must poll again, and that it returns the reply in reply_format. It does not describe error/timeout edge cases or explicitly confirm lack of side effects, but the core behavior is transparent.

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 short, purposeful sentences. The core purpose is front-loaded, followed by the key constraint and loop behavior, then the return semantics. Every sentence earns its place 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?

For a simple polling tool with no output schema and no annotations, the description covers the main loop and return value adequately. However, it leaves gaps: the chat parameter is unexplained, non-'generating' statuses are not mentioned, and timeout behavior is only implied. These gaps prevent it from being fully self-sufficient.

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 timeout_sec (max 900) and reply_format (the format of the returned reply), but it completely omits the required 'chat' parameter. An agent would have to guess what value to supply for chat, which is a significant gap for the only required 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 tool's function: 'Wait for the newest reply in a chat to finish (poll).' It identifies the verb, resource, and behavior, and distinguishes itself from siblings like status or get_reply by emphasizing polling and reply retrieval. The added details about status=generating and reply_format make the tool's role 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 description provides concrete usage guidance: set timeout_sec<=900, and if the returned status is 'generating', call wait again. This tells the agent how to use the tool in a loop. It does not explicitly discuss alternatives or when not to use this tool, but the context is clear enough for typical polling scenarios.

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