Skip to main content
Glama
Sign In
llm-sparring

llm-sparring

by 121Development
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Debate verdict

debate_verdict

End a debate and get a blind AI moderator's ruling on settled points, unresolved issues, and which side made the stronger case.

Instructions

End a debate and get a ruling from a fresh, blind GPT moderator that sees only the transcript, with the two sides relabelled A/B in random order and model names removed. Returns what is settled (and which side each point favours), what is still unresolved and what would settle it, and which side made the stronger case. Call this when all rounds are done, or earlier if the debate has stopped producing new arguments. Calling it again returns the same verdict. Report the result to the user even-handedly, including points that went against you.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "debate_id": "<debate_id>"
    },
    "name": "debate_verdict"
  }
}

Input Schema

NameRequiredDescriptionDefault
debate_idYesThe debate_id returned by debate_open.

Output Schema

NameRequiredDescriptionDefault
parsedYes
side_aYesWhich debater the moderator saw as side A.
settledYes
debate_idYes
unresolvedYes
stronger_sideYes
rounds_completedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.2/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: the moderator is blind, side ordering is randomized, model identities are stripped, and repeat calls return the cached verdict. That caching statement sits in mild tension with idempotentHint=false, though it reads as a caching note rather than a contradictory claim about write behavior. The description also states what the verdict contains (settled points with favoured side, unresolved points and what would settle them, stronger case).

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

Conciseness4/5

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

Front-loaded with purpose, then return shape, then invocation timing — a sensible order with little waste. The closing instruction about reporting even-handedly is more agent conduct than tool semantics, but it is one short sentence and does not crowd out the operational content.

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

Completeness5/5

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

An output schema exists, so return values need not be spelled out, yet the description still summarizes the verdict structure. It covers invocation timing, caching behavior, and the moderator's blinding — everything an agent needs to call this correctly at the end of a debate.

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

Parameters3/5

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

Schema coverage is 100% and the single debate_id parameter is already documented as coming from debate_open, so the description has little to add. It never mentions debate_id, but it does establish the cross-tool lineage implicitly through the workflow framing, so the baseline 3 applies.

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

Purpose5/5

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

States a specific action ("End a debate and get a ruling") plus the mechanism (a fresh, blind moderator seeing only the transcript with sides relabelled A/B and model names stripped). That detail makes it unmistakable against siblings like debate_turn or synthesize, which do not produce a terminal verdict.

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

Usage Guidelines4/5

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

Gives a clear trigger ("when all rounds are done") and an early-exit condition ("or earlier if the debate has stopped producing new arguments"). It does not explicitly name an alternative or exclusion, but for a terminal step in the workflow the decision boundary is clear enough.

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

Deploy Server

Other Tools