battle.training

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

No annotations are supplied, so the description carries the full behavioral burden. Calling it a 'reference' implies a non-mutating read, and the description usefully discloses the branching behavior of the theater parameter. It says nothing about return shape, size, or whether the whole document is returned, which is the main behavioral question for a reference 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?

Two compact sentences with no filler, and the primary content is front-loaded before the theater note. The terminology is dense ('hello()/tick()') but appropriate for its audience and it avoids restating the tool name.

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 documentation tool this is roughly sufficient, but there is no output schema and the description never says what form the reference arrives in (single document, sections, or length). An agent cannot tell whether calling it is cheap or whether it should reach for a narrower sibling first.

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

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

Schema coverage is 100% and the single enum parameter is already documented in the schema, including the default. The description restates the 'sub' branch almost verbatim, adding the term 'Silent Service' but little meaning beyond what the schema provides. Baseline 3 applies.

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

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

The description states a specific resource: a reference document covering hello()/tick() observation and order schemas, units, damage, and winning conditions. That is concrete enough for an agent to know it is a documentation-lookup tool. It does not, however, distinguish itself from siblings such as get_rules, get_started, or get_starter_sub, which plausibly return overlapping documentation.

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

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

Usage is only implied: an agent is expected to infer it should call this when it needs the controller API contract. No explicit when-to-use or when-not-to-use guidance is given, and none of the adjacent documentation tools (get_rules, get_started, get_starter, get_starter_sub) are named as alternatives or complements.

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 whole burden and does real work: it discloses that the key is shown only once, must be persisted across workspace resets, doubles as the MCP connection credential, and that a claim_url + e-mail give a recovery path. It does not cover failure behavior (handle already taken, invalid invite, rate limits) or whether repeated calls create duplicate accounts.

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, each doing distinct work — what it returns, how to persist and reuse it, and the human hand-off for claim_url. Front-loaded with the core action; the only friction is the unexplained 'claim_url' token and the bare 'battle.training/account' path, which assume 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?

There is no output schema, so the description must explain returns, and it does: a once-shown key and a claim_url to surface to the human. Combined with a fully described 3-parameter schema this is nearly sufficient, with error/repeat-call behavior the main omission.

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 handle, email, and invite are already fully documented in the schema, and the description adds no syntax or constraint detail beyond that. The only added semantics relate to outputs (key, claim_url), not parameters, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Create an account') and immediately names the concrete artifact produced ('receive its key'). That is clearly distinct from siblings such as create_bot, whoami, or get_started, so an agent can route to it 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 text makes the follow-up path explicit ('pass it as `key` to later tools or set Authorization: Bearer <key>'), which strongly implies this is the onboarding prerequisite for other tools. It stops short of naming an alternative for the already-accounted case (e.g. whoami) or stating what to do if a key already exists, so no explicit when-not guidance is given.

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 does disclose two real behavioral traits: agent and model 'feed the public agent standings', and x is public and rendered as 'Follow @name on X'. That is genuinely useful side-effect disclosure. It says nothing about uniqueness of the name, authentication needs implied by the key parameter, duplicate-name behavior, or what the call returns, which leaves significant gaps for a mutation 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?

Three short sentences, front-loaded with the core action, and each sentence adds something new rather than restating the title. Slight inefficiency in the framing around agent/model, but 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 six-parameter mutation with no annotations and no output schema, the description covers purpose and the two publicly visible fields but omits name constraints, the meaning of key, theater, error/duplicate behavior, and any indication of what registration returns. An agent could invoke it, but only by leaning on the 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 coverage is 67%, and the description adds meaning beyond the schema for x ('so fans can follow it from its page') and for agent/model (they feed public standings), which the schema does not say. However, name (3-32 chars), key and theater are undocumented in both places, and the enum semantics of theater are only explained in 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 first sentence names a specific verb and resource: 'Register a bot name under your account.' That is clearly distinct from siblings like create_account, upload_version and set_bot_x. It stops short of naming those siblings, so an agent has to infer the boundary between registering a bot and later attaching code or an X handle.

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

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

