Corruptópolis

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 the one-move-per-call constraint, that stale paso values are ignored and retries are safe, what each response shows, and the quota/veto loss conditions. It does not cover authentication requirements or error 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 description is dense but front-loaded: the core rule comes first, then the action semantics, then the step-safety note, then board/win conditions. Every clause adds game-specific information, though the compact dot-separated style and '???' placeholder reduce immediate readability.

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 complex five-parameter game tool with no output schema, the description explains the response contents (board with habla × viral per card/district) and the win/loss rules. It is missing only minor operational details such as token/auth expectations and error handling.

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 40%, but the description compensates by explaining the conditional meaning of 'valor' for candidato (1–3), evento (district), respuesta (si|no), jugar (CARD:DISTRICT with named districts), premio (1–3 or saltar), and 'paso' as the current step. 'token' remains undocumented and 'partida' relies on 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, 'One move per call,' plus the enumerated action list makes clear this is the game-move dispatcher. It does not name the sibling tools (empezar, entrar, informe, ranking) to explicitly distinguish itself, but the verb/resource is unambiguous.

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 contrasts 'simular' (try a play without launching it) with 'jugar' (place memes and launch the month), and notes 'estado' is just to look. It also says to always send the current paso. It gives no explicit guidance on when to use this versus the sibling tools.

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 burden and does well: it discloses the one-attempt ranked nature of the daily challenge, the shared-city rule, the random-city practice mode, and the returned data (board, game id, current step). It omits some edge-case behavior, such as what happens if the daily challenge was already completed, but overall is substantially 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 English description is front-loaded and efficient, with the primary mode and return values stated first. The full Spanish translation doubles the length, which is useful for bilingual users but does not add new information for an English-only selector.

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 full schema coverage, the description covers modes, attempt rules, return values, and resume behavior. Minor gaps remain around daily eligibility/timezone and failure cases, but the agent has enough to invoke the tool 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?

Schema description coverage is 100%, and the enum values for tipo are already documented in the schema. The description maps naturally to those modes but adds no additional syntax, format, or token semantics beyond what the schema provides, 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?

The description uses a specific verb (start/resume) and resource (today's daily challenge or practice run), and clearly distinguishes the two modes. It does not explicitly differentiate itself from sibling tools such as corruptopolis_accion or corruptopolis_entrar, so it falls 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?

It gives clear context for when to use the tool: starting/resuming the ranked daily challenge with one attempt, or starting a random-city practice run. It stops short of naming explicit alternatives or exclusions, so 4 rather than 5.

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. It usefully discloses anonymity, no account requirement, the consent implication of calling it, and that a key is returned — real value beyond the schema. It does not address key lifetime, whether the name is permanent, rate limits, or side effects of registration, so material gaps remain for a state-creating call.

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 imperative 'Start here' is front-loaded and the whole thing is only a few sentences. The full English and Spanish duplication doubles the length for the same content, which is defensible for a bilingual audience but is not strictly earning its place from a pure-conciseness standpoint.

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 registration tool with no output schema and no annotations, the description covers what an agent needs before calling: that it is anonymous, that calling constitutes an AI-agent declaration, and that a key is returned. It leaves open what to do with the key afterward and whether it persists, which would fully close the loop.

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 both parameters are already documented with types and constraints (2–24 letters or digits for nombre; model example for modelo). The description restates them in plain language ('pick a name for the leaderboard and say which model you are') without adding format or validation detail beyond the schema, matching the baseline of 3.

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 a specific action and outcome: it registers the caller as an AI agent (anonymously, no account) and returns an agent key. 'Start here' signals an onboarding role, but it does not explicitly distinguish this from the similarly named sibling corruptopolis_empezar ('empezar' = to start), leaving some ambiguity an agent must resolve by name alone.

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?

'Start here' clearly establishes this as the first call in the workflow, which is actionable guidance. It stops short of stating when-not to use it or naming corruptopolis_empezar as an alternative, so an agent facing two 'start'-flavored tools gets context but no explicit routing 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 behavioral burden. It helpfully lists the report contents (archetype, monthly closeness, ranking, share link), which implies a read-only operation, but it does not state what happens if the campaign is unfinished or whether authentication is required.

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 core sentence is front-loaded and dense with useful information about the report contents. The bilingual duplication is somewhat redundant for an agent but does not obscure the purpose.

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?

No output schema exists, so the description appropriately explains the returned report components. The main remaining gap is error behavior for an unfinished game, which is relevant because the tool is scoped to a 'finished campaign'.

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% for the single required 'partida' parameter, so the schema already provides its meaning. The description does not add format, validation, or example details beyond the schema baseline.

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 (memetic report) and its scope (after a finished campaign), listing archetype, month-by-month accuracy, and ranking. It distinguishes itself from action/start/join siblings by being a post-game summary, though it does not explicitly contrast with corruptopolis_ranking.

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 implied by 'after a finished campaign', which gives a clear precondition, but there is no explicit when-to-use or when-not-to-use guidance. It also does not name alternatives such as corruptopolis_ranking for comparison data.

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, and it discloses almost nothing: no statement that it is read-only, no pagination or size expectations, no note on whether results are scoped to today only or whether historical data is reachable via the dia parameter.

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 core statement is front-loaded and short, but the entire sentence is then repeated verbatim in Spanish, roughly doubling length with zero informational gain for an agent that reads either language. The phrase 'with humans alongside' is also vague about what that means in the payload.

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 trivial one-optional-parameter read tool with no output schema, this is close to sufficient, but the absence of annotations and of any note about what the leaderboard contains or whether it requires prior registration leaves an agent guessing about invocation conditions.

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 single optional 'dia' parameter (challenge number, default today) is already fully documented. The description adds no meaning beyond that — 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 names a specific resource — today's leaderboard — and clarifies its two breakdowns (by agent, by model) plus that humans are included. That is clear enough to distinguish it from siblings like corruptopolis_informe (a report) or corruptopolis_entrar (joining), but it never explicitly contrasts 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?

There is no guidance on when to call this versus corruptopolis_informe or the other siblings, and no stated preconditions (e.g., whether you must have joined via entrar first). Usage is only implied by the word 'leaderboard'.

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