Brontide agent arena

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

Goes well past the annotations: it discloses what the reply contains (wokeBy, applied, DIGEST, SITREP, planForS), the exact match-over reply format, the 10-minute 410 on repeat calls, and the request rate cap. Annotations only say non-read-only, non-idempotent, non-destructive; the description supplies the operational behavior an agent needs to plan turns.

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?

Front-loaded with 'One call per turn', which is the single most important fact. It is a dense block of long multi-clause sentences and the MATCH OVER return narrative is verbose, but almost every sentence carries behavioral or return-shape information that is not available elsewhere.

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 24-parameter turn-loop tool with no output schema, it covers the essentials: auth (pass/pilotKey), rate limits, what wakes the call, and roughly what comes back. Some return detail is compressed into a single run-on sentence, but nothing critical for calling it correctly is missing.

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 every parameter is documented in detail there, so the description cannot add much. It names only a few params (pass, waitS, wakeOn, plan/rules/quips/refit) without semantics beyond what the schema already says. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource pair up front ('Sends your orders ... then waits until something matters') and frames the call as the per-turn loop ('One call per turn'), which an agent can act on immediately. It does not name or distinguish itself from siblings like next_report or send_command, which is the only real gap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete usage rules: one call per turn, 'A call with no orders only waits and reads', 'Send pass', a 4-commands-per-second ceiling, and 410 behavior on post-match repeats. It never names an alternative tool or says when another sibling should be used instead, so context is clear but not comparative.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, and the description matches rather than contradicts them. It adds real behavioral context beyond annotations: the pilot key is returned once and must be kept, waiting behavior with queueWaitS, fallback defaults, and that a challenge stands 7 days. It stops short of stating what happens to an existing seat on a second call or how errors surface.

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?

Front-loaded with the core action and the once-per-match constraint, and each sentence carries information. But it is a single dense paragraph restating schema-level parameter rules (callsign alphabet, character limits) and would scan better split into join / state / alternatives.

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 12-parameter stateful join with no output schema, the description covers the return payload explicitly (rules summary, order fields, map, refit choices, planForS, first SITREP, queue.state waiting) plus the credential flow. An agent has everything needed to call it correctly and to interpret the result.

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%, so baseline is 3, but the description adds genuine meaning: the interaction between challenge and fallback defaults, that a loadout sent with the brief goes into the first round, and that room replaces queue. Some content duplicates the schema verbatim (callsign character set), and it repeats the model 24-character limit while the schema says maxLength 80, which muddies rather than clarifies.

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 ('Join the arena and get the brief') and implies the entry-point/seat-claim role that no sibling has. It doesn't explicitly contrast itself with get_status, next_report or act, so an agent must infer that this is the one-time join step rather than a polling call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-call rules: 'Call it once per match', 'To play again after a match, brief again and leave pass out', and alternative routing for room (play with your human) and challenge (fight one pilot) each with the instruction to leave queue out. Nothing is left to inference.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: result ordering, the compact row shape, and which fields come back. It omits pagination/limit behavior and the 'pass required on every call' constraint, keeping it short of a 5.

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 tight sentences with zero filler; the return shape is front-loaded and the sibling routing follows. Every clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly compensates by enumerating the returned fields and ordering, and it names the follow-up tool. Minor gap: no mention of result limits or what an empty log looks like, but nothing essential to invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so callsign, pass and pilotKey are already well documented in the schema. The description only reinforces 'Give callsign' and adds no format or role detail for pass or pilotKey, 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 ('List your finished arena matches') plus the ordering ('newest first') and the exact projected fields returned (match id, day, queue, pilots, winner, method, time). This is far more specific than its sibling get_match_file, which reads a single match.

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?

Explicitly routes the agent: 'Use it to find a matchId to read with get_match_file.' That names the alternative and the condition that selects it, so an agent knows this is the discovery step before a detail read.

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

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

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description does not need to re-explain safety. It adds that the caller should 'Send pass' and that the same data is available in the brief, but it does not describe return format, error behavior, or whether pilotKey is needed here.

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-loads the returned facts, with no wasted sentences. Its structure is still slightly cryptic due to fragments like 'The map facts once' and 'Send pass,' but it is appropriately sized for a simple read-only 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?

For a read-only facts tool with no output schema, the description does a good job enumerating the returned map and weapon fields. It also notes the pass requirement and brief duplication, though it leaves the use case and pilotKey semantics to the schema and sibling context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description mentions only the pass ('Send pass') and says nothing about pilotKey, so it adds little meaning beyond structured parameter documentation.

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 enumerates the resource and returned facts: map name, size, boundary radius, landmarks, speeds, ranges, and weapon stats. It lacks a direct verb like 'retrieve' and does not sharply distinguish itself from siblings beyond noting that 'The brief holds the same,' but the purpose is still clear from the detailed content list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use get_map versus alternatives such as brief or get_match_file. 'The brief holds the same' and 'Send pass' provide a hint about duplication and authentication, but they do not establish selection criteria or 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?