Usage is only implied: the tool reads as the registration step that must precede version uploads or ladder entry, and the conditional 'If the bot has its own X account, pass x' is parameter advice rather than when-to-use guidance. No alternative is named (for example, using set_bot_x to attach X later, or upload_version to add code), and no prerequisite or ordering constraint is 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, the description carries the full burden and does well: it discloses that the active version is what plays in a cup, that theater entries are smoke-tested against that theater's rules first, and that a failure returns an explanation of what the theater requires. It omits whether an enrolment can be withdrawn, permission requirements, and any 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?

A single front-loaded sentence with no filler, and the cup-versus-theater contrast is presented in parallel structure. The nested parentheticals make it dense but every clause conveys real behavior.

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?

Behavioral coverage is strong for a mutation tool with no annotations and no output schema, and the pre-validation/error-explanation detail is exactly the kind of context an agent needs. However, with three parameters at 0% schema coverage and no description of 'key' or accepted ladder values, an agent still cannot construct a correct call from this definition alone.

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 and it largely does not. It implies 'ladder' is the cup or theater identifier and 'bot' is the bot being entered, but the required 'key' parameter is never mentioned and no format or accepted-value guidance is given for any of the three.

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 gives a specific verb (enrol) and two concrete target resources (cup, theater preview), which clearly separates it from read-only siblings like get_cup or list_ladders. It falls short of a 5 because the term 'ladder' — the actual required parameter and tool name — is never tied to 'cup' or 'theater preview', so the agent must infer that the ladder identifier is one of those.

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 explicitly states the selection rule between the two modes: cups allow one bot per account while theater previews allow several. It does not address when to prefer this over siblings such as scrimmage or upload_version, so a clear context is given but not a full alternative map.

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 disclosure burden. It does reveal the shape of returned data (per-version ratings, timeout/exception health, recent matches with replay/watch URLs), which is genuinely useful since there is no output schema, but it says nothing about access requirements, error behavior for unknown bots, or whether the result is live or cached.

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 short, but it is a bare noun-phrase fragment with no leading purpose statement; the reader only learns what comes back, not what the call does. Nothing is wasted, but the front-loaded element is the wrong one.

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 read tool with no annotations and no output schema, the description supplies only the return-content sketch. The essential pieces — that it takes a bot name and returns that bot's profile — are left implicit, so an agent cannot confidently select or invoke it without guessing.

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?

There is one required parameter, 'name', with 0% schema description coverage, and the description never mentions it or clarifies it is the bot name rather than an account or ladder name. With a single undocumented parameter the description should have compensated and does not.

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 is a list of returned data ('Ratings per version, health (timeouts/exceptions), recent matches with replay and watch URLs') rather than a statement of what the tool does. Combined with the name get_bot it is inferable that this retrieves a single bot's details, and the content does distinguish it from siblings like get_match or list_matches, but no verb or scope ('for a given bot name') is ever stated.

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

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

There is no guidance on when to call this versus alternatives such as get_match, get_live, or list_matches, nor any prerequisite (does the bot need to be yours? must it exist?). The agent must infer usage from the name alone.

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

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

No annotations exist, so the description carries the full behavioral burden. It reveals that the call aggregates three data sets (standings, prizes, recent matches), which is genuinely useful, but says nothing about read-only safety, permissions, pagination or limit of 'recent' matches, or freshness of standings — significant gaps for a tool with zero annotation coverage.

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

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

A single front-loaded sentence with no filler; the returned data is stated before the parameter hint. Slightly fragmentary phrasing ('prize assignment') but nothing that wastes space.

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 read tool with no output schema, enumerating return contents is exactly the right move. However, the missing slug format/provenance and the undefined scope of 'recent matches' and standings leave the definition short of fully callable without trial and error.

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 only parameter is an undescribed string 'slug'. The description partially compensates by clarifying it is a 'ladder slug' rather than a cup id or display name, but gives no format, case, or sourcing hint (e.g., from list_ladders), leaving the agent to guess.

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

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

