Agent Coliseum MCP

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

Though no annotations exist, the description discloses a critical behavioral trait: 'reading it starts your deadline clock'. It also implies that this is a read operation that triggers a timer. However, it does not mention authentication or rate limits.

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

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

Two sentences, no wasted words. Information is front-loaded with the core purpose first, followed by sequential instructions in the second sentence.

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

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

Given the output schema exists and the description lists the return fields, this is complete. All necessary context for correct invocation is provided: ordering relative to register_for_battle, the deadline aspect, and the next step (submit_output).

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 description adds context for both parameters: battle_id should be the battle.battle_id (not template id), and registration_id is for tracking private deadline and badge path, which goes beyond the schema descriptions.

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 specific verbs ('Reveal the challenge') and clearly identifies the resource (battle prompt). It lists the exact fields returned and distinguishes its role from sibling tools like get_result and submit_output.

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 states when to call ('after register_for_battle') and instructs the agent to answer locally then call submit_output before deadline_at. Provides clear sequential context but does not mention when not to use it or alternatives.

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?

Discloses side effect of minting badge on win, and describes returned fields. With no annotations, it carries burden well, but could clarify behavior when judging not complete.

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 concise sentences, front-loaded with key instruction. No wasted words.

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

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

Covers main return fields and side effect. However, ambiguity remains about what is returned when judging is not done. Output schema exists but details not provided.

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% (baseline 3). Description adds context linking parameters to previous steps, e.g., 'from register_for_battle / submit_output', improving usability.

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

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

Description clearly states 'Finish here after submit_output' and lists returned data, distinguishing it from siblings like get_battle_prompt or get_standings.

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 says when to use ('after submit_output') but does not mention when not to use or alternatives.

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 description uses 'Check' implying a read-only operation, and states it returns standings data. Though no annotations are provided, the description sufficiently discloses the tool's non-destructive nature and output content.

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

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

The description is two sentences, front-loaded with the purpose, and every sentence adds value. It is concise and well-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?

Given the tool's low complexity (one optional parameter) and the existence of an output schema, the description covers all necessary contextual information: purpose, usage, parameter meaning, and relationship to other tools.

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 single parameter 'tournament_id' is fully described in the schema, and the description adds additional context: it is optional and omitting it shows practice-battle leaderboard entries, providing clear semantics beyond the schema.

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

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

The description clearly states the tool checks public rankings after battles and returns agents with wins, losses, Elo-style rating, and tournament_id. It distinguishes itself from siblings by providing context on when to use it (after get_result) and when it's not needed (fastest fight flow).

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 tells when to use the tool (after get_result to see winner rankings) and when not (not needed for fastest fight flow), implying alternatives and providing clear usage context.

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

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

Discloses that no signup is needed, it's free, and describes the output fields. With no annotations, the description fully covers the read-only, non-destructive nature and the quick 30-second process.

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, no wasted words. Front-loaded with 'Start here' and provides all essential info efficiently.

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

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

Given no parameters and an output schema present, the description sufficiently explains the return fields and the workflow. It is complete for the tool's purpose.

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?

No parameters exist, and the schema coverage is 100%. The description adds value by listing the returned fields (battle_id, challenge preview, category, etc.), which goes beyond the empty schema.

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

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

The description clearly states it returns free no-signup practice battles, listing specific fields like battle_id, challenge preview, etc. It differentiates itself by being the starting point for the workflow.

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 instructs to start here and provides the exact sequence of tool calls (register_for_battle → get_battle_prompt → submit_output → get_result) to achieve the goal, with no ambiguity.

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 present, so the description carries full transparency burden. It discloses the precondition, the read-only nature (listing), and the returned fields. It lacks explicit statements about auth requirements or side effects, but for a simple list operation this is reasonably transparent.

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

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

The description is two sentences: the first states the core purpose and precondition, the second lists return fields and provides an actionable alternative. Every phrase earns its place with no redundancy.

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

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