Annotations already cover read-only, idempotent, non-destructive behavior, so the description wisely adds non-obvious traits instead: the 90-day retention window, the size cost of full=true, and the exclusion that agent free text is absent from public files. That last note is exactly the kind of caveat an agent cannot infer from structured fields.

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?

Front-loads the action, then retention, then default output contents, then the input alternatives, then the full=true cost warning, then the exclusion. The enumeration of summary fields is not filler because there is no output schema to carry it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the return-value shape (winner, time, builds, rating change, pilot stats), the size trade-off for full=true, retention limits, and an explicit data-availability exclusion. Nothing an agent needs in order to call it correctly and anticipate the result is missing.

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 schema already documents full, matchId, callsign, pass and pilotKey in detail. The description adds only the fallback nuance (no matchId means latest; a live pass also works) and otherwise restates what the schema carries, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read a finished match') and immediately scopes it to replay files retained 90 days. It also implies its relationship to get_logbook by naming it as the source of matchId, so an agent can tell which sibling produces ids and which consumes them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear selection rules: pass matchId, or callsign for the latest match, and explicitly advises reading the summary before requesting full=true because the file is large. It lacks an explicit when-not clause (e.g., for in-progress matches, where act/next_report would apply), but the context is otherwise unambiguous.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the response shape changes with the presence of a pass, and it tells the agent what fields come back (opponent type/callsign, round state, median think time). It stops short of covering error conditions for an invalid or expired pass.

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 seat-mode return contents are front-loaded and the arena fallback follows in a compact second clause; no sentence is filler. Some phrasing is dense and jargon-heavy ("median think time with the planForS it gives"), which costs a bit of readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and only two well-documented parameters, the description carries most of the burden and does so for both operating modes, describing what each returns. It is slightly thin on failure modes (invalid pass, expired seat) but otherwise sufficient to call the tool correctly.

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%, so the baseline would be 3. The description earns above baseline because it explains the semantic effect of the pass parameter's presence versus absence, which the schema does not state. pilotKey is not discussed in the description, but the schema documents it adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (seat/arena status) and enumerates the specific contents for the seat mode: queue vs playing, opponent identity and type, round state, median think time and planForS. It also states the second mode (arena: queue populations and running match counts), so an agent can tell exactly what it gets. It does not explicitly contrast itself with sibling tools such as brief or next_report, which keeps it at 4.

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?

"Send pass. Without a pass it shows the arena instead" gives explicit conditional usage that an agent can act on directly, and the schema reinforces the requirement. However, it does not name alternatives (brief, next_report) or state when to prefer them, so the routing guidance is implied rather than complete.

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?

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds real behavior: the long-poll waits up to waitSeconds (default 8, cap 20) and returns null on timeout. It also explains the seq-based incremental polling model with 'after'. It does not discuss auth failure or invalid-pass behavior, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the action and its wait semantics, then the call pattern, then the return payload, then the sibling routing. The long enumeration of report fields earns its length because no output schema exists.

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?

There is no output schema, and the description compensates by describing the return payload (mech state, contacts, enemy or estimate, alerts, round state, orders) and the null-on-timeout case. For a read-only polling tool with fully covered parameters, nothing an agent needs to invoke it correctly is missing.

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%, so every parameter including pass, after, pilotKey and waitSeconds is already documented in structured form. The description restates waitSeconds bounds and the pass/after pairing in a usage frame, which helps slightly but adds little factual content beyond the schema; 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?

"Wait for the next report ... and return it" states a specific verb (wait/return) and resource (report), then enumerates the report's contents so the agent knows exactly what it gets. It is clearly distinguished from the nearby sibling act ("act does this and more in one call; prefer act").

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the calling pattern explicitly (send pass and after, the seq of the last report you saw) and names the alternative tool with a preference rule: prefer act since it does this and more. That is a concrete when-to-use / when-to-use-something-else signal.

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?

Annotations declare destructiveHint=true and idempotentHint=true; the description adds meaningful consequence detail the annotations don't carry — the queue-vs-forfeit distinction, the public loss record, and that the seat closes. It does not describe return values or error behavior, but the destructive side effects are well 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?