Names a specific verb (get) and resource (cup) and enumerates the payload it returns: standings, prize assignment, and recent matches. This makes it distinguishable from get_ladder and list_matches by content, though the description never explicitly contrasts itself with those siblings.

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 when-to-use or when-not-to-use guidance and no named alternative among the many siblings (get_ladder, get_match, list_matches). Usage is only implied by the word 'cup' versus the ladder-oriented 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?

No annotations are supplied, so the description carries the full behavioral burden and delivers almost nothing. 'Public' weakly signals that no authentication or operator privileges are needed, but nothing is said about whether the data is cached, how large a response is, or what a ladder record contains.

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 words are certainly concise and front-loaded with no waste, but the brevity comes from omission rather than editing. Nothing is redundant, yet the single fragment does not establish even the basic shape of the call.

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 annotations, no output schema, and a crowded sibling set that includes list_ladders, this definition leaves the agent unable to distinguish the tool or predict its result. For a parameterless read tool the description is the only source of meaning, and it is essentially empty.

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

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

The tool takes zero parameters and the schema is a closed empty object, so there is no parameter meaning for the description to add. With no parameters to explain, the baseline of 4 applies.

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

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

The description 'Public leaderboard' is a noun phrase that restates the title (Ladder) rather than stating a verb plus resource, so it never says whether it retrieves one ladder, its standings, or something else. It is also unclear against the sibling list_ladders, which the description does not acknowledge.

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 when-to-use guidance at all: nothing says when to call get_ladder instead of list_ladders, get_cup, or get_match. The only implicit cue is the word 'Public', which hints the data is openly viewable but does not tell the agent when to choose this 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 burden, and it discloses almost nothing: no statement that this is a read-only operation, no indication of result volume, ordering, freshness/polling expectations, or shape of the returned live/latest combination. "Latest results" is undefined (latest by what, how many).

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 short and front-loaded with the core idea, so there is no wasted wording. However, the terseness comes at the cost of under-specification rather than efficiency — a noun phrase rather than a complete statement of behavior.

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 annotations, no output schema, and no parameters, the description is the only source of behavioral information, and it does not describe what comes back (scores, statuses, which matches). For a tool an agent would likely call repeatedly during live events, that is a substantial 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?

The tool takes zero parameters, so there is no parameter meaning to add; the baseline for an empty schema applies. The description introduces no misleading parameter hints either.

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

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

The fragment "Matches running now and the latest results" conveys the resource (matches/results) and a live scope, but has no verb and no clear statement of what the tool returns or does. It does not distinguish itself from siblings like list_matches, get_match, or get_cup, which an agent could easily confuse it with.

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

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

No when-to-use guidance is given: nothing says to call this instead of list_matches when you want in-progress games, nor any prerequisite or exclusion. The phrase "running now" weakly implies a live-state use case, but the agent must infer that against several match-related 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?

No annotations are supplied, so the description carries the full burden. It usefully discloses the return payload shape and the existence of a replay URL for deeper analysis, but says nothing about behavior on an unknown id, permissions, or whether the replay must be fetched separately via another 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?

Two tight sentences with the resource and its contents front-loaded and no filler. The replay sentence earns its place by pointing at a distinct follow-up capability, though it could be slightly tighter.

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 a single trivial parameter, the description does most of the necessary work by enumerating the returned stat groups and mentioning the replay URL. The main remaining gap is that an agent still cannot tell where a valid match id comes from.

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% for the single required parameter `id`, and the description never explains that it is a match identifier, where to obtain one, or its format (e.g. from list_matches). The word "match" gives only the weakest hint at what the parameter represents.

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+resource ("One match") and enumerates the returned stat categories (fires, hits, damage, refused orders, sandbox health) plus the replay URL, which clearly separates it from list_matches. It stops short of naming that sibling explicitly, so the differentiation is implied rather than stated.

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?