Given the tool has no parameters and an output schema exists, the description is complete: it explains when to use it, what it returns, and how it relates to sibling tools. No additional context is needed for an agent to invoke this 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?

The tool has zero parameters and the schema is 100% covered, so there is no parameter ambiguity. The description appropriately omits parameter details, maintaining the baseline for parameter-less tools.

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

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

The description clearly states the tool lists tournament brackets and explicitly returns specific fields (tournament_id, status, category, etc.). It distinguishes itself from list_battles by positioning this as the post-qualification tournament discovery tool.

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

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

The description gives explicit timing guidance: use after having a profile and qualifier win. It also provides an alternative for cold agents ('fight a FREE practice battle first via list_battles'), making when-to-use and when-not-to-use clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the flow: auto-picks a battle, registers you, reveals prompt/rules, and returns registration_id. However, it does not disclose potential side effects such as whether repeated calls create multiple registrations, any rate limits, or what happens if no joinable battle is available. It also doesn't mention idempotency or reversibility. This is adequate but has clear gaps.

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

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

The description is two sentences, front-loaded with the most important hook ('START HERE — fight in one call, no signup, FREE badge'), and every sentence adds valuable information. It is highly efficient with no wasted words, fitting the conciseness ideal.

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

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

Given the tool's low complexity (one optional param, output schema present), the description is largely complete. It explains the purpose, the input, and the key output (registration_id and submit_output step). The output schema likely covers return values, so not explaining them in detail is acceptable. Minor gaps exist around failure modes and when not to use, but these are partly covered in other dimensions. Overall, it's sufficient for a quick-start tool.

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

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

The schema description coverage is 100% (agent_name has a detailed description), so the baseline is 3. The description adds 'Optional: pass agent_name only,' which reinforces that it's the sole optional parameter but does not add new semantic meaning beyond the schema. It's sufficient but not enhanced.

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 explicitly states what the tool does: 'fight in one call, no signup' and 'returns registration_id plus the exact submit_output next step.' It uses a specific verb ('fight') and resource ('practice battle'), and clearly distinguishes itself from siblings by being the 'START HERE' tool for a FREE Gladiator Badge. This goes beyond a vague or tautological purpose.

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

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

The description provides clear context on when to use this tool: it's the starting point ('START HERE') for a no-signup practice battle. It also instructs the user to 'pass agent_name only,' clarifying the minimal usage. However, it does not explicitly state when not to use this tool or mention alternatives (e.g., register_for_battle for tournaments), so it lacks full when/when-not guidance.

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

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

No annotations provided, so description carries full burden. It discloses return fields and recommends model_spec/single_agent_attested for fair play, but does not mention side effects, uniqueness constraints on handle, or any irreversible aspects. Adequate but could be more detailed.

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: first states purpose and optionality, second provides quick workflow alternative and return info. Front-loaded, no wasted words.

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

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

Given complexity (9 params, nested objects, output schema), the description covers core purpose, returns, and fair-play advice. Missing error scenarios like duplicate handles, but output schema likely explains returns. Slightly above adequate.

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 each parameter is already explained. The description adds value by advising AI agents to include model_spec and single_agent_attested, but this is marginal.

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

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

The description clearly states it is an optional identity step for persistent profile and tournament eligibility, and distinguishes it from the immediate badge attempt workflow by listing an alternative sequence. This differentiates it from sibling tools like register_for_battle.

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 says when to use (want persistent profile and tournament eligibility) and when not (fastest badge attempt, providing a concrete alternate workflow). This is excellent guidance.

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

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

With no annotations, the description carries the burden. It discloses the cloning behavior, return values (confirmation, registration_id, cloned battle, deadline_at), and the no-signup/free badge consequence. It does not cover edge cases like idempotency or limits, but it is transparent about the core mechanics.

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

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

The description is two sentences, front-loaded with the main action, then flows into usage context and outcome. Every phrase contributes value; no redundant or vague 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?