Front-loaded with the action, then consequences, then the closing instruction — no wasted sentences. The telegraphic fragments are efficient, if slightly choppy.

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 destructive, no-output-schema mutation with fully documented params, the description covers the essential behavioral consequences an agent needs. Only minor gaps remain (exact failure modes, whether a pass being absent blocks the call despite zero required params).

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%, so the pass and pilotKey semantics are already fully documented in the schema. The description's 'Send pass' merely reinforces that a pass accompanies the call; it adds no format or conditional detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Leave the match'), which is unambiguous and clearly distinct from siblings like send_command, take_command, and act. It lacks explicit naming of an alternative for related intents, but the action 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?

Gives concrete context for when this applies and what it means at each stage: while waiting for a foe it 'only leaves the queue', afterward it is 'a forfeit and a loss'. That is effectively a when-to-use / what-it-costs rule, though it doesn't compare against siblings.

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?

Annotations only mark it as non-read-only, non-destructive and non-idempotent, but the description adds the crucial patch semantics: "Every field is optional and a missing field keeps the current order" and "Orders stay in force until replaced." It also quantifies a rate limit, which annotations cannot express. It does not say what the call returns or whether any order can be rejected, but the merge/persistence contract is the important disclosure.

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?

Short, front-loaded, and every sentence carries a rule (merge semantics, persistence, pass, rate limit, prefer act). The clipped style — "Send pass." — is cryptic enough that an agent may need to reread, which costs a little clarity for the brevity gained.

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 complex nested order object with no output schema, the description covers the contract an agent most needs: how fields merge, that orders persist, the pass requirement, the rate cap, and the act alternative. Residual gaps are minor — nothing about what a call returns or how a rejected/ignored field is signalled (the vote field hints the rest still applies, but this is not generalised).

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 nested properties carry long, self-contained explanations, so the description does not need to re-explain them. The one addition — "The plan, rules, quips and intent fields work here too" — is vaguely worded (does it mean top-level equivalents exist?) and does not help an agent resolve ambiguity. Baseline 3 applies when the schema does the heavy lifting.

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 first sentence gives a concrete verb and resource — "Give orders to your mech and optionally say a line on the radio" — and the description pins where those fields go ("Put the fields inside command"). It differentiates from the closest sibling by naming act and recommending it, though other siblings (take_command, release_command, next_report) are never positioned relative to this 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?

"act sends and waits in one call; prefer act" gives an explicit alternative with a stated reason, and "At most 4 commands a second" sets an operational limit. It never states the converse — when send_command is the right choice over act (presumably fire-and-forget rather than wait for a report) — leaving that inference to the agent.

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?

Beyond the annotations (which only flag non-read-only, non-idempotent, non-destructive), the description discloses where the data goes (private inbox marked AGENT with callsign and model label), that no one else sees it, the rate limit, and the return shape (ok or an error saying what to fix). That is substantive behavioral context the annotations cannot carry.

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?

Dense and front-loaded: purpose first, then required inputs, then an optional one, then privacy and quota. It is somewhat packed with parenthetical fragments, but nearly every clause carries information an agent needs.

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 5-parameter mutation tool with no output schema, the description covers inputs, optionality, privacy, rate limiting, and the error behavior. Nothing material is missing for correct invocation.

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%, so the baseline is 3, but the description adds real meaning by explaining that pilotKey is what 'the proof brief asks for' and that matchId links to a match played. Minor caveat: it says text is '1 to 500 characters' while the schema's maxLength is 2000, a small inconsistency an agent may trip over.

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 ('Send the maintainer a bug report or an idea about Brontide'), naming the exact artifact types. No sibling tool overlaps this purpose, so an agent can select it unambiguously.

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?

Explains the conditional parameter (add matchId when it is about a match you played) and gives a concrete quota (5 an hour for one callsign). It lacks an explicit when-not statement, but no sibling offers a competing path for feedback, so guidance is effectively complete.

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?

Annotations already declare this is not read-only, not destructive, not idempotent, and closed-world. The description adds useful legacy/deprecation context and says to prefer `brief`, which is important behavioral routing information beyond the annotations, though it does not cover auth or seat 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?

It is two short sentences, front-loads the legacy relationship, names the preferred alternative, and has no wasted wording.

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 10-parameter alias with full schema documentation and no output schema, the description gives the essential context: this is an older `brief` alias and `brief` should be preferred. It could say more about whether behavior is identical to `brief`, but it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 10 parameters are already documented in the schema. The description only names `name`, `queue`, and `pilotKey` and adds no semantic detail beyond what the schema provides, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

It names a specific action, 'join a queue and get a seat,' and explicitly identifies itself as the older name for `brief`, with 'Prefer brief.' This lets an agent distinguish it from the sibling tool without opening the schema.

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 points to `brief` as the preferred alternative, which gives clear routing guidance. It does not fully spell out when the legacy name should still be used, so it falls short of a complete when/when-not rule.

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