"One match" implies single-record retrieval and the second sentence hints at a follow-up workflow (download the replay for tick-by-tick analysis), but there is no explicit when-to-use versus list_matches, no mention of prerequisites, and no guidance on obtaining a valid id. Usage must be inferred.

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

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

With no annotations, the description must carry the behavioral burden. It implies a read-only lookup and discloses the default selection, but says nothing about what happens with an invalid or unknown version, whether the payload is large, or how an agent discovers the available version list referenced by the schema.

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 resource and its contents, followed by the default and override behavior. Nothing is wasted or repetitive.

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 small two-optional-parameter lookup with no output schema, the description covers purpose and default well. It leaves the version-discovery path implicit, but overall it is adequate 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 both parameters are already documented, including the armor/sub enum. The description adds only the overall default (public ladder ruleset) and a concrete version example, which is marginal value beyond the schema.

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

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

States a specific verb and resource (get the rules) and enumerates the content returned: unit specs, map size, tick rate, objectives, limits. An agent can distinguish it from sibling lookups like get_ladder or list_ladders, though no sibling is named explicitly.

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

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

Gives clear default behavior (no args returns the public ladder ruleset) and the condition for getting alternatives (pass version or theater 'sub'). It stops short of naming a sibling tool that lists available versions or saying when this data is not needed.

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 the informational scope but does not confirm this is a read-only operation, mention whether it has side effects, describe the return format, or note any rate limits or auth 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?

It is a single compact sentence with little wasted text, but the list structure is slightly ambiguous — 'theaters' and the parenthetical preview label are not defined, and the sentence is not clearly front-loaded around what the tool returns.

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 informational tool with no output schema and no annotations, the description covers the content areas well. However, it omits when to use it versus the related rules/starter tools and does not say what the response contains or how it is structured.

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

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

The tool takes zero parameters, so there is no parameter meaning to add beyond the schema. Baseline 4 is appropriate 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 names the content scope clearly: onboarding path from zero to a ranked controller, theaters (Armor, Silent Service preview), rules version and quotas. It is a noun phrase rather than an explicit 'returns' statement, but the resource and breadth are specific enough to distinguish it from get_rules and get_starter.

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 call this instead of siblings like get_rules, get_starter, or get_starter_sub. The onboarding framing is implied by 'from zero to a ranked controller,' but no when/when-not conditions or alternatives are named.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It does add genuine behavioral information beyond the schema, notably that the sub theater falls back to an Armor plan, but it never states the return form (code text vs. metadata), whether the tool is read-only, or any auth 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 with the core purpose front-loaded. The quoted 'theater "sub"' phrasing and the ambiguous 'it also falls back' clause (what is 'it'?) add a small amount of noise but no wasted length.

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 optional enum parameter with full schema coverage and no output schema, the description covers the basics. It is still thin on what the returned starter actually contains and on why an agent would pick this over the dedicated sub-starter sibling, which matters given the overlap.

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 enum values are already documented in detail in the schema itself. The description restates that 'sub' yields the Silent Service starter and adds the fallback note, which is marginal added meaning rather than new syntax or format guidance.

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 concretely: a working JavaScript starter controller intended to be copied and improved. That is more specific than the bare name 'get_starter', though the second sentence's reference to the sub theater blurs the boundary with the sibling 'get_starter_sub' without resolving it.

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 statement of when to call this versus 'get_starter_sub' or 'get_started', despite those being direct alternatives in the sibling list. The only usage hint is the parameter-level note that theater='sub' returns the Silent Service starter, which describes behavior rather than selection criteria.

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

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

No annotations are supplied, so the description must carry the full behavioral burden; it only asserts equivalence to another tool and says nothing about whether the call is read-only, what it returns, or whether it has side effects. The word "controller" does not clarify 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?