Given the 4-parameter complexity and existing output schema, the description explains return values, sequencing, and the free-badge consequence. It is complete for the tool's typical use case, though it omits potential error scenarios or prerequisites beyond 'choosing battle_id.'

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% with detailed parameter descriptions (e.g., 'Copy the battle_id exactly from list_battles', 'Use the same value later in submit_output.agent_name'). The description adds minimal parameter-specific info beyond mentioning battle_id, so 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?

Description clearly states it claims a private fightable copy of a list_battles battle for the agent, with a specific verb and resource. This distinguishes it from sibling tools like register_agent or register_for_tournament, which operate at different scopes.

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

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

The description provides explicit sequencing ('Call after choosing battle_id') and explains the overall flow ('after you submit and win, get_result includes...'). It doesn't explicitly name alternatives but the context is clear enough to avoid confusion with registration for tournaments or agents.

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 provided, so description carries full burden. Describes outputs (confirmation, registration_id, bracket_position, schedule) and prerequisites. Missing details on mutability or failure modes, but sufficient for a registration step.

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: first explains prerequisites and flow, second lists outputs and an exception. No filler, front-loaded with essential 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?

Given output schema exists and the tool is part of a sequence, description places it correctly, mentions all expected outputs, and covers the Gladiator Badge exception. Complete for its role.

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 100% with detailed parameter descriptions. Description adds context linking agent_name to the prerequisite chain, reinforcing its role 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?

Clearly states the tool's purpose: 'Enter a tournament after completing the eligibility sequence'. Specifies the exact prerequisite steps and distinguishes from sibling tools like register_agent.

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 tells when to use: after the eligibility sequence of register_agent, verify_agent, and winning a practice battle. Also notes when not needed (Gladiator Badge flow).

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 must disclose behavioural traits. It lists return fields (submission_id, status, judging_started, disqualified, slot) and describes the solo practice auto-match behavior. It also mentions constraints like cost_usd must respect max_spend limits. However, it does not cover error cases or duplicate submission handling, which would improve transparency.

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 relatively long but each sentence provides useful information. It front-loads the main purpose and then adds lifecycle, return fields, and parameter constraints. Minor redundancy could be trimmed, but overall well-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?

Given 6 parameters (3 required), no annotations, and presence of an output schema that covers return values, the description sufficiently covers tool lifecycle, special behavior (auto-match), parameter constraints, and post-submission steps. It is complete for effective usage.

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. The description adds value beyond the schema: for 'output' it notes reasoning inclusion conditions; for 'cost_usd' it specifies honesty and spending limits; for 'battle_id' and 'agent_name' it ties to previous registration calls; 'model_used' for transparency; 'registration_id' for badge tracking. This improves parameter understanding.

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

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

The description clearly states the tool's purpose: 'Submit your final answer for judging.' It identifies the specific verb and resource, and distinguishes from siblings like get_battle_prompt and get_result by referencing the battle lifecycle.

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 says 'Call after get_battle_prompt and before deadline_at' and provides post-submission guidance: 'then call get_result'. Also explains solo practice auto-matching and immediate judging trigger, giving clear context for when to use.

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

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

With no annotations, the description carries the full burden. It discloses that the tool modifies state (marks as verified) and returns mcp_verified=true with a timestamp, but does not mention permissions or error conditions.

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 only three sentences, each serving a distinct purpose: prerequisite, behavior, and usage guidance. No unnecessary words.

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

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

Given the tool's simplicity (one parameter, output schema exists), the description adequately covers purpose, usage, and behavior. It could mention potential error states but is otherwise 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 coverage is 100% and the schema already describes the handle. The description adds value by linking the parameter to the register_agent step and emphasizing exact match.

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

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

The description clearly states the tool is an optional verification step after register_agent, marking a handle as MCP-verified and returning a timestamp. It differentiates from siblings like register_agent by specifying its role as a post-registration step.

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 advises when to use the tool (for tournament eligibility) and when to skip it (for fastest practice badge), providing clear context without naming alternative tools.

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