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 two side effects: history is preserved and a running turn is cancelled. However, it doesn't disclose whether closing is reversible, whether subsequent messages will fail, or any permission requirements.

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 deliver the core action and the two most important side effects. There is no filler, and the content is front-loaded and easy to scan.

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 mutation with no output schema, the description covers the main behavioral outcome but leaves gaps: no statement about reopening, error conditions, or the effect on subsequent chat calls. Given the absence of annotations, a bit more context would improve completeness, but the tool is simple enough that these omissions are moderate.

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 0% description coverage and the description does not discuss chat_session_id at all. While the parameter name is self-descriptive, the description provides no guidance on how to obtain or validate the session id, leaving the agent to infer it from context.

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 clear imperative verb and resource: mark a chat closed. The detail that history is kept and a running turn is cancelled helps distinguish it from other chat lifecycle tools like chat_start and chat_send, though it does not explicitly name a sibling.

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 explicit when-to-use or when-not-to-use guidance is provided. The description implies closing is for ending a chat, but it doesn't contrast with alternatives like chat_poll or chat_list or state conditions under which closing should be avoided.

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 only provides the return format, omitting any mention of read-only semantics, authentication requirements, pagination, or potential error conditions. It does not contradict annotations (none exist), but leaves key behavioral aspects unspecified.

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, compact sentence that immediately conveys the return structure. There is no fluff or redundant wording; every token serves a purpose, making it highly efficient.

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 gives the return format explicitly, which covers what the tool outputs. However, with many sibling tools and no usage guidance, plus a single parameter whose meaning is only implicit, the definition lacks sufficient context for an agent to confidently invoke it in the right scenario.

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 explain the parameter, but it does not mention chat_session_id at all. The schema only gives type 'integer' and a title, leaving the agent to infer the parameter's role from the tool name and context.

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 phrase 'Message-level history of a chat' clearly indicates the tool returns the message-level history, and the appended array shape clarifies the return format. This distinguishes it from chat_list (session-level list) and chat_poll (new messages), though it lacks an explicit verb like 'retrieve'.

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 offers no guidance on when to use this tool versus siblings like chat_poll or chat_list. It does not state whether it returns all history or only new messages, nor does it mention alternatives for filtering or incremental updates.

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 behavioral disclosure burden. It does disclose an important nuance: closed sessions are included and marked. It does not mention ordering, default behavior when working_dir is empty, or other response characteristics, though 'List' implies a read-only 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, efficient sentence that fronts the primary action and bundles the important behavioral note about closed sessions. Every part of the sentence earns its place, 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?

For a simple one-parameter listing tool with an output schema, the description covers the core behavior and the optional filter. It does not cover pagination, sorting, or what an empty working_dir means, but the presence of an output schema and the tool's simplicity make this acceptable.

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 provides only the parameter name and default value, with no description, so schema coverage is 0%. The description compensates by explaining that the working directory is an optional filter, giving meaning to the sole parameter beyond what the schema offers.

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 clear verb and resource: it lists chat sessions, not individual messages, which distinguishes it from chat_history. Mentioning that closed sessions are included and marked adds useful scope. It does not explicitly differentiate from sibling tools beyond that, 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?

The description clearly conveys that this tool is for listing chat sessions and that working_dir is an optional filter, which implies the typical use case. However, it does not provide any explicit guidance on when to prefer this over alternatives like chat_history or chat_start, nor does it state exclusions.

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 full responsibility for behavioral disclosure. It mentions the long-poll nature and early return, but omits key behaviors such as timeout handling, immediate return when already complete, potential errors, and side effects. This is insufficient for an agent to anticipate the tool's runtime behavior.

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, concise sentence with no filler, efficiently communicating the core purpose and return format. It could benefit from more details, but the structure is clean and 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?

Given the absence of annotations and output schema, the description is the only source of context beyond parameter names. It fails to explain parameter semantics, timeout behavior, or error conditions, making it incomplete for a 3-parameter polling tool with siblings like chat_history and council_poll.

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% and the description does not mention any parameter names or explain the semantics of task_id, wait, or timeout. It provides no value beyond the raw schema, leaving an agent without guidance on how to set these parameters correctly.

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 ('Long-poll') and a specific resource ('queued chat turn'), clearly differentiating it from siblings like chat_send and chat_history. It also specifies the returned shape, leaving no ambiguity about the tool's core function.

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 usage after a chat turn is queued, providing clear context. However, it does not explicitly mention alternatives or scenarios where polling should be avoided, though the nature of the tool makes its use case fairly evident.

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 burden. It discloses the key behavioral traits: async operation, immediate return with a task_id, and the need to poll. This adequately informs the agent of the tool's core behavior, though it omits details like error handling or rate limits.

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 that conveys the core purpose and async nature immediately, then provides the return type and follow-up action. Every word 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?

