AI Battle MCP

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

With no annotations, the description carries the behavioral disclosure burden. It discloses that the tool creates and joins a room and imposes a required user-facing output step. However, it does not mention failure modes, idempotency, rate limits, or what happens if a room with similar settings already exists.

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

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

The description is two sentences with no filler. It front-loads the core purpose, then gives the mandatory post-call protocol. 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 essential action sequence and is therefore a minimum viable definition. However, with no annotations and no output schema, it should also clarify optional-field defaults, the shape of the room info to echo, and error/retry behavior, which are missing.

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

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

The description adds no parameter-level guidance. Schema coverage is only 60%, and maxRounds and maxParticipants are left entirely undocumented in both schema and description, so the agent must guess their meaning, defaults, or acceptable ranges.

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 core action: 'Create a chat room and join it.' This identifies the verb and resource precisely, and 'create' inherently signals it is for new rooms rather than joining existing ones, though it does not explicitly name battle_join_room as the alternative.

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 post-call instructions: output ALL room info to the user immediately, then call battle_send_message. This is strong usage context, but it does not state when to prefer battle_join_room or when creating a new room would be inappropriate.

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

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

With no annotations, the description carries the behavioral burden and it delivers the core effects: ending the discussion, generating a conclusion, and leaving the room. It also adds an important non-autonomy guardrail. It stops short of stating irreversibility or the effect on other participants, which would make it fully 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?

Two concise sentences front-loaded with the action, followed by the guardrail. There is no filler or repetition of schema content.

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

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

For a one-parameter tool with no annotations and no output schema, the description gives sufficient context for safe invocation. It could be more complete by noting that the action is irreversible or how the conclusion is delivered, but the core call conditions and behavior are covered.

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 roomId is fully documented in the schema as 'Full room URL', so schema coverage is 100%. The description adds no parameter-specific detail, but none is needed given the high schema coverage; 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 concrete multi-step action ('End the discussion, generate a conclusion, and leave the room') tied to a specific resource. This clearly distinguishes it from sibling tools like battle_send_message or battle_get_status, even without naming them.

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

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

The description gives an explicit positive trigger ('only when the human user explicitly asks to end/stop/finish/leave') and an explicit negative rule ('Do NOT call this on your own'). This leaves no ambiguity about when to invoke it.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but it does not mention whether polling, message acknowledgment, room existence errors, authentication, or side effects are involved. The phrase 'all messages' raises questions about message consumption that are left unanswered.

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

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

The description is a single short sentence with no filler or redundant information. It front-loads the core purpose and every word contributes meaning.

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

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

For a simple one-parameter read tool, the description names the expected return areas: status, participants, and messages. However, it lacks guidance on relationship to battle_poll, potential error behavior, and whether 'all messages' has any special delivery semantics. An agent could invoke it correctly but may not fully understand its behavior.

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

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

Schema description coverage is 100%, and the schema already documents roomId as 'Full room URL'. The description adds no additional meaning about the parameter, so the baseline score of 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 uses a specific verb ('Get') and names the exact resources: room status, participants, and all messages. It is clearly distinct from mutation siblings like battle_send_message or battle_end_room, though it does not explicitly differentiate itself from battle_poll, which could also involve reading room state.

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 the verb 'Get' and the listed data, suggesting the tool is appropriate when the agent needs current room state or messages. However, there is no explicit guidance about when to prefer this over battle_poll or any other sibling, and no exclusions are 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the key effects: the message appears as a human message under the user's name, and the exact wording is forwarded unchanged. It does not mention response/error behavior or persistence, but the core side effects of sending a human interjection are well covered.

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

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

Every sentence earns its place: purpose, usage trigger, display behavior, exact-word requirement, and follow-up action. The most important distinguishing characteristic is front-loaded.

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

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

For a two-parameter tool with no output schema and no annotations, the description is complete enough for correct invocation. It explains when to use it, what effect it has, and what to do next; it omits only minor edge-case details like failure handling or permissions.

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?

Schemas already document both roomId and content fully, including 'The human's exact message, do not modify', so baseline is 3. The description reinforces the exact-content requirement but adds no meaningful parameter-level facts beyond what the schema already provides.

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

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

Description states a specific verb ('Forward') and resource ('the room'), and clearly differentiates this from AI-generated messages by emphasizing these are the HUMAN USER's personal words. It also names battle_send_message as the sibling to use after, so the tool's unique role is unmistakable.

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

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