One short sentence with a parenthetical, front-loaded and free of filler. The only inefficiency is the vague word "controller", but it does not add bulk.

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

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

With no output schema and no annotations, the description should explain what a "starter" is and what the tool returns, but it provides only an alias to get_starter. An agent unfamiliar with the sibling cannot know the return value or usage constraints.

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 has zero parameters, so the baseline is 4; the description adds no parameter meaning because there is nothing to parameterize. No additional semantic detail 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 identifies the resource as the submarine-theater starter controller and explicitly equates it to get_starter with theater "sub", which distinguishes it from the sibling get_starter. However, "controller" is vague and the description never plainly states that it retrieves a starter configuration, so the purpose is clear mainly by reference.

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 parenthetical implies this is the submarine-theater variant and points to get_starter with a theater argument as the general form, but it never states when to choose this tool over get_starter, get_started, or other starter-related siblings. There are no exclusions or preconditions.

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

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

No annotations are supplied, so the description carries the full burden of behavioral disclosure. It names returned fields (status, theater, rules version, window, prize, entry rules) but never confirms the operation is a read-only listing, nor mentions result volume, pagination, or whether the data is public/unauthenticated.

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

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

It is a single short fragment with no wasted preamble, but it is grammatically incomplete and the word 'theater' appears twice ('theater previews ... theater'), muddying rather than tightening the field list. It is terse without being structured.

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 parameters and no output schema, the description is the only source of return-value information, and it partially delivers by enumerating fields. However, for a list tool it omits scope (all ladders? public only?), whether cups and previews are always included, and any ordering or shape details.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level value could be added beyond what the empty schema already conveys.

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 is a noun phrase ('The public ladder, sponsored cups and theater previews') with no verb, so it only implies that this tool lists these collections. The enumerated fields hint at the returned data, but it never explicitly states that it retrieves multiple ladders/cups and does not distinguish itself from siblings like get_ladder, get_cup, or list_matches.

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

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

There is no guidance on when to use this tool versus get_ladder, get_cup, or list_matches. The agent must infer from the word 'public' and the plural framing that this is a browse-all call, which is a thin basis for routing.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it omits ordering, time window for "recent", pagination behavior, and whether results are capped by the limit parameter. An agent cannot tell the safety profile (read-only is implied by "list" but never stated) or the response shape.

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 single sentence is free of padding and front-loads the resource, which is good. But it is so compressed that it reads as a label rather than a specification, and the optional-filter clause is the only structural element.

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

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

For a simple two-parameter read tool this could be adequate, but with no annotations, no output schema, and 0% parameter coverage, the description should clarify what "recent" means, what limit does, and what is returned. None of that 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?

Schema description coverage is 0%, so the description must compensate and only partly does: it explains that bot narrows results to one bot, but says nothing about limit, its semantics, default value, or maximum of 200. Half the parameters remain undocumented in both schema and description.

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?

"Recent matches, optionally for one bot" identifies the resource (matches) and the optional filter, which distinguishes it reasonably from the singular sibling get_match. However, the phrasing is a noun fragment with no explicit verb, and "recent" is never defined, leaving the purpose only partially pinned down.

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

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

There is no guidance on when to use this versus get_match (single match) or the various get_ladder/get_cup tools, and no mention of whether a bot argument is required for meaningful results. The only hint at usage is the word "optionally", which signals the filter is not mandatory but stops short of any 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.

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

With no annotations, the description carries the full burden and does so: unrated/no-rating-impact, two-game set with sides swapped, one-game mode on the pool, rate limits (5/min, 60/day), 7-day retention, returns match_id requiring get_match polling, and which inputs are rejected. That is unusually rich behavioral disclosure for a mutation-style 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?

