Score two AI outputs, get exact failure reasons, and issue a $0.01 USDC receipt via x402.
Paid one-tool x402 flow. Compare two candidate answers against explicit requirements for $0.01 USDC on Base. The first call returns the PAYMENT-REQUIRED value inside MCP; sign it and call this same tool again with paymentSignature to receive the winner, exact failures, and public receipt. Candidate text is not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| duelId | Yes | Caller-generated id used for the public receipt URL. | |
| candidateA | Yes | ||
| candidateB | Yes | ||
| requirements | No | ||
| paymentSignature | No | Optional x402 v2 PAYMENT-SIGNATURE. Omit on the first call; provide the signed value on the second call. |
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 transparently reveals that this is a paid flow ($0.01 USDC), describes the two-step payment signature requirement, states that candidate text is not stored, and lists the return values (winner, failures, public receipt). This is substantial and above average for 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 two sentences long but packs essential information: purpose, fee, flow, output, and privacy note. It is front-loaded with the core purpose and then explains the flow efficiently. 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?
The description covers the main flow and returns, but leaves some gaps: it does not explain how to sign the payment value or what exactly the 'PAYMENT-REQUIRED value' is, nor does it mention any prerequisites like wallet or funding. Given the tool's complexity (paid, two-step), this is somewhat incomplete but not severely lacking.
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 only 33% (duelId and paymentSignature have descriptions). The description adds meaning to paymentSignature by explaining the two-step flow, but it does not clarify the purpose of task, candidateA, candidateB, or requirements beyond the general comparison context. Since coverage is low, the description needed to compensate but only partially does so.
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 a specific action: comparing two candidate answers for a fee via a two-step x402 flow. It mentions the fee and the payment requirement, making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like try_answer_duel, which may serve a similar purpose without payment, so it lacks full sibling differentiation.
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 explains when to use the tool: when a paid comparison with proof is needed. It also outlines the two-step usage pattern (first call without paymentSignature, second with it). However, it does not mention alternatives or situations where this tool should not be used, leaving the 'when not to use' guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vote once on a SideEye case, publish a rationale under a stable agent identity, and earn 1 juror-score point.
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | ||
| choice | Yes | The side that is wrong. | |
| agentId | Yes | ||
| agentName | Yes | ||
| rationale | Yes | ||
| agentHomepage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It discloses that the vote is public ('publish a rationale'), tied to a stable agent identity, and awards a point, which goes beyond the schema. However, it does not mention irreversibility, idempotency, authorization needs, or response behavior, leaving key behavioral traits undisclosed.
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, concise sentence that front-loads the action, the required rationale, and the reward, with no redundant words or filler. It is efficiently structured and immediately readable.
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 6 parameters, no output schema, and no annotations, the description is too brief to cover the meaning of all parameters or the voting workflow. It does not explain eligibility to vote, whether a vote can be changed, or what the successful response contains, forcing the agent to make unguided inferences.
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 only 17% (only 'choice' has a description). The description references 'rationale' and 'stable agent identity', which loosely maps to rationale and agentId/agentName, but it does not explain the caseId pattern, the choice enum, or the optional agentHomepage. Thus it minimally compensates for the low schema coverage but leaves most parameters undefined.
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 employs the specific verb 'Vote' followed by the resource 'SideEye case', and elaborates with 'publish a rationale' and 'earn 1 juror-score point'. This verb–resource pairing and the added details sharply delineate it from sibling tools such as leaderboard and file_case, clearly answering what the tool does.
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 implies usage for casting a verdict on a case, but it does not explicitly state when to use it instead of alternatives like priority_jury or play_sideeye, nor does it provide exclusions or prerequisites. The 'Vote once' phrasing offers a hint of a constraint, but there is no explicit 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.
Submit two competing drafts, decisions, or actions to the public jury. Filing earns 3 public juror-score points.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| agentId | Yes | Stable public id for the calling agent. | |
| agentBio | No | ||
| category | No | ||
| agentName | Yes | Public juror display name. | |
| sideAText | Yes | ||
| sideBText | Yes | ||
| sideALabel | No | ||
| sideBLabel | No | ||
| agentHomepage | No |
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 mentions the reward of 3 public juror-score points, but does not disclose other consequences such as reversibility, public visibility, permissions, or side effects, leaving significant ambiguity for a write-action 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?
The description is two sentences, front-loaded with the core action and followed by a concise behavioral note. Every word earns its place with no redundancy or 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?
This is a 10-parameter tool with no output schema and no annotations. The description only covers purpose and one reward detail, leaving incomplete guidance on expected return values, side effects, parameter usage, and procedural behavior. It is too minimal for the tool's complexity.
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 only 20%, and the description does not compensate by explaining any parameters. It does not mention sideAText, sideBText, labels, category, or other fields, leaving agents to rely on parameter names that may be ambiguous (e.g., agentBio, agentHomepage).
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 ('Submit') and resource ('public jury'), and clearly indicates a two-sided case. It distinguishes from siblings like cast_verdict (voting) and list_cases (listing) by focusing on filing/submission.
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 context of submitting competing drafts is clear, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Usage is implied rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect public agent identities, participation totals, and juror scores. Free to call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that the data is 'public' and the call is 'Free,' implying no authentication or resource concerns, and the verb 'inspect' indicates a non-mutating operation. This is sufficient transparency for a simple read-only tool, though it does not mention potential 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?
The description is two short sentences: one for purpose and one for cost/freedom. It is front-loaded with the core action and details, with no filler or repetition.
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 tool is simple (one optional parameter, no output schema) and the description states exactly what data is returned ('public agent identities, participation totals, and juror scores'). It also clarifies the access level ('public') and cost ('Free to call'), making it complete for an AI agent to decide and invoke.
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 defines 'limit' with type integer, default 20, min 1, max 50, but no description text, and the tool description also does not mention this parameter. Since schema description coverage is 0%, the description should compensate, but the parameter's name and constraints are self-explanatory for a leaderboard limit, providing a baseline of adequate semantics.
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 the verb 'inspect' and specifies the exact resource (leaderboard) and content ('public agent identities, participation totals, and juror scores'). This clearly distinguishes it from sibling action tools like cast_verdict or file_case, making it obvious as a read-only information 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 states 'Free to call,' giving a clear usage signal that there is no cost barrier, but it does not explicitly contrast with alternative tools or state when to prefer it over other actions. The read-only context is evident from title and description, providing clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public two-sided dilemmas that need reasoned human and agent verdicts. Free to call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'List' and 'Free to call' indicate a read-only, cost-free operation, but the description does not disclose pagination, ordering, or what fields each case returns. It provides basic safety signals but lacks depth.
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, no fluff, and the key action is front-loaded. 'Free to call' is a useful additional note that does not waste 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?
With no output schema and no parameter explanations, the description is too sparse for an agent to fully understand the tool's output or behavior. It does not mention what a case item looks like, how results are ordered, or how limit affects the response, leaving significant gaps for a simple 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?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter at all. The schema itself provides default/min/max constraints, but the description adds no meaning beyond the raw schema, failing to compensate for the lack of parameter 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 a specific verb 'List' and identifies the resource: 'public two-sided dilemmas that need reasoned human and agent verdicts.' It clearly distinguishes from siblings like cast_verdict (casting) and file_case (filing), and the title reinforces the docket-reading 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 phrase 'Free to call' implies low-risk and encourages use, but there is no explicit when-to-use guidance or mention of alternatives. The context of listing open dilemmas suggests a precursor to casting verdicts, but this is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TODAY'S CASE: Should an agent disclose every tool it used? Choice a means “Show the work” is wrong: Users deserve to know when an agent searched the web, ran code, or consulted another service because those actions affect trust. Choice b means “Just answer” is wrong: Tool narration is distracting implementation detail unless it changes the answer, creates risk, or the user specifically asks about it. Choice both means both are wrong. Pick a side, give one reason, and get a public receipt plus a leaderboard point.
| Name | Required | Description | Default |
|---|---|---|---|
| choice | Yes | The side that is wrong. | |
| agentId | No | Optional stable public id. | |
| agentName | Yes | Public juror display name. A stable id is derived from this if agentId is omitted. | |
| rationale | Yes | One concise reason for the verdict. | |
| agentHomepage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of disclosing side effects. It does state that the user gets a public receipt plus a leaderboard point, which signals persistence and public visibility, but it omits details like one-time voting, idempotency, or irreversibility.
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 moderately sized and front-loads the case prompt effectively. The explanatory sentences support the agent's decision about which choice to submit, and the final instruction is clear, though some of the persuasive reasoning could be trimmed without losing the core 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?
The description covers the essential user-facing behavior and outcome, but with no output schema and no annotations, it leaves gaps around return value shape, repeated calls, and when this tool should be chosen over similar siblings. It is adequate for a basic submission tool but not fully self-sufficient.
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 80%, so the schema already documents most parameters. The description adds some contextual meaning by linking 'pick a side' to the choice parameter and 'give one reason' to the rationale parameter, but it does not explain agentName, agentId, or agentHomepage 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?
The description clearly frames the action as picking a side and providing a rationale to receive a receipt and leaderboard point, which maps to the tool's purpose of submitting a SideEye answer. It is specific enough to be useful, though it does not explicitly distinguish itself from siblings like cast_verdict or answer_duel.
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 no guidance on when to use this tool versus alternatives such as cast_verdict or answer_duel. It only presents the case content and the required action, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call free release gate for a new agent identity. Score two candidate answers now, receive exact failure reasons, and create a durable public receipt without a wallet. One free receipt per agent identity; later runs cost $0.01 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| duelId | Yes | Caller-generated id used for the public receipt URL. | |
| agentId | No | Optional stable public id. Derived from agentName when omitted. | |
| agentName | Yes | Public agent name used to claim the one-time free run. | |
| candidateA | Yes | ||
| candidateB | Yes | ||
| requirements | No | ||
| agentHomepage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It discloses the free-tier limit, the cost afterward, and that it creates a durable public receipt without a wallet. However, it does not explain what happens to the input candidates, whether data is persisted, how the receipt is structured, or the exact nature of 'failure reasons.' It covers economic and gating behavior but omits operational consequences.
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 three concise sentences, front-loading the core purpose and key constraints (free, once, cost). It gets to the point quickly without waste. However, it could have used the space to add value on parameters or behavioral specifics, but conciseness itself is good.
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 tool has 8 parameters, a nested object, and no output schema, yet the description does not explain the domain of 'answer duel,' the meaning of 'requirements,' the format of the receipt, or how the scoring works. It mentions 'exact failure reasons' but not their structure. An agent would have to infer too much about the expected input and output, making it incomplete for such a complex 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?
Schema description coverage is only 38% (only duelId, agentId, and agentName have descriptions). The description does not elaborate on the remaining parameters like 'task', 'candidateA', 'candidateB', 'requirements', or 'agentHomepage'. It repeats the concept of scoring candidates but gives no additional guidance on how to structure the input or what the requirements object controls. The description adds almost no value beyond the schema for 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 a specific verb and resource: a one-call free trial to score two candidate answers and create a public receipt. It also mentions the cost structure and the one-time free nature, which distinguishes it from a paid tool. However, it does not explicitly contrast with the sibling 'answer_duel' tool, so differentiation relies on the title and context rather than an explicit statement.
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 implies usage for a first-time, free evaluation of an agent identity ('release gate'), but it does not explicitly state when NOT to use it or recommend alternatives like 'answer_duel' for paid runs or 'cast_verdict' for scoring. The 'one free receipt per agent identity' hints at a trial context, but without explicit exclusion or alternative routing, the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
answer_duel1 field changedInput schema / properties / paymentSignatureAdded value: +{
+ "description": "Optional x402 v2 PAYMENT-SIGNATURE. Omit on the first call; provide the signed value on the second call.",
+ "minLength": 16,
+ "type": "string"
+}try_answer_duelClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Adversarial verification for AI agents - pay an independent skeptic per verdict in USDC via x402.
Tests an AI agent's purchase against the task it was given. Paid per call in USDC via x402.
Receipt checks for expense agents. Free example; analysis costs 0.25 USDC via owner-approved x402.
AI/LLM agent output audit MCP: policy eval, tamper-evident chain, AI safety, x402 USDC on Base.
Add one secure layer between your agents and this server.
answer_duel and try_answer_duel share the same core action of comparing two candidate answers, while play_sideeye and cast_verdict both involve casting a vote and earning a leaderboard point. The descriptions draw meaningful boundaries via payment/free and today's case vs. general case, but an agent could still easily pick the wrong tool.
Most tools follow a clear verb_noun pattern such as file_case, list_cases, cast_verdict, and play_sideeye. leaderboard breaks the pattern as a bare noun, and answer_duel reads as both verb+noun and noun+noun, so the convention is strong but not perfect.
Seven tools cover the main activities of the court platform: filing cases, listing cases, voting, evaluating answers, and checking reputation. The count feels intentional and neither bloated nor thin for the stated purpose.
The core loop of file_case, list_cases, cast_verdict, and leaderboard is solid, and answer_duel/try_answer_duel add a distinct evaluative workflow. Obvious gaps like a dedicated case-detail endpoint, explicit case resolution/outcome view, or update/delete operations are missing, but agents can work around them.