Given the tool's simplicity and lack of output schema, the description covers the essential aspects: what it does, the async return, and the next step (polling). It does not describe edge cases or detailed response structure, but the mention of {task_id} provides sufficient context for an agent to proceed.

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 parameter meaning. It does not explain 'chat_session_id' or 'message' beyond their obvious names, and no additional context is provided for how they should be used or formatted. The parameter names are somewhat self-explanatory, but the description adds no semantic 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 clearly states the action ('Send a message') and the target ('chat's seat'), and explicitly notes the ASYNC behavior, which distinguishes it from synchronous tools like chat_poll. The reference to returning a task_id and polling via chat_poll further clarifies its role.

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 clear context that this is an async send and that results are obtained by polling with chat_poll. While it doesn't explicitly state when not to use it, the directive to poll with chat_poll effectively indicates the expected workflow and distinguishes it from the chat_poll tool.

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 transparency burden. It discloses the return shape and the default model behavior, which is useful, but it does not mention side effects, persistence, health requirements, or resource cleanup. It adds some context but leaves significant behavioral aspects unspecified.

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, front-loaded with the action and return value. Every word earns its place, and the return value is presented clearly in a compact way.

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?

Given the tool has 4 parameters, no annotations, and no output schema, the description is incomplete. It covers the purpose and return shape but leaves working_dir and system_prompt unexplained, and lacks usage guidance. An agent would need additional information to correctly invoke the tool with the optional parameters.

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%, and the description only explains 'seat' (seats.yaml key) and 'model' (defaults to first healthy model). The parameters 'working_dir' and 'system_prompt' are completely unexplained. Since the description must compensate for the lack of schema descriptions, partial coverage of only half the parameters 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 uses a specific verb phrase 'Open a direct 1:1 chat with one seat' and clearly identifies the resource (a seats.yaml key). It distinguishes itself from sibling council_start (council vs direct 1:1) and chat_send/chat_poll (starting vs continuing a 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 usage as the entry point for a direct 1:1 chat, contrasting with council tools, but it does not explicitly state when to use this tool versus alternatives like council_start or chat_send. No when-not-to-use or alternative guidance is provided.

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 behavioral burden. It discloses a key trait—this tool never reveals the model—and explains why council_poll omits content. However, it does not describe error cases or behavior if called before a hat is done, though the simple fetch nature makes this less critical.

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 core purpose and immediate usage condition. Every phrase earns its place—no filler, no repetition of schema field names beyond necessary context.

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 tool is simple (2 params, no output schema, no nested objects), and the description covers purpose, trigger condition, and a key non-behavior (model secrecy). It could mention where to obtain council_id, but the workflow context with council_poll makes the description sufficiently 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 0%, so the description must compensate. It explains 'hat' as a blind label with an example ('hat2') and ties it to 'status=done in council_poll'. It does not explain 'council_id', but the name and context make its role inferable. Partial compensation, not full.

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 ('Fetch') and resource ('ONE seat's FULL answer text') with a clear identifier ('blind hat label'). It explicitly distinguishes itself from council_poll by stating it retrieves content council_poll omits, and from model-revealing tools by noting 'Never reveals the model.'

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?

Provides explicit when-to-use guidance: 'Call once a hat shows status=done in council_poll.' It also implies when not to use (before done) and references council_poll as the alternative that omits content, plus a clear exclusion ('Never reveals the model').

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 states that the tool 'Runs a follow-up turn on that seat's session (it may re-read files)' and 'returns its reply synchronously,' which are meaningful behavioral details. It also discloses the critical constraint that it 'Never reveals the model.' While it doesn't mention potential side effects or error conditions, it covers the most important behavioral aspects for a probe 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 compact and every sentence contributes: purpose, behavioral detail, a critical constraint, and a usage recommendation. It is front-loaded with the primary verb and resource, making it easy to scan.

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 having no output schema and no annotations, the description is quite complete. It explains what the tool does, how it behaves, and when to use it, and it notes that the reply is returned synchronously. It lacks explicit return structure details, but the description's overall clarity compensates for the absence of an output schema.

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 parameter meaning. It gives a concrete example for 'hat' ('hat2') and implies that council_id identifies the council and message is the follow-up prompt. However, it does not explicitly define the expected format or constraints for council_id and message, leaving some ambiguity.

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 action ('Cross-examine'), the target resource ('ONE seat by its blind hat label'), and the context ('within a council'). It also distinguishes this tool from siblings by emphasizing it targets a single seat, and the phrase 'Never reveals the model' adds a unique distinguishing constraint.

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 an explicit use case: 'Use to probe disagreements before you synthesize.' This gives clear when-to-use guidance. However, it does not explicitly name alternative tools or when not to use it, but the emphasis on 'ONE seat' implies a contrast with broader polling tools.

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 discloses a key side effect: 'Records are KEPT ... nothing is deleted,' clarifying the tool is non-destructive to data. It also mentions the ordering requirement with council_score. Missing are details like reversibility or required permissions, but the provided context is valuable.

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 sentences, each with a distinct purpose: state the action, note data retention, and give a prerequisite. It is front-loaded and contains no filler, making it highly efficient.

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 operation, the description covers the purpose, side effects (nothing deleted), and a critical prerequisite. It does not explain the return value or post-close state, but these are less essential given the straightforward nature of the tool and the presence of sibling tools for other operations.

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 required parameter, council_id, with no description. The tool description does not explicitly describe the parameter, but 'Mark a council closed' makes its role obvious (the council to close). Since the parameter is simple and self-explanatory, this meets the minimum but adds little extra semantic meaning 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?

The description clearly states the tool's function with a specific verb and resource: 'Mark a council closed.' This distinguishes it from sibling tools like council_start (begin a council) and council_score (score seats). The 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?

It provides an explicit precondition: 'Score the seats with council_score FIRST if you haven't.' This tells the agent when not to use this tool yet and names the specific sibling tool to use first, giving clear sequencing and 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?

With no annotations, the description carries full behavioral burden. It explicitly discloses that the tool returns only True/False and never the hat label or answer, which is a critical behavioral guarantee. It also implies it is a safe check (no side effects) and is used specifically to preserve blindness, adding context beyond a bare function 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 exceptionally concise—two sentences with no filler. It front-loads the core purpose, then adds a critical behavioral caveat and usage context. Every word 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 simple boolean-check tool with an output schema, the description covers purpose, behavior, parameter roles, and usage intent. It doesn't discuss error conditions or edge cases (e.g., invalid council_id), but those are not necessary for a tool of this simplicity. The description is complete enough for the agent to use it correctly in normal scenarios.

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 does explain the role of 'model' as the participant whose answer status is checked, and 'council_id' as the context. However, it does not specify any conventions for model values (e.g., name format or source) beyond the schema's type, leaving the agent to infer from sibling tools. This is adequate but has a clear gap.

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 ('has model finished answering') and resource (council), and immediately distinguishes this tool from siblings by emphasizing the 'blind check' nature that returns only True/False without exposing hat label or answer. This makes it unambiguous and separates it from council_poll or council_reveal.

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 clear context: use this when you need to confirm a model participated without breaking hat blindness for scoring/synthesis. It does not explicitly mention alternatives or exclusions, but the context is strong enough to guide the agent's selection among sibling tools.

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 burden of behavioral disclosure. It delivers: the blind/no-bloat design, the meaning of DONE vs RUNNING statuses, the progress object details, long-poll early-return behavior, and the 'returning early' optimization. This is far more transparent than most API descriptions.

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, then explains return behavior and long-poll mechanics, followed by a usage paragraph. Every sentence adds new information—no repetition or filler. Despite being detailed, it remains tight and well-organized, earning 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?

Despite having no output schema and no annotations, the description covers the essential operational aspects: return types, status semantics, polling behavior, and the follow-up flow to council_answer. It even addresses the edge case of a short first poll burning turns. This makes the tool fully usable without external documentation.

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 0% description coverage, so the description must compensate. It directly explains wait and timeout: 'With wait=True this long-polls up to timeout seconds' and 'timeout >= 360' for the first poll. It even explains the benefit of a large timeout. council_id is self-explanatory from the schema and context. This adds substantial semantic value beyond the bare 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 opens with a clear, specific verb and resource: 'Poll a council for seat STATUS ONLY'. It immediately distinguishes itself from siblings like council_answer by noting that it strips model names and answer bodies, focusing purely on status. This is not a vague or tautological statement; it precisely defines the tool's scope.

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 guidance is explicit and actionable. It tells the agent to call repeatedly until done=true, then fetch answers with council_answer. It also provides concrete timeout recommendations: 'FIRST poll: use timeout >= 360' and explains why, and notes subsequent polls can be shorter. This goes well beyond vague usage hints.

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?

Since there are no annotations, the description carries the full burden of disclosing behavior. It states the output (hat->model mapping and per-seat status) and adds a key warning about not using it for diagnostic weighting, which is a behavioral trait beyond the raw action. However, it does not explicitly state side effects or access requirements, but as a 'reveal' operation focused on returning data, the main behaviors are adequately 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?

The description is two sentences, front-loaded with the main action, and each sentence adds value. The first explains what it does; the second provides crucial usage guidance. No waste, perfectly concise.

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 tool with one parameter and no output schema, the description covers the essential context: what it returns (mapping and status) and the intended usage scenario. It lacks detailed return value structure (e.g., what 'per-seat status' contains), but for a debug tool, this is acceptable. The warning about non-diagnostic use adds important context, making it fairly 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 0% description coverage—the only parameter, council_id, is just a type and title. The description does not mention council_id at all, so it fails to compensate for the low schema coverage. While council_id is a simple integer, the description adds no meaning beyond the schema, leaving the agent to infer its purpose from the tool name.

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: 'De-anonymize a council: return the hat->model mapping and per-seat status.' It uses a specific verb ('de-anonymize'/'return') and identifies the resource ('council'). The mention of 'after synthesis' and 'do NOT use this to weight the diagnosis' distinguishes it from sibling tools like council_score and model_scores, which likely serve diagnostic purposes.

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 it ('For human/debug insight AFTER synthesis') and when not to use it ('do NOT use this to weight the diagnosis'). This gives clear context and an exclusion, satisfying the 'explicit when/when-not' criterion even without naming an alternative tool.

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 disclosure burden. It reveals that the server resolves hat->model itself, that scores feed a per-model leaderboard, and that scores are judged on correctness, depth, and actionability. It does not mention the response format or what happens on duplicate calls, but the core side effects are clearly 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?

The description is dense and front-loaded with the purpose, followed by an example and scoring rubric. No filler words, but the embedded JSON example makes it longer than strictly necessary. Overall, each sentence contributes useful 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?

Given the lack of annotation and output schema, the description covers the essential workflow context: when to call, how to score, what fields to provide, and where results go (model_scores). Minor gaps exist: council_id is not explained and the return/acknowledgment behavior is unspecified. Still, the tool is well contextualized within its sibling workflow.

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 is minimal (0% coverage; scores items are free-form with additionalProperties), so the description must add meaning. It provides an example object shape with hat, score, and notes, defines the score range (1-10), and explains the scoring criteria. Council_id remains undocumented and notes optionality is unclear, but the description compensates substantially for the schema gap.

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-object pair ('Score each seat's reply') and immediately identifies the tool as the MANDATORY end step of every council. It distinguishes itself from siblings like council_reveal and model_scores by naming the exact temporal position in the workflow, so the agent knows exactly what this tool does and how it differs.

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 explicitly stated: it must run AFTER synthesis and BEFORE council_reveal, and it is labeled MANDATORY for every council. The rationale (avoiding bias by model identity) provides context for why ordering matters. This is strong, actionable guidance for when to invoke the tool.

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 burden of behavioral disclosure. It reveals that seats run concurrently in the background, that the tool returns immediately, that the hat->model mapping is hidden, and that the 'kind' parameter never affects routing—all beyond what the schema or annotations provide.

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 three focused paragraphs: core behavior, optional parameters, and the 'kind' parameter. Every sentence provides value, front-loaded with the primary purpose, and uses formatting (bold, backticks) to enhance readability without waste.

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?

Given the lack of an output schema, the description adequately explains the immediate return value (council_id and blind hat labels) and points to council_poll for retrieving answers. It covers most parameters and important behavioral details, but omits the seat_system_prompt parameter and does not describe potential error conditions or lifecycle management (e.g., council_close).

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 description adds meaningful semantics for four of the five parameters: brief (fanned out to seats), models (optional, default roster), working_dir (defaults to server CWD), and kind (purely descriptive, never affects routing). However, it does not explain 'seat_system_prompt,' leaving that parameter underspecified despite schema description coverage being 0%.

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 'Convene a blind multi-model council on a hard problem,' clearly stating the verb and resource. It then details the exact behavior (fans brief out to one seat per model, runs concurrently, returns immediately) and differentiates itself from siblings by mentioning council_poll and council_reveal, making it distinct from chat and other council 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 description gives clear context for when to use the tool ('on a hard problem') and explicitly references council_poll for polling answers and council_reveal for unmasking hat-to-model mappings. It does not explicitly state when not to use it versus chat_start, but the context and sibling references provide sufficiently clear usage 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?

With no annotations, the description carries the burden. It discloses the data source (seats.yaml) and the return format (seats and warnings), and hints that warnings may indicate skipped seats. However, it does not explicitly state that the operation is read-only, nor does it mention potential errors or side effects beyond loader warnings.

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 sentence with no fluff, front-loading the action. It packs the return format and a brief explanation of warnings and seat concept efficiently. Slightly dense but not verbose.

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 no-parameter listing tool, the description provides the return format, warns about possible loader warnings, and explains the domain concept of a seat. It lacks only explicit usage context, but that is covered under usage guidelines. Given the absence of an output schema, this is sufficiently 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 tool has zero parameters and the schema documents none. The baseline for 0 parameters is 4, and the description adds no parameter-specific meaning since there are none to define.

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 ('List') and resource ('seats defined in seats.yaml'), and clarifies what a seat is (LLM family served by CLI). It does not explicitly contrast with sibling tools, but the name and description make its purpose 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?

Usage is implied by the name and description; there is no explicit guidance on when to use it versus alternatives, nor exclusions. The description does not mention any alternative tools or conditions, leaving it to the agent to infer that it is the tool for listing seats.

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 burden. It discloses the data composition (all council scores, avg, count, recent scores) but does not mention whether the data is live, cached, or whether there are any conditions (e.g., requires an active council). No side effects are implied, but for a read-only leaderboard this is adequate though not thorough.

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, readable sentence that packs essential information: the metric (leaderboard), source (council scores), and specific fields returned. 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 zero-parameter, simple aggregate query with an output schema, the description covers the behavior and contents. No additional context is necessary.

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 the description needs no parameter details. The schema coverage is 100% (vacuously). Per baseline guidance, 0 params earns a 4, and the description adds no unnecessary param info.

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+resource: 'Per-model quality leaderboard' aggregated from council scores. It clearly identifies the output contents (avg_score, eval count, 5 most recent scores), distinguishing it from sibling council tools like council_reveal or council_score which likely operate per seat or per score.

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?

Implicitly clear that this is for viewing a leaderboard of model quality across all council scores. It gives no explicit exclusions or alternative tool references, but the context is sufficient for a simple query tool with no parameters.

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 clearly indicates a read-only 'dump' operation and enumerates the output fields, but it does not explicitly state that there are no side effects. The phrase 'Seats record capacity failures here' could be misread as a write operation, though the verb 'dump' clarifies the tool's read-only nature.

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 concise and front-loaded, with the core purpose in the first sentence. The second sentence adds relevant behavioral context, and the final parenthetical historical note is brief and does not obfuscate. Every sentence earns its place without unnecessary verbosity.

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, parameterless dump tool with an output schema, the description is complete. It explains what the tool returns, what the statuses and reasons mean, and how the data relates to council_start behavior. It also notes the rename for continuity. No additional context seems necessary.

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 coverage is 100% (empty). The description adds value by describing what the returned dump contains, providing semantic context that the schema cannot. This meets the baseline of 4 for a parameterless 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?

The description clearly states the tool's function with a specific verb ('Dump') and a well-defined resource: the seat/model availability cache. It enumerates the exact data returned (per-model status, classified reason, last error, cooldown expiry), making its purpose unambiguous and distinguishing it from sibling tools that perform actions or list seats.

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 clear context for when this tool is relevant by explaining that seats record capacity failures here and that council_start skips models in cooldown. This implies usage for debugging availability before council operations, though it does not explicitly state exclusions or directly contrast with alternatives like list_seats.

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