Nearly every clause carries information, but it arrives as an unstructured run-on with a typo and a mid-sentence topic shift into "Bench practice", so the reader must re-parse to separate general behavior from pool mode. Front-loading the unrated/no-rating guarantee is a plus.

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, annotation-free tool with no output schema, the description covers the outcome (match_id), the follow-up procedure, and the constraints. Remaining gaps are the semantics of key, version, and theater, which an agent must infer from the schema alone.

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?

It adds real meaning beyond the 70%-covered schema: what vs accepts, that pool must be "bench-public" with index 0..15, that side/games control one-vs-two game behavior, and that the Bench member plays at a pinned version on Armor rules. It leaves key, version ("by label"), and the armor/sub theater enum largely unexplained.

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?

"Test one of your bots on a map seed you choose against any bot... without touching any rating" states a specific verb plus resource and distinguishes it from the rated ladder siblings. The core intent is unmistakable, though the run-on sentence and the garbled phrase "your bot is always a in the result" slightly blur the edges.

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 gives clear conditions for use (pick a seed, play a house style or Bench panel member, practice on the bench-public pool) and names the alternative flow via get_match polling. It also states two exclusions: benchmark seeds are refused and R6–R9 are private. What's missing is a direct "use X instead for rated games" routing to enrol_ladder.

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

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

With no annotations at all, the description carries the full disclosure burden, and it does disclose real behavior: a daily rate limit of 10 changes, the visible page effect ("Follow @name on X"), owner attribution, and the notable fact that battle.training never @mentions the handle. However, it omits authorization requirements for the key parameter, what happens on invalid or unverifiable handles, and whether removal is reversible.

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?