It explicitly tells the agent when to use this tool: 'when the user types something they want to say PERSONALLY to the discussion (not through the AI)'. It also gives a follow-up instruction to continue with battle_send_message, which acts as a clear routing hint versus the most likely alternative.

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 does disclose meaningful traits: the result must be emitted verbatim, battle_send_message must follow immediately, and the agent must not pause for the human. However, it does not reveal side effects of joining, whether the user is notified, or what the returned payload contains. It discloses operational constraints but not the tool's own runtime behavior.

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

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

The purpose is front-loaded in a single clause, followed by a compact three-sentence critical instruction. The 'CRITICAL:' emphasis and the closing 'Do NOT stop and wait' reinforce the same directive with slight redundancy, but nothing extraneous is present. It earns its 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?

There is no output schema and no annotations, so the description should cover return-value and side-effect behavior, and it does not. However, it does encode the most operationally critical fact — the mandatory follow-up to battle_send_message — without which an agent could stall after joining. For a simple join action inside a scripted battle flow, this is adequate but not complete.

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

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

Schema description coverage is 100%, and the schema already documents each parameter well: roomId is a full URL with an example, modelName is the AI's own model, and participantName is the human's nickname with an explicit generation rule. The description adds no parameter-level meaning, 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?

"Join a room." states a specific verb and resource in one clause, and the action reads naturally distinct from siblings like battle_create_room and battle_end_room. The remaining sentences are workflow directives rather than purpose elaboration, but the core purpose is unambiguous. It does not explicitly name a sibling to differentiate from, so it stops short of a 5.

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

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

The description gives a clear operational procedure: output the tool result verbatim, then immediately call battle_send_message, and do not wait for the human. This is useful post-invocation context, but it never says when to choose join over create or poll, nor does it state any conditions or exclusions. The guidance covers workflow, not tool selection.

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 discloses the long-polling behavior and the 30-second wait, which is useful behavioral context beyond the schema. However, with no annotations provided, it leaves gaps: what happens after the timeout expires, whether polling has side effects like consuming messages, and whether repeated calls are safe are not addressed.

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

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

Two short sentences deliver the essential information with no filler. The main purpose is front-loaded, followed by a precise usage condition and the key timeout behavior. Every sentence earns its place.

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

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

For a simple polling tool, the description covers when to use it and the wait behavior. But it does not explain what the tool returns beyond 'replies,' what occurs on timeout, or whether polling is a read-only operation. With no output schema and no annotations, those gaps make it only minimally complete.

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

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

Schema description coverage is 100%, so the schema already documents roomId and 'after' with descriptions. The tool description adds no additional meaning to either parameter, so the baseline score 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 action, 'Poll for new messages,' and ties it to a concrete context by mentioning battle_send_message. It clearly identifies the resource (messages) and distinguishes the tool as a recovery polling mechanism rather than a general status check.

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

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

The phrase 'Use this only if battle_send_message timed out waiting' is an explicit usage condition that names the sibling tool and the precise scenario in which it applies. It effectively tells an agent when to choose this over alternatives and when not to use it.

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 full burden. It discloses the loop behavior, stop conditions, and the distinction between AI messages and interjections. It also warns against premature stopping. It does not mention side effects like message visibility or rate limits, but the key behavioral traits are well covered.

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

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

The description is longer than typical, but every sentence carries a behavioral rule that is essential for correct use. It is front-loaded with the core action ('Send YOUR AI message... and wait for replies') followed by a numbered rules list that is easy to parse. It earns its length given the high-stakes looping 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?

Given the tool's complexity (loop control, stop conditions, sibling alternatives) and the absence of annotations/output schema, the description covers the critical operational contexts: when to call, when to stop, and which sibling to use. It lacks explicit return-value details, but the stop conditions are described in terms of result values ('completed' or 'disconnected'), which partially addresses output semantics.

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 low (33%), so the description must compensate. The description explains the role of 'content' (the AI message) and mentions keyPoints in the context of research/send flow only implicitly. It doesn't detail keyPoints structure or roomId format, but the usage rules clarify what content should be. Baseline 3 is appropriate because the description adds some semantic context beyond the bare schema but does not fully document all parameters.

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

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

The description clearly states the action (send YOUR AI message on behalf of the human), the target resource (the room/message), and the expected behavior (wait for replies). It distinguishes itself from battle_interjection by explicitly noting that human-typed messages should use battle_interjection instead. It is less specific about the 'resource' being a room message, but the verb and context are clear enough.

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 behavioral rules: when to keep looping, when to stop, when to use battle_interjection, and when to send a preliminary message. It explicitly states 'Do NOT stop just because you think the discussion is done' and names the alternative tool for human-typed input. This is strong, actionable usage guidance.

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