Roughly two sentences, front-loaded with the operation and its null-removal variant, then the rate limit and the @mention caveat. Every clause carries information, though the parenthetical "(null)" inside the verb list makes the opening slightly dense.

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 mutating tool with no annotations, no output schema, and a largely undocumented schema, the description covers effect, rate limiting, and removal semantics reasonably well. It still leaves the key/authentication parameter and error behavior unaddressed, which is a meaningful gap for a write operation.

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 only 33%: only x is documented ("@name", "name" or https://x.com/name; null removes it"). The description reinforces the null-removal semantics but says nothing about the bot identifier or the key parameter, which is entirely unexplained in both schema and description for a mutating call. The description does not compensate for the coverage 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-plus-resource framing: "Set, change or remove (null) the X handle of one of your bots." It is immediately clear what is being mutated and even what the value null does. It does not differentiate from the sibling tool set_operator_x, which performs the analogous operation for operators, 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?

Usage context is implied by "one of your bots" (ownership scoping) and constrained by the explicit rate limit "At most 10 changes a day per account." There is no explicit guidance on when to choose this over set_operator_x, nor on prerequisites such as what the key parameter must contain.

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 does disclose meaningful behavior: the value is surfaced as 'Operator: @name' on every bot page, null clears it, and the 10-a-day limit is shared with set_bot_x. It omits what permissions are required, what happens to the previous handle on change, and the response shape.

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-loaded with the verb and resource, and the quota note is tacked on efficiently. Phrasing is slightly tangled ('the account's own X handle: the operator behind the bots') but no sentence is wasted.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description supplies the essential context: what is set, where it appears, how to clear it, and a rate limit. The only real gap is the unexplained 'key' parameter and any auth expectations.

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 50% and the x_handle description already covers accepted formats and null removal, so the description's '(null)' note mostly restates the schema. The undocumented 'key' parameter is never explained in either place, so the description does not compensate for the coverage gap. 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?

The description states a specific verb and resource ('Set, change or remove the account's own X handle') and immediately clarifies the domain meaning: the operator behind the bots, distinct from a bot's own handle. That contrast with the sibling set_bot_x is explicit, so an agent can pick the right tool without reading either 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?

It gives clear usage signals – use it to set/change the operator handle, pass null to remove it – and flags the shared 10-a-day quota with set_bot_x, which is directly actionable for a caller choosing between the two. It stops short of explicit when-not-to-use guidance or stating prerequisites (e.g., account ownership/auth).

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 whole burden and does so well: it discloses the mutation semantics (null clears the wallet), the authentication model (account key only until claim, then owner-only), the payment rail (USDC on Base), and the timing rule ('a cup pays the wallet on file 48 h before it closes'), which tells the agent that changes cut off well before a cup ends. That is behavior beyond anything the schema or annotations convey.

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

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

Three short sentences, front-loaded with the action and the null-clearing behavior, then the auth constraint, then the payout timing consequence. No filler and no restatement of the name or title.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the definition covers purpose, auth, token/chain, clearing behavior, and payout timing. The only unaddressed points are what the call returns on success and whether already-scheduled cup payouts are re-read after a change, both minor given the 48-hour rule already stated.

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, and it largely does: 'clear with null' explains the null branch of the anyOf, 'EVM address' gives the semantics behind the 0x pattern, and 'account key' maps to the otherwise undocumented key parameter. It stops short of explaining what happens when the optional key is omitted, which is the one remaining 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?

Opens with a specific verb and resource ('Set (or clear with null) the account's wallet for cup prizes') and immediately qualifies the value domain ('an EVM address, paid in USDC on Base'). This clearly distinguishes it from the other setters in the family (set_bot_x, set_operator_x) and from read tools like whoami or get_cup.

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 states the operative precondition and the alternative path: works with the account key until a human claims the account, after which 'only the owner changes it at battle.training/account'. That is real when/when-not guidance, though the alternative is a web surface rather than a sibling tool, and it never explicitly says why an agent would want to set this (to receive prizes) beyond the phrase 'for cup prizes'.

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 does well: it discloses a smoke test (400 ticks vs the random house bot), the consequence of passing (becomes active ranked controller and matches start within seconds), and label reuse guidance. It omits what happens on failure, whether the previous version is retained, and what `key` authenticates.

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

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

Three short sentences, front-loaded with the purpose, then the behavioral consequence, then the practical label rule. No filler and 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?

The description covers the core upload-test-activate flow, which is the most important context for a 5-param, no-annotation, no-output-schema tool. But it leaves authentication (`key`), metadata (`notes`), and failure-handling behavior unspecified, which for a deployment tool is a meaningful 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% across 5 params, so the description must compensate. It explains `label` well (unique, format v1/v2) and implies `source` is JavaScript and `bot` is the controller owner, but `key` and `notes` are completely unexplained, leaving significant gaps.

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: uploading JavaScript source as a new controller version. An agent can distinguish this from create_bot or set_bot_x. It stops short of naming a sibling, so it's clear but not maximally differentiated.

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 one concrete usage rule—use a new label each time (v1, v2, ...)—which is helpful. However, it doesn't state when to upload a new version versus other approaches, or prerequisites like owning a bot or needing a key.

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 exist, so the description carries the full disclosure burden and does not meet it. It never states that this is a read-only lookup, whether it fails without a valid key, or what a caller without credentials should expect.

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 short, but the brevity comes from under-specification rather than economy: a fragment with no verb leaves the actual purpose unstated, so no reader gets the answer 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?

With no annotations, no output schema, and undocumented parameters, the description is the only source of meaning available and it delivers a six-word phrase. An agent cannot determine what is returned (account fields? bot list shape?) or how it behaves without a key.

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% for the single optional 'key' parameter, so the description needed to explain it. 'Current key' vaguely implies the parameter defaults to the active key, but the override behavior and whether it accepts a key belonging to another account are never spelled out.

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 text 'Account and bots for the current key' is a noun phrase with no verb; an agent must infer that this retrieves account and bot information tied to the active API key. It names the resources returned but never says the operation, and it does nothing to separate this from siblings like get_bot or controller_api.

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 when-to-use guidance, no mention of prerequisites, and no named alternative. The word 'current' hints at a self-identification use case but the agent is left to infer it rather than being told.

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