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

With no annotations at all, the description carries the full burden and does so well: it enumerates the return payload (remark, accepted_items, effects, new_deal), explains the renewal row semantics (offered end vs final_turn_offered), and discloses the multi-leader queue behavior (still_pending, next, gate). This is behavioral context an agent could not derive from the empty schema.

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 action and the sibling routing are front-loaded in the first two sentences. The remainder is dense but information-bearing, covering returns and the queue/gate flow. A few clauses are syntactically heavy (the parenthetical on current_deals), which costs it the top mark.

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 must supply both the safety/behavior profile and the return shape — and it largely does. Remaining gaps are failure modes (e.g. what happens if the deal was already withdrawn) and any preconditions, but coverage of the success path and the pending-leader gate is strong.

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 takes zero parameters, so the baseline is 4 per the rubric. There is nothing for the description to clarify or compensate for on the input side.

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?

Opens with a specific verb+resource ('Accept an incoming trade already on the table') and immediately anchors to the sibling that surfaces it (incoming_deal). It also explicitly excludes the sibling it is not ('Does not construct a new deal'). The distinction from propose_deal is stated outright.

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 use this tool (an offer already on the table), when to use the alternative (propose_deal 'To make an offer of my own'), and gives a routing rule for the pending-leader case (answer the next screen, no discussion() read needed). Nothing is left to inference.

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 burden, and it delivers the key non-obvious trait: the request remains acceptable server-side even after dismissal/decline. It also points to diplomacy()/IsDoF as a way to verify the effect, though it does not state permission requirements or whether acceptance can be undone.

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?

Front-loads the action and the identifying state, then adds the edge-case behavior and a verification hint. Dense and mostly earned, though the internal state name and API reference add some jargon weight.

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, no-output-schema tool with no annotations, the description covers the action, the non-obvious server-side persistence, and how to confirm the result. The only real gap is the semantics of player_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 0% and the single player_id parameter is undocumented. The description implies the target is the leader who sent the proposal, but never says how to obtain or format player_id, so it only partially compensates for the coverage gap.

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?

States a specific verb (Accept) and resource (a pending Declaration of Friendship proposal), and pins down the exact server-side state (turn_digest's leader_message with state DISCUSS_WORK_WITH_US). An agent can distinguish it from propose_friendship, respond_discussion, and accept_deal without opening a schema.

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?

Gives a clear condition for use (a pending DoF proposal exists) and explicitly notes it still works after the dialog was dismissed/declined, which is a non-obvious usage case. It stops short of naming the sibling tools an agent should prefer when the proposal is not a friendship offer.

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 the blocking trigger and the option source, but it does not describe the effect of adding a belief, whether the choice is permanent, or validation 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 a single front-loaded sentence with no wasted words. The trigger condition comes first, followed by the required action and source.

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 low-complexity one-parameter choice tool with no output schema and no annotations, the description provides the key context: when to invoke it and where to get valid input. It is nearly complete, though side-effect details are absent.

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 there is no enum, so the description must compensate. It does by directing the agent to obtain the belief value from available_beliefs(kind="reformation"), though it does not specify the exact string format expected.

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 trigger and action: when turn_status shows the blocking Reformation status, pick one belief from available_beliefs(kind="reformation"). This distinguishes it from the sibling available_beliefs, which only lists options. It could be slightly clearer that the selected belief is added, but the meaning is evident.

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 an explicit when-to-use condition tied to turn_status and names the correct source for valid choices, available_beliefs(kind="reformation"). This is precise enough that an agent can route correctly without inference.

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 and does well: partial-update semantics, explicit clear operations (target={} clears the target, review={} clears the triggers), note persistence in history, the returned 'previous' values, and a cost hint ('One game read'). It omits error/auth behavior and any failure modes, keeping it short of a 5.

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?

Front-loaded with the core in-place/partial semantics, then the usage cases, then the return and cost. It is appropriately sized, though the parenthetical clarifications are dense and the 'review as in assign' clause reads awkwardly.

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 9-parameter mutation tool with no annotations and no output schema, the description covers most fields, the clearing rules, the return value with `previous`, and the cost. Gaps remain around assignment_id semantics and error/edge behavior, but an agent has enough to invoke it 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 coverage is 0% and there are 9 parameters, so the description must compensate — and it does, defining role, purpose, done_when, review, note, and the replace-vs-clear semantics of unit_ids/city_ids/target beyond anything the bare schema conveys. The replacement/list-overwrite rule is exactly the kind of meaning the schema lacks.

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?

States a specific verb and resource — 'Change an active assignment in place' — and nails the scope with 'only the fields given change'. It implies the create/close counterparts (assign, close_assignment) by referencing 'as in assign', so an agent can tell it apart from siblings without opening a schema.

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?

Gives concrete trigger conditions: 'Use it when a unit was upgraded (new id), a site moved, or the review turn passed and the plan still holds.' That is a clear when-to-use, and the 'as in assign' reference implies the create alternative, but there is no explicit when-not or named-alternative routing.

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 and does well: it discloses that the button's real handler runs (side effects), that the window closes, and that the call may return `discussion_pending` because some answers trigger an AI leader response. It omits error/failure behavior and permission requirements.

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?

Three tight, front-loaded sentences with no filler; the action, side effect and return value each occupy their own clause. Dense but efficient.

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 single-param tool with no output schema and no annotations, the description covers the action, its side effect, the return sentinel, and the parameter's format/origin. The remaining gap is failure modes, which is minor here.

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 0%, so the description must compensate, and it does: 'button' is clarified as a 1-based id sourced from generic_popup. That is exactly the indexing and provenance information an agent needs, though it could note valid 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?

Specific verb+resource: 'Press one button ... of the open generic confirmation', and it names the sibling (generic_popup) that supplies the button id. An agent can distinguish this from sibling popup tools without opening a schema.

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 'of the open generic confirmation' implies the prerequisite that a generic popup must already be open, but there is no explicit when-to-use/when-not guidance or comparison to alternatives like respond_discussion or dismiss_discussion.

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-disclosure burden. It usefully notes that unmet artifact origins are masked, but says nothing about whether the tool is read-only, whether it has side effects, what permissions are needed, or what the response shape looks like.

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 short and front-loads the key context ('Completed dig:') without filler. Its telegraphic fragments and slash-heavy lists reduce readability slightly, but every phrase contributes 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?

With no annotations and no output schema, the description must fully orient the agent. It lists option content and masking behavior, but omits what the tool actually returns and when it should be called versus choose_archaeology, leaving significant gaps for a 0-parameter options 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 tool takes zero parameters, so the rubric assigns a baseline of 4. The description correctly adds no parameter-level detail because there are no parameters to describe.

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 identifies the context as a completed dig and lists the kinds of options involved (artifact origins/era, art/writing slots, artifact/landmark or writing/culture choices). However, it lacks a clear verb and does not explicitly distinguish itself from the companion choose_archaeology sibling, so an agent must infer its role as an options-listing 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?

Only the phrase 'Completed dig' hints at a precondition for use. There is no explicit when-to-use guidance, no when-not-to-use guidance, and no reference to the related choose_archaeology tool, leaving routing decisions to inference.

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 fully carries the behavioral burden: fingerprinting behavior, done_when checked on every read with default manual, review triggers (turn, hostile proximity, hp), replace_id closes old assignment, and return is the stored assignment reconciled immediately in one game read.

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?

Front-loaded with purpose and contrast to remember, then systematically covers parameters. Despite its length, every clause adds necessary semantics for an 8-parameter nested tool; no redundant 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?

No output schema exists, but the description states the return ('stored assignment reconciled right away ... One game read') and covers all inputs. Combined with detailed behavioral notes, it is complete for a complex create/replace assignment 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%, but the description defines every parameter: role, purpose, unit_ids/city_ids with fingerprinting semantics, target variants, done_when forms and defaults, review triggers, and replace_id behavior. It adds syntax and meaning beyond the bare schema types.

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?

States a specific verb (Give ... assignment) and resource (units or cities in my notebook), and explicitly contrasts with remember, so the agent can distinguish siblings. It also names the assignments sibling for the return.

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 contrasts with remember: prose note says why, assignment persists structured state for later sessions. However, it does not mention when to use amend_assignment or close_assignment instead, so not 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?

With no annotations, the description carries the full burden and delivers well: it discloses the read-only nature ('Nothing is closed, re-targeted or ordered for me'), the state machine (condition_met / needs_review / on_track), the meaning of needs_review reasons, and the fog rule that unseen plots/units are marked stale/unknown rather than assumed gone. It stops short of stating permissions or any side effects beyond the read-only claim.

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, but the body is a dense wall of run-on sentences with nested parentheticals and backtick-quoted tokens that are hard to parse. Much of the length is legitimately needed to convey the return shape given no output schema, but structure and scannability suffer.

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, the description must explain the return shape and it does thoroughly – row fields, state values, reasons list, units/cities/target semantics. Little an agent needs to call it correctly is missing, though the parameter explanation and its placement at the end is less prominent than the return detail.

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 'status' parameter has 0% schema description coverage, so the description must compensate, and it does: status is documented as 'active' (default), 'closed' (completed, cancelled, replaced), or 'all'. This fully enumerates the accepted values and their meanings, filling the gap the schema leaves.

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?

States it returns 'My assignments (see assign), each reconciled against what I can see now, in one game read' – a specific resource with scope. It implies it is a read/list operation and differentiates itself from assign/amend_assignment/close_assignment by noting nothing is closed, re-targeted or ordered. The verb itself is implicit rather than stated, and the dense return-shape prose buries it somewhat.

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 references 'see assign' and mentions that briefing() carries the active ones compactly, needing-a-look first, which hints at an alternative for a terse view. But it never explicitly says when to reach for this tool versus briefing(), or what the caller must do first. Usage is only implied.

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 burden. It does disclose a useful non-obvious behavior ('kind=founder also lists the religions nobody has founded') and points to reference('beliefs') for semantics, but it says nothing about permissions, cost, or return format for a query 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?

Front-loads the core purpose and the allowed kind values in the first two segments, then adds workflow context. The semicolon-heavy, terse style is efficient but borders on cryptic, particularly the reference() call embedded mid-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?

For a single-parameter read tool with no output schema and no annotations, the description supplies the enum values, the meaning of each, and the workflow context needed to invoke it correctly. Only minor gaps remain (no explicit next-step routing, no return-format note).

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 0% and the schema declares no enum for kind, so the description's explicit enumeration ('pantheon | founder | follower | enhancer | bonus | reformation') is essential and fully compensates. It further explains what each kind selection implies, adding real meaning beyond the bare parameter name.

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?

States a specific resource and scope: 'Beliefs still available for one slot', which distinguishes it from found_pantheon/found_religion/enhance_religion siblings that consume beliefs. It also clarifies the return shape ('enum + name'). Not quite a 5 because the phrasing is dense and the slot notion depends on the reader inferring the game mechanic.

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 implies when each kind matters by describing the founding workflow ('Founding a religion takes pantheon/founder/follower...; enhancing takes follower + enhancer'), which helps the agent pick the right kind. However, it never explicitly says to call this before found_religion/enhance_religion, nor names those siblings as the next step.

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, so the description carries the full burden. It discloses the useful empty-result behavior, but doesn't state whether it requires the city to have ranged capability, permissions, or any side effects. It reads as a pure read query, which is helpful but not fully specified.

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 tight sentences with the core purpose front-loaded; nothing wasted and the empty-case caveat follows immediately.

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-param query with no annotations or output schema, the description conveys both what it returns (bombardable plots) and the empty-result condition. Minor gaps remain around the exact return format, but it's largely 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 0% for the single city_id parameter. The description's 'this city' weakly implies city_id selects the acting city, but adds no format or constraint detail beyond what the bare integer schema shows.

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?

States a specific verb and resource: it returns the plots a given city can bombard right now. It's clearly distinguishable from the action sibling city_ranged_attack, though it doesn't name that sibling directly.

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?

'Empty if it has no ranged strike this turn' gives a usage condition and implies the tool is a query to run before attacking. However, there's no explicit statement of when to use it versus city_ranged_attack or other targeting 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, the description carries the full disclosure burden. It usefully describes the returned content (which branches are unlocked/unlockable, culture vs next cost) and implies a read-only query via "available," but never states read-only safety, side effects, or that effects live in a separate reference tool as the authoritative source. Adequate but incomplete for an unannotated 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?

Two dense but front-loaded sentences: domain, then contents, then routing. Every clause carries information and nothing is padded. The nested parenthetical about the reference lookup makes it marginally heavier than 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?

For a zero-parameter, no-output-schema, no-annotation tool, the description covers what is returned and where effect details live, which is what an agent needs to act. The main residual gap is behavioral safety, which the missing annotations leave unaddressed.

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 takes zero parameters, so the baseline is 4. The description adds useful shape information about the response payload (enum + name for adoptable policies, effect text deferred to reference("policies")) that an agent cannot get from 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?

States a specific resource (social policies) and enumerates exactly what the call surfaces: adopted policies, currently adoptable policies, branch unlock status, and culture cost to next. It also points to reference("policies") for effect text, so an agent knows what this returns without confusing it with the effect-lookup tool. It does not explicitly contrast itself with the other available_* list tools, keeping it a touch below top marks.

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?

"Use before choose_policy / unlock_policy_branch" gives an explicit precondition and names the two downstream tools it feeds. That is clear context for invocation. It does not state when-not to use it or any exclusivity conditions, so it falls short of the 5-level routing 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 full burden and does so richly: it documents the returned fields (turns, gold, can_buy, faith/faith_can_buy, faith_only), the enumerated buy_blocked reasons (gold, stacking, unbuyable, engine, refused), puppet refusal behavior, the Venice purchase_only exception, and the enum-vs-display-name divergence.

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 purpose is front-loaded in the first sentence, and the dense field-level detail is all job-relevant for interpreting output. It is long but nearly every sentence earns its place; a small amount of repetition around gold/can_buy appears twice.

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 must explain return values – and it comprehensively describes row fields, buy_blocked reasons, faith purchase paths, and edge cases (puppets, Venice). An agent has everything needed to call and interpret the result.

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?

One parameter (city_id) at 0% schema description coverage, so the schema gives no semantic help. The description establishes city context implicitly ('this city can produce') but never explains the city_id argument itself, so it only partially compensates.

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?

Opens with a specific verb+resource: 'What this city can produce right now: units, buildings, projects, processes.' It also distinguishes its role from siblings by naming set_production (to queue) and purchase_production (to buy), so an agent can place it in the action flow without opening other schemas.

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 routes the agent to downstream actions ('Use set_production(city_id, item) to queue one', purchase_production for faith items), which implies usage. But it never states when to prefer this tool over alternatives like city_screen, purchase_cost, or cities() – no explicit when/when-not framing.

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 the payload semantics (current marker, nonzero progress, what unlocks covers, and the important 'our units and buildings, not another civ's uniques' scoping). It never states the operation is read-only or side-effect free, which for an unannotated tool is a real gap.

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?

Front-loaded with the core purpose, followed by compact field explanations. It is dense with domain jargon ('seat', 'button row', 'embark, ocean, embassy') but every sentence carries information and nothing is padded.

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, so the description usefully doubles as documentation of the returned fields. For a zero-parameter listing tool this is close to complete, though it could note that calling it has no side effects.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 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 resource and scope: 'Techs I can research right now (prereqs met).' It makes clear this is a filtered availability listing rather than the full tech tree, though it never names the siblings (tech_tree, set_research, available_production) it should be distinguished from.

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?

'prereqs met' and 'right now' imply the condition for calling it, but there is no explicit when-to-use statement and no routing to alternatives like tech_tree or set_research. The agent must infer that this is the option-enumeration step before choosing research.

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 and largely meets it: it explains the meaning of the returned `potential` field in both directions (stealable vs exposed) and discloses the 'unknown' state until a spy has surveilled the city. It does not mention turn-timing rules beyond 'right now' or any failure modes, keeping it short of 5.

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 purpose is front-loaded, and the second sentence, while long, is entirely about return-value semantics rather than filler. It is dense but almost every clause 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 1-param, no-output-schema, no-annotation tool, the description is nearly self-sufficient: it conveys what comes back, what the key field means, and which tool consumes the result. A brief note on freshness/turn scope would make it 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 0% and there is one required param, so the description must compensate; it does by identifying agent_id as a spy id sourced from spies(). It does not state the id's type/range or error behavior on an invalid id, so not a 5.

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?

States a specific verb+resource: which cities a given spy could be sent to right now, and splits them into two actionable categories (own cities for counter-intel, foreign for steal tech/coup). It also names the sibling it feeds (move_spy), which lets an agent distinguish it from move_spy, spies, and stage_coup without opening schemas.

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?

'Cities ... could be sent to right now' plus 'Feeds move_spy' clearly establishes the context and the downstream call, and '(agent_id, from spies())' points to the prerequisite tool. It stops short of explicit when-not guidance or naming alternatives to compare against, so a 4 rather than a 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 burden and does unusually well: it discloses that yields are PER TURN, decodes the *_them field pairs, explains the food/production destination quirk, describes the list-vs-object return shape and why (no destinations => object with a reason), and specifies kind/detail behavior. It omits read-only confirmation and any error/permission caveats, so not quite a 5.

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?

Dense but front-loaded: the purpose and the establish_trade_route link come first, then field semantics, then the empty-result case. Nearly every clause carries information, though the run-on phrasing and field-pair explanations push it toward the verbose side.

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 query tool with no output schema, the description explains the return values thoroughly enough to interpret them. Remaining gaps (unit_id meaning, pagination/limits, what detail='summary' vs other strings do) are minor given the depth already 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 0%, so the description must compensate. It does explain the detail parameter ('full' adds `details`, the itemised gold/science hover) well, but unit_id is only implied, and the kind enum values shown are part of the output, not input parameters. Partial compensation for the coverage gap.

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?

States a specific resource (valid trade-route destinations) scoped to a specific unit (caravan/cargo ship) at a specific time ('right now'), and names the sibling it feeds into (establish_trade_route). An agent can distinguish it from trade_routes and establish_trade_route without opening a schema.

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?

Effectively tells the agent this is the prerequisite lookup before establish_trade_route by saying the trade_type is what to 'pass into establish_trade_route.' It also covers the empty-result case and the 'route starts inside one of my own cities' subtlety. Lacks an explicit when-not-to-use or a direct comparison to sibling trade_routes.

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 full behavioral burden and delivers: it states it does not select the unit or pan the camera (side-effect clarity), and discloses return-shape and quirks such as a build with 0 moves starting next turn, air previews including retaliation/interception warnings, melee fire_support_damage effects, and where `help` vs the standing sentence comes from.

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 the first sentence and subsequent sentences each add concrete value (routing, build workflow, preview contents, promotions/help sources). It is dense and long, but largely earns its length given the absence of an output schema.

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 game-state query with no output schema and no annotations, the description supplies the missing return-value detail (nearby_builds, build_info, ranged_targets, promotions, help) and correct follow-up calls. Nothing an agent needs to invoke it correctly appears to be absent.

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 0%, so the description must compensate, but it says only 'for this unit right now', implicitly making unit_id the target unit. It spends far more text on output fields than on the single input parameter, leaving the parameter's meaning minimally inferred rather than stated.

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?

Opens with a specific verb-and-resource statement ('Legal unit-panel actions for this unit right now') and enumerates the categories (missions, tile builds, commands, promotions). It also draws a clean boundary by naming move_unit as the separate tool for movement, so an agent can distinguish it from siblings without opening schemas.

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?

Gives explicit sequencing ('Call this before unit_mission') and an alternative ('Move-to is a separate tool (move_unit)'), plus a concrete workflow for Workers/Work Boats (move_unit onto a plot, then unit_mission(MISSION_BUILD, build=...)). It lacks guidance on when not to use it versus broader siblings like units or todo_actions, but the routing is strong.

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 and does well: it discloses the gate/`withheld` behavior, that `decisions` is never truncated, that every other list caps at limit (default 8, max 50) with `omitted`/`more` pointers, and the read-scope constraint ('five game reads; nothing another seat can see is read'). It omits error/failure behavior and performance characteristics, so it is not exhaustive.

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?

It is front-loaded with the purpose and almost every clause carries information, but it is delivered as long semicolon-chained run-ons rather than a structured list of the returned keys, making it harder to parse than it needs to be. No filler, but the density hurts scanability.

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 output schema and no annotations, the description covers the full return surface key-by-key (decisions, warnings, opportunities, changes, empire, cities, units, threats, camps, civ_rules, notes, assignments, orders), plus the gate case and where to find field documentation. Nothing material for calling it correctly appears to be 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?

Schema coverage is 0%, so the description must compensate, and it largely does: limit gets a default and max, since="turn" is defined against the previous turn boundary, notes is explained for its 'all' value and against the last briefing/finish_turn, and detail="full" is described. The default notes="auto" behavior and the default since="previous" semantics are not spelled out, leaving one real gap.

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 opening sentence gives a clear verb+resource: a compact per-turn read for deciding and for recovering after a context reset, enumerating what it returns (decisions, changes, board state). It also differentiates from at least one sibling by noting turn_digest keeps its own cursor. The phrasing is idiosyncratic and dense, so the purpose takes work to extract, which keeps it below 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 states the two motivating situations explicitly ('for deciding' and 'recovering after a context reset') and reinforces the reset case with 'since="turn" ... use it after a context reset'. It also discloses the gated case where only `gate` returns. However, it never names an alternative tool to use instead in a given situation, so it stops short of full when/when-not routing.

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 gold cost and the coordinate-based purchase, but does not explain permissions, failure cases, irreversibility, or what changes in the game state after purchase.

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 with no wasted words. The action and cost are front-loaded, and the supporting reference to city_screen follows naturally.

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 no-annotation, no-output-schema mutation tool with three undocumented parameters, the description is minimally adequate. It conveys the purchase action and where to find valid plots, but omits enough behavioral and return context that an agent may still need to infer or discover important details.

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%, so the description must add meaning. It clarifies that x and y are plot coordinates and that the city is identified by city_id ('this city'), but it adds no format, range, coordinate-system, or validation details beyond the parameter names.

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 gives a specific verb and resource: 'Buy plot (x, y)' with city and gold cost. It distinguishes the action from the informational sibling city_screen by describing the purchase itself, though it does not differentiate from other purchase-related siblings.

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 implies a prerequisite by stating that city_screen lists buyable plots with buy_gold, which tells the agent where to find valid coordinates. However, it does not explicitly state when to use this tool versus alternatives, nor does it give when-not-to-use 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 full burden and does well: it explains that the standing move is dropped, the unit stops where it is, and ongoing build or fortify is left alone. It does not discuss reversibility or permissions, but the consequences of cancellation are clearly disclosed.

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 front-loaded with the core action and stays compact across three sentences. The parenthetical '(note: why)' is slightly awkward but not wasteful.

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 mutation tool with no annotations and no output schema, it provides useful behavioral context and turn timing. However, it omits how to obtain the required order_id and does not help route between the many order-related siblings.

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%, so the description should compensate. It adds meaning only for the optional note parameter ('note: why'), while the required order_id is left without any description, format, or sourcing guidance.

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?

States a specific verb and resource: 'Close an open order as cancelled.' This clearly identifies the operation, but it does not distinguish itself from sibling tools like orders, give_order, or resume_order.

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?

Provides one usage condition: 'Usable while it is not my turn.' However, it gives no explicit guidance on when to cancel versus resuming or issuing orders, and no alternatives are named despite many related siblings.

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 discloses key effects: adopting the preferred ideology, paying the cost shown in overview().public_opinion.switch_cost, anarchy turns, tenets kept, and refusal when the button is grey. It still leaves some behavior implicit, such as what happens to the previous ideology beyond tenet retention.

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, front-loaded with the action and its cost/condition. Every clause adds relevant information and there is no wasted text.

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 no-parameter game action with no output schema, the description supplies the essential context: what it does, its cost, and when it is refused. It could be slightly more complete by explaining how to verify success or what changes after the switch.

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, so per the scoring baseline the schema cannot require additional parameter documentation. The description appropriately does not invent 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 states a specific action: adopting the preferred ideology that public opinion pushes toward, tied to the policy screen's Switch Ideology button. It is clear this is a switch action rather than initial ideology selection, though it does not explicitly name the sibling tool choose_ideology for contrast.

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 a condition for refusal — the button is grey when there is no public-opinion unhappiness — which implies when the tool is usable. However, it does not explicitly compare this tool to alternatives like choose_ideology or available_policies.

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 and does disclose two non-obvious behaviors: that the call disables automatic specialist assignment (a persistent side effect, not just a toggle) and that it verifies the resulting count. It still omits permission requirements, behavior on an invalid or full slot, and error handling.

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?

Three short, front-loaded sentences with no filler; the critical add/remove semantics and the side effect come first. Minor phrasing awkwardness ('like clicking a slot') costs a little, but nothing is wasted.

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 3-parameter mutation tool with no output schema and no annotations, the description covers the core action, its side effect, and its verification, which is adequate. It stops short of documenting error cases, cost, or what the verified count result looks like, leaving an agent to discover those by trial.

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 0%, so the description must compensate, and it does explain the least self-evident parameter by mapping add=true to add and false to remove, plus clarifying that building refers to a BUILDING_* identifier. city_id is left to inference, but it is unambiguous from the name.

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 verb pair (add/remove) and a specific resource (one specialist in a BUILDING_* from city_screen), which is far more concrete than a bare tool name. It implicitly contrasts with automatic assignment but never names the sibling set_auto_specialists, which would have sharpened 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?

It tells the agent the toggle semantics (add=true to add, false to remove) and implies this is the manual-counterpart to automatic assignment, but gives no explicit when-to-use/when-not guidance or named alternative such as set_auto_specialists.

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 load and does so reasonably: it explains the toggle semantics, that forced-worked tiles stay locked until clicked again, and that puppet cities refuse the action. It omits failure modes (e.g. invalid plot, already-owned tile) and any return/confirmation 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?

Three short sentences, front-loaded with the core action followed by the analogy and edge-case rules. Every sentence carries information with no 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?

For a simple toggle tool with no output schema, the description covers the essential action and key edge cases (forced tiles, puppets). It is still incomplete on parameter validity and on what the result signals, which matters given zero schema coverage.

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%, so the description must compensate. It clarifies that x and y are plot coordinates belonging to the target city, which adds real meaning over bare integer parameters, but gives no ranges, validity rules, or confirmation that city_id must be the controlling city.

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?

States a specific verb+resource: toggling whether a city works a given plot (x, y), with the clear analogy of clicking a tile in the city screen. An agent can distinguish it from plot-related siblings like buy_city_plot, though it does not name an alternative explicitly.

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 city-screen analogy and the 'puppets refuse' note imply usage context, but there is no explicit 'use this when / use X instead' routing against siblings such as city_screen or buy_city_plot. Usage is inferable rather than 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 burden. It says 'verifies resolution' but doesn't describe what happens on success/failure, whether this is a committed action or reversible, or what permissions/state are required. For a 3-param mutation-style action with zero annotation coverage, this is a significant gap.

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 with no filler, and the core action is front-loaded. The brevity is efficient, though it may be too terse for the complexity of the action.

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, no annotations, and 0% schema description coverage, the description should carry more weight. It provides only a minimal pointer to archaeology_options and coordinates, omitting workflow context, return behavior, and error conditions needed 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?

Schema description coverage is 0%, so the description must compensate. It only explains that 'choice' refers to a choice ID from archaeology_options and that x,y are coordinates. It doesn't clarify the valid range of choice, coordinate conventions (tile vs pixel), or units, leaving the schema's bare integer types entirely undocumented.

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 ('Confirm a choice ID') tied to an 'archaeology_options' resource, which gives an agent a decent sense of purpose. However, it's somewhat vague about what 'confirming' actually means in gameplay terms (selecting an artifact? resolving a dig?) and doesn't clearly differentiate from the sibling archaeology_options 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 phrase 'at the completed dig's x,y' implies a precondition (the dig must be complete), but there's no explicit when-to-use guidance or mention of the sibling 'archaeology_options' as the source of the choice ID. The agent is left to infer the workflow order.

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 reveals the four outcomes but says nothing about their consequences (e.g. that raze destroys the city), whether the choice is irreversible, or what permission/state is required. For a consequential decision tool this is a significant gap.

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?

A single tight sentence that front-loads the action and the enumerable choices. No filler or 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?

With no annotations, no output schema, and one required param, the description is minimally adequate: it names the action and the legal values but omits the consequences of each option and any ordering relative to city_capture_options. It is enough to invoke but thin on the ramifications of the choice.

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 0% and the single parameter has no enum defined, so the description meaningfully compensates by listing the valid values (liberate | annex | puppet | raze). The caveat that only the values city_capture_options lists are legal adds useful constraint, though it defers the authoritative list to the sibling.

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?

States a specific verb ('decide') and resource ('a captured city') and enumerates the possible choices, so the agent knows this commits one of four outcomes. It implicitly contrasts with the sibling city_capture_options by noting the choices come from that list, though it doesn't spell out the relationship directly.

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 ('decide a captured city') and it points to city_capture_options as the source of valid values, which hints the agent should consult that first. However there is no explicit when/when-not guidance or statement of prerequisites/ordering beyond the parenthetical reference.

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 adds only the locational detail that the great person appears in the capital or holy city. It does not disclose whether the choice is irreversible, what resource or pool it consumes, what permissions are needed, or what the result looks like.

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?

A single, front-loaded sentence with no filler. It is appropriately sized for a one-parameter selection tool, though the parenthetical could be folded more cleanly into the main clause.

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-param selector with no output schema and no annotations, the description covers the bare minimum: what to pass and where the options come from. It omits the consequence of the action and any preconditions, leaving the agent slightly under-informed but able to call the 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%, so the description must compensate for the single 'unit' parameter. It partially does by indicating the value should be one entry from faith_great_person_options, which tells the agent where valid identifiers come from, but it gives no format, type, or example of the identifier itself.

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 gives a verb ('take') and points at the source of valid values (faith_great_person_options), which helps tie it to its sibling options tool. However, the phrasing 'one unit type' is imprecise for a Great Person selection tool and never states the effect of choosing (spawning the great person in the capital/holy city). It is distinguishable from siblings only via the referenced options tool, not by an explicit statement of what the tool accomplishes.

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?

Sort of implies the prerequisite that faith_great_person_options must be consulted first, since the value is taken from that list. There is no explicit when-to-use vs when-not, no mention of alternatives like choose_free_great_person, and no note about timing or turn conditions.

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, so the description carries the full burden. It usefully discloses the state gate (ENDTURN_BLOCKING_FREE_ITEMS), but says nothing about what happens on an invalid unit value, whether the claim is irreversible, or any permission/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?

Two tight sentences, front-loaded with the action and then the gating condition. No filler, though the parenthetical example is slightly expendable.

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, no-annotation, no-output-schema tool, the description supplies the essential action, an argument format, and the critical precondition. Only the set of valid unit values and failure behavior 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?

Schema coverage is 0% for the single 'unit' parameter, so the description must compensate. It provides a format example (unit="UNIT_SCIENTIST"), which is genuinely useful, but does not enumerate valid values or point to where the list of claimable Great People can be found.

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?

Specific verb+resource: 'Claim a free Great Person'. It is distinguishable from siblings like free_great_person_options and choose_faith_great_person by the 'free' + Liberty-policy precondition, though it never names those siblings directly.

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?

Gives an explicit activation condition: only valid while turn_status shows ENDTURN_BLOCKING_FREE_ITEMS, with a concrete example (after completing Liberty). It does not, however, tell the agent to inspect free_great_person_options first or what to do when the state does not hold.

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 says 'Take one ruins reward' but does not disclose whether the choice is irreversible, what happens to unselected options, whether it consumes a resource, or what the response looks like. This is a significant gap for a mutation 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?

A single, front-loaded sentence with no filler; the example is embedded efficiently. Every element 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 one-parameter mutation tool with no annotations and no output schema, the description gives just enough to find the valid input source (goody_hut_options) and an example. It omits behavioral consequences and does not list valid values, so an agent must rely on the sibling tool to complete the picture.

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%, so the description must compensate. It adds a useful example value and points to goody_hut_options as the source of valid strings, but it does not enumerate allowed values or explain the string format beyond the example. It partially compensates, not fully.

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?

States a specific verb ('Take') and resource ('one ruins reward'), and identifies the sibling tool goody_hut_options as the source of the reward. It is clear enough to distinguish from other choose_* siblings, though it could state more explicitly that it selects one of the options returned by goody_hut_options.

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: call this after goody_hut_options and pass a valid goody string. It does not explicitly state when not to use it, nor does it name alternatives, but the sibling reference provides contextual 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 full burden and largely meets it: it discloses the enabling condition, that the choice is irreversible, that other civs' ideologies are public and drive pressure/unhappiness, and the return payload. It does not describe what each branch actually grants, but the consequential behavioral facts are present.

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?

Front-loaded with the action, followed by trigger, valid values, consequence, and returns in one dense but non-redundant passage. Slightly packed with parentheticals, but every clause contributes information.

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, irreversible game decision with no output schema, the description covers trigger, legal values, irreversibility, downstream consequences, and the return values plus the follow-up tool (choose_policy). Nothing an agent needs to call it correctly is 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?

Schema coverage is 0% and the schema declares `branch` as a bare string with no enum, so the description's enumeration of POLICY_BRANCH_FREEDOM / ORDER / AUTOCRACY is the only place the valid values exist. It adds the essential meaning but does not explain what each branch entails.

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?

States a specific verb and resource ('Choose the empire's ideology') and pins the exact game state that enables it. An agent can distinguish this from change_ideology and choose_policy without opening any schema.

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?

Gives an explicit trigger ('when ENDTURN_BLOCKING_CHOOSE_IDEOLOGY is up (3 Factories or the Modern era)') and notes irreversibility 'short of a revolution', which implicitly routes later changes to change_ideology. It never names that sibling outright, so the alternative is inferred rather than 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 disclosure burden. It implies a selection that consumes a reward, but never states permissions, whether the choice is permanent, what the reward actually is, or what side effects occur - only a vague 'verify' note.

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?

A single compact sentence, but the parenthetical example and the dangling 'verify the reward was consumed' clause make it clunky and front-load the mechanic less cleanly than it could.

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 single-parameter action tool with no annotations and no output schema, the description should at least explain what a 'maya bonus' selection does and what happens after. It leaves the agent guessing about the consequence of the choice and the meaning of the verification step.

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?

With 0% schema coverage and no enum, the description does add value by revealing the value pattern ('UNIT_*'), an example ('UNIT_PROPHET'), and the source of valid values (maya_options). However it does not explain the semantics of the parameter beyond that format hint.

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 verb 'Choose' plus the resource 'an available UNIT_* from maya_options' and the sibling reference 'maya_options' give some differentiation, but the trailing 'verify the reward was consumed' blurs whether that is the tool's behavior or an instruction to the caller, leaving the purpose only vaguely grasped.

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?

Pointing the agent at maya_options implies a prerequisite (list first, then choose) and hints at where valid values come from, but there is no explicit when-to-use, no exclusions, and no routing against the many other choose_* siblings.

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 burden. It does disclose a real gating condition (the branch must already be unlocked), which is useful behavioral context, but it says nothing about reversibility, cost, or whether adopting replaces an existing policy.

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?

A single efficient sentence with the action front-loaded and the constraint appended. Nothing is wasted.

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 action tool with no annotations or output schema, the description covers the core action and a precondition. However, it omits the source of valid policy values, which is the key piece an agent needs.

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 sole 'policy' parameter is undocumented in both schema and description. The example value POLICY_TRADITION hints at the expected string format, but valid values and constraints remain unclear.

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?

States a specific verb (adopt) and resource (social policy), with an example value (POLICY_TRADITION) and a scope constraint (an already-unlocked branch). It is distinguishable from siblings like available_policies and unlock_policy_branch, though it does not name 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 phrase 'within an already-unlocked branch' implies a precondition, but the description never tells the agent to enumerate valid options via available_policies first, nor when to prefer choose_ideology or change_ideology. Usage is only implied.

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 hints that the promotion must be 'earned' and that a PROMOTION_ name is required, but it does not disclose side effects, reversibility, or what happens after choosing. This is insufficient for a likely state-changing action.

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 front-loaded sentence with no wasted words, which is good. However, it is so terse that it omits necessary detail rather than achieving useful conciseness.

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 two required parameters, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It should explain both parameters and the behavioral consequences of choosing a promotion.

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%, so the description must compensate for both parameters. It partially explains the 'promotion' parameter by mentioning its PROMOTION_ name format, but it says nothing about 'unit_id' or how the two parameters relate.

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 verb ('Choose') and resource ('earned promotion'), making the basic action clear. It does not distinguish itself from the many other 'choose_*' sibling tools beyond the resource name, but an agent can still understand the core operation.

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?

No guidance is given about when to use this tool versus alternatives such as available promotions or other choose_* tools. The phrase 'earned promotion' implies a prerequisite but does not explain the context or exclusions.

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 and does well: it explains growth statuses, when growth_turns appears, when expense/income rows are omitted, and what blockaded/wltkd_turns represent. It does not explicitly state read-only behavior or absence of side effects, but the informational nature is clear from the 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 front-loaded with the resource and returned fields, then adds concise field-semantics notes and a single sibling handoff. Every sentence contributes directly to understanding the output or when to use the alternative.

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 annotations, the description supplies the missing return-value context: it names the key city attributes, explains conditional fields, and points to city_screen for detail. That is complete enough for an agent to call this zero-parameter overview 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?

The tool has zero parameters, so there are no parameter semantics to document. Per the rubric, a zero-parameter tool has a baseline of 4 even when the description adds no parameter information.

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 the resource and scope explicitly: 'My cities' with population, yields, production, growth, happiness, and other city-summary fields. It also distinguishes itself from the sibling city_screen by directing detailed per-city inspection there, so an agent can tell the two apart without opening a schema.

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 clearly routes detailed city inspection to city_screen(city_id) and implies this tool is for a broad overview. The when-to-use condition is easy to infer, but there is no explicit 'use this when' or exclusion statement beyond the sibling handoff.

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 exist, so the description carries the full disclosure burden. It usefully enumerates the returned content (plunder, choice list, unhappiness deltas, warmonger warning), but never states that it is a read-only inspection with no side effects, nor what happens if the popup is not in the expected state.

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?

A single dense sentence that front-loads the gating condition before the payload. The parenthetical list of choices and modifiers is information-dense but readable; nothing is wasted, though the sentence is slightly overloaded.

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 annotations, no output schema, and zero parameters, the description is the only source of information and it does explain the shape of what will be returned. It is adequate for a simple read-only popup-inspection tool; only the absence of a follow-up action reference and error-state behavior keep it from a 5.

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 takes zero parameters, which is the baseline-4 case per the rubric. There is no parameter ambiguity to resolve, and the schema confirms an empty argument object.

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 exactly what the tool surfaces: the plunder, the four capture choices (liberate/annex/puppet/raze), each option's unhappiness change, and the warmonger warning. It implicitly distinguishes itself from the sibling action tool choose_city_capture by describing an inspection result rather than a decision, though it never names that sibling.

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 an explicit trigger condition ('When pending_popups shows BUTTONPOPUP_CITY_CAPTURED'), which tells the agent precisely when this tool is relevant. It stops short of naming the alternative action tool (choose_city_capture) for actually making the choice, so the when-vs-alternatives guidance is incomplete.

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 must carry the full behavioral burden. It discloses some side-effect information ('Does not select the city or pan/flip the camera'), but omits critical attack consequences such as whether it is destructive, whether it consumes the city's ranged attack, target validity conditions, or required permissions.

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 compact sentences, front-loaded with the core action and followed by prerequisite and side-effect notes. Every sentence adds useful information without 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?

For a tool with three required parameters, no schema descriptions, no annotations, and no output schema, the description leaves important gaps. It covers the basic action and a prerequisite, but not parameter semantics for city_id, attack outcomes, or failure 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 0% for all three required parameters. The description clarifies that x and y are plot coordinates, but it does not explain the role of city_id or provide format or range details for any parameter.

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 verb ('Ranged attack') and resource ('from a city onto plot (x, y)'), making the action unambiguous. It implicitly distinguishes itself from the prerequisite listing tool by naming available_city_strikes as a separate 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?

It gives clear prerequisite guidance: 'See available_city_strikes first.' This tells the agent when to use the tool relative to its sibling. It lacks explicit when-not conditions or alternative tools, but the context is 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, the description carries the full burden and does substantial work: it discloses the buyable vs buy_gold/can_afford:false red-pricing distinction, can_sell/sell_gold/gold_maintenance on sellable buildings, worked_by for tiles another city owns, and blockaded/enemy markers. The trailing note that writes are separate tools implies this call is read-only, which is important context. It stops short of 5 because it never explicitly states the call has no side effects.

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?

It is long but information-dense: nearly every clause maps to an actual field in the return payload (meters, breakdown, yields, buyable, worked_by, can_sell), which is necessary since no output schema exists. It is front-loaded by starting with what the screen contains, though the single undifferentiated paragraph reduces scanability.

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, so the description must explain returns, and it does so thoroughly, covering meters/breakdown, specialists, worked tiles, buyable plots, sellable buildings, and the write-tool pointers. The remaining gap is call-side guidance (parameter format and when to choose this over sibling reads).

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 param `city_id` has 0% schema description coverage, so the description must compensate. It conveys that the tool is scoped to 'one of my cities', which indirectly explains the argument, but it never states format, valid range, or how to obtain the id (e.g. from `cities`). Marginal value over 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?

States a specific verb+resource: it is the read-only view of one city's screen, and it enumerates exactly what the payload contains (buildings, specialists, worked tiles, production queue, focus, buyable plots). An agent immediately understands it returns city-state data. It does not name a sibling like `cities` or `compare` to differentiate scope, 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?

Usage is only implied: this is the screen to inspect a city's full status. It helpfully notes that writes from the same screen live in separate tools (set_city_focus, buy_city_plot, etc.), which routes the agent away from using this for mutations, but it never states when to prefer it over `cities`, `compare`, or `overview`.

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 usefully discloses a real behavioral trait — the call is refused with current state when the screen would not offer the action — which is genuine value. But it says nothing about the consequences of destructive branches like declare_war/bully_gold or permission/precondition requirements beyond the generic refusal note.

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 tight sentences, front-loaded with the core purpose followed by the action enum and the refusal caveat. Efficient with minimal waste, though the action list could be formatted for easier scanning.

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 mutation dispatcher with no annotations and no output schema, the description covers the action vocabulary and refusal behavior but omits per-action consequences and the meaning of player_id. Adequate but with clear gaps.

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 0%, so the description must compensate. It does list the valid 'action' values that the schema lacks (a real gain), but 'player_id' is left entirely unexplained — it is unclear whether it refers to the human player or the target city-state, which is a meaningful ambiguity.

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?

States a specific verb (press) and resource (city-state screen button) and enumerates the six concrete actions, so the agent knows it is an action-dispatcher for city-states. However it does not differentiate itself from the similarly named sibling 'city_state_actions' or from standalone tools like 'make_peace'/'declare_war' whose actions it duplicates.

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?

No explicit when-to-use guidance and no routing to alternatives. The action enumeration implies context, but the agent cannot tell from the description whether to call this versus the 'city_state_actions' sibling or the dedicated 'make_peace'/'declare_war' 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, the description carries the full behavioral burden. It adds useful detail (kill-camp x/y only when the camp is revealed, tribute paying gold or a Worker, that `details` explains the strength check), which is real beyond-schema context. But it never states whether the tool is read-only or mutating, nor any permission or side-effect behavior, leaving a key gap for a tool whose name implies mutation.

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 single dense sentence is not front-loaded with a clear statement of purpose and instead leads with a cross-reference ('beyond gifts') before burying the actual content list. Internal field names (quest_list, details) and sibling references add clutter without improving the opening.

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 annotations, the description does partially describe return content (influence, structured quest fields, contest scores, tribute strength check), which is valuable. But it omits the sole parameter and leaves the read-vs-write nature unresolved, so it is only partially adequate for a no-schema, no-annotation 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 single required parameter player_id is never mentioned, explained, or given format/scope meaning in the description. The description must compensate for the coverage gap but does not, so an agent learns nothing about the argument from either source.

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 the resource (the city-state screen) and enumerates the content it exposes (influence, quest list, protection, tribute, war/peace), but never uses a clear verb and blurs whether it reports availability ('Whether I can pledge') or performs these actions, despite the name suggesting 'actions'. It does distinguish itself from the sibling city_state_gifts by scoping to content 'beyond gifts'.

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 'beyond gifts' implicitly routes the agent away from city_state_gifts and toward this tool for the rest of the city-state screen, and a sibling quests/quest_list relationship is implied. However, there is no explicit when-to-use statement, no conditions that select this over city_state_action or diplomacy, and no exclusions.

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, yet it only lists returned content. The phrase 'Met city-state's' faintly implies the target must already be met, but it never states that this is a read-only lookup, what happens if minor_id is unknown/unmet, or whether it has side effects.

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?

It is a single front-loaded sentence with no filler, but it is a dense comma-separated enumeration of return fields rather than a structured statement of purpose. Adequate but not well organized.

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, the description usefully enumerates what comes back, partially covering the return-value role. However, for an unannotated lookup it omits call preconditions and error behavior, leaving the definition only partially 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 0% for the single parameter minor_id, and the description never explains that minor_id is the city-state identifier or what values it accepts. 'Met city-state's' is the only indirect clue, which does not compensate for the fully undocumented parameter.

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 sentence enumerates the data the tool surfaces (trait/bonus tooltips, yields, unit gift estimate, unique unit, exported resources), which conveys the resource, but the verb is implicit and there is no differentiation from siblings such as city_state_gifts, city_state_actions, or relationship. An agent can infer it is an info/lookup tool but cannot cleanly separate it from adjacent city-state tools.

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 statement of when to use this tool, when not to, or which sibling to prefer for city-state gifts, actions, or relationship data. With many overlapping city-state tools in the list, the absence of routing guidance is a real gap.

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 and does substantial work: it enumerates the `ally` tooltip variants ({us}, {none, to_become_ally}, or a named current ally), explains `to_become_ally` as remaining influence, and discloses a negative behavior (other majors' influence is not returned). This is meaningful behavioral context beyond what a bare schema provides.

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 and the sibling alternative are front-loaded, and the remaining clauses are dedicated to explaining the return shape, which is warranted since there is no output schema. It is dense but each clause carries return-structure information rather than 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?

With no output schema, the description must explain return values, and it does: `ally` variants, per-tier `influence_after`/`makes_ally`, and the `short_by` fallback. The main gap is the undocumented player_id, but for the tool's return semantics the description is largely 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 0% and the single parameter `player_id` is never mentioned in the description. For a low-coverage schema the description should compensate, but it adds no meaning about what player_id is or how it is used, leaving the parameter effectively undocumented.

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 states the resource (gold gift tiers and friendship) and the target (a met city-state), and the second sentence disambiguates from the similarly-named sibling by routing the actual gifting action to minor_gold_gift. The verb is implicit (it is a query tool, not the gifting action), but the scope is clear enough that an agent can distinguish it from minor_gold_gift.

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 names the alternative ('See minor_gold_gift to actually gift') and states the precondition that the city-state must be met. It gives clear context for when to reach for this tool versus the sibling, though it does not spell out a when-not-to-use case beyond that.

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, and it does disclose meaningful consequences: annex creates resistance and raze burns one population per turn. However, it omits whether actions are reversible, what permissions or preconditions apply, and what happens on failure, so disclosure is partial.

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?

Three sentences, front-loaded with the operations and followed by mechanical effects and a pointer to related state. Dense and largely waste-free, though the closing sentence is somewhat incidental.

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?

A mutation tool with no annotations, no output schema, and 0% parameter coverage. It compensates by supplying the action values and consequences, but the missing city_id semantics and lack of reversibility/permission detail leave gaps for a destructive 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 coverage is 0%, so the description must compensate. It usefully enumerates the valid action values (annex, raze, unraze), effectively supplying the missing enum, but it says nothing about city_id or how to identify the target city.

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?

States a specific resource (city) and the exact operations (annex, raze, unraze) it performs, which is more than a tautology. It distinguishes itself somewhat by noting it operates on the city screen and relies on state already flagged by cities()/city_screen, though it does not fully contrast against those sibling tools.

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?

Implies usage by telling the agent that cities()/city_screen already flag puppet/razing state, hinting that those should be consulted first, but gives no explicit when-to-use or when-not-to-use guidance or named 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?

With no annotations present, the description carries the full burden and does a fair job: it discloses the state transition (active → closed), that closed items leave the briefing but stay readable, and the availability window. It does not say whether closing is reversible or what side effects it has on the other party, so it is not 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?

Short and front-loaded, with the core action first and the state/availability consequences after. The mid-sentence quote placement and run-on second clause make it slightly less crisp than it could be, but nothing is wasted.

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 three-parameter mutation with no annotations and no output schema, the description covers the essential behavioral facts an agent needs: what closing does, the allowed outcomes, the optional reason, and when it can be called. Return payload and irreversibility remain unaddressed, which keeps it short of a 5.

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%, so the description must compensate, and it does: it supplies the domain of 'outcome' (completed/cancelled, which the schema does not enumerate) and clarifies 'note' as the reason for closing and optional. 'assignment_id' is left to inference but is self-evident.

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?

States a specific verb and resource ('Close an active assignment') and enumerates the outcome values ('completed' or 'cancelled') plus the optional note. It is clearly distinct from assign/amend_assignment and from the order-family siblings (cancel_order, resume_order), though it never names a sibling explicitly.

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?

"Usable while it is not my turn" gives the agent a concrete timing condition, and the description routes it to the right place to see closed assignments (assignments(status="closed")). It stops short of stating when closing is preferable to amending or simply leaving an assignment open.

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 still discloses meaningful behavior: it is a read-oriented comparison ('one read' and 'the facts, never a pick'), fogged plots are not read, answers include context/sources/assumptions/omitted items, and detail='full' adds help text. It does not explicitly state that the tool never mutates game state, but the read-only framing is strong.

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 long, but the tool has four distinct modes and eight parameters, and the text is front-loaded and organized by kind. Most sentences add useful mode-specific detail, though the density could be reduced slightly.

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 annotations, no output schema, and 0% schema coverage, the description is unusually complete: it covers all modes, inputs, defaults, output fields, assumptions, pagination/omitted behavior, and how to escalate detail. An agent has enough context to invoke and interpret 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 0%, so the description must carry all parameter meaning, and it does: it defines every kind mode, explains sort options per mode, gives limit range 1-20, describes plots defaults, detail='full', and which parameters apply to city_id, unit_id, and candidates.

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 clear comparison purpose: 'Your candidates side by side in one read, for a decision you are weighing; the facts, never a pick.' It names the compared resources across four modes and explicitly distinguishes the tool from a recommendation engine.

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 strong mode-by-mode usage guidance, explaining when to use kind='production', 'research', 'improvements', or 'trade' and what inputs each mode expects. It does not explicitly name alternative sibling tools or when not to use compare, so it stops short of full alternative routing.

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 and does well: it discloses the returned fields (level exotic..dominant, percent, tourism per turn, trend, turns_to_influential while rising) and an important edge case -- unmet civs appear as 'unknown'. It does not state that this is a side-effect-free read or note any performance/rate concerns, which keeps it from a 5.

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?

Purpose and returned contents are front-loaded, then the usage trigger closes it out; there is no filler. The middle enumeration is dense but every clause adds distinct information about the screen's contents.

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 zero parameters, the description must describe the return payload itself, and it does so in detail -- including field semantics, the exotic-to-dominant scale, and the 'unknown' case for unmet civs. Nothing an agent needs to call and interpret this tool is 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 tool takes no parameters, so per the rubric the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already conveys.

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?

Names the specific screen (Culture Overview) and the exact resource it reports: per met major civ, count of civs Influential on, tourism, and influence on every other major civ. It is clearly distinguishable from siblings like domination_progress, wonder_overview, and demographics.

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?

Gives an explicit trigger condition -- 'Use it when a "Culture Victory Contender" alert names a rival' -- which is concrete and actionable. It does not name a competing tool or state when not to use it, so it falls short of a full 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 does imply read-only status by naming the separate write tools, which is genuinely useful disambiguation. Beyond that it says nothing about permissions, cost, or freshness of the data.

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?

It is front-loaded with the primary tab contents, but the run-on second half piles invented jargon (`ours`, `theirs`, 'pull-down's candidates') into a dense block that is hard to parse. Every sentence carries information, yet the structure is cramped.

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, so the description must convey what comes back, and it does enumerate the fields well. It is thin on how the `swap` view is actually reached given the tool exposes zero parameters, leaving a real ambiguity for an agent trying to trigger that variant.

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 takes zero parameters, so there are no argument semantics to clarify and the baseline is 4. The description instead spends its words on returned data shape, which is appropriate but not required here.

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 (the Culture Overview works tab) and enumerates its contents: Great Work slots, work tooltips, theming rules/bonuses, and tourism breakdowns. It also distinguishes the `swap` variant and its `ours`/`theirs` keys. However, it never explicitly contrasts itself with the sibling culture_overview, so an agent must infer the boundary.

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 closing line routes writes to set_swappable_great_work and swap_great_works, which usefully signals this tool itself is read-only. But there is no explicit 'use this when / not when' guidance and no comparison against culture_overview or great_person_progress for deciding which overview to open.

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, so the description carries the full burden: it declares the tool is non-mutating ('Does not construct or propose anything'), discloses a refusal precondition tied to the scratch table, and names the fields returned. It gives a solid behavioral picture, though it omits any note on permissions or freshness of the deal data.

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 tight sentences with the core query stated first and the qualification/refusal behavior after. Every clause earns its place with no 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?

There is no output schema, so the description compensates by enumerating the return contents (who, items, turns remaining). For a read-only, no-arg tool this is nearly complete; only the refusal-handling path could be fleshed out further.

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?

Zero parameters, so the schema offers nothing to interpret and the baseline of 4 applies. The description correctly adds no spurious parameter detail for a no-arg query.

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?

States a specific read action (listing current deals) on a specific resource, and enumerates the returned fields (who, items, turns remaining). The closing clause 'Does not construct or propose anything' explicitly separates it from sibling tools like propose_deal and negotiate_deal, so an agent can distinguish it without opening schemas.

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 names the precondition ('Refuses if a trade is already on the scratch table (answer incoming_deal first)'), routing the agent to the incoming_deal sibling. Clear context for use, though it doesn't distinguish itself from trade_catalog or the deal-proposal tools beyond the negative statement.

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 irreversibility ('can't make peace again immediately') and that it skips the leader-head confirmation screen, but omits consequences (warmonger penalties, effects on other civs), any confirmation/return behavior, and permission requirements.

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?

Three compact clauses with the action and its main consequence front-loaded; every sentence carries information and there is no 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?

For an irreversible, no-annotation, no-output-schema mutation tool, the description covers the precondition and the key irreversible trait but leaves out downstream effects and the meaning of the sole parameter, so an agent still has gaps before invoking it confidently.

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 0% and the single parameter player_id is never named or described. The phrase 'on a civ I have met' does imply the parameter identifies the target civilization, but the description adds no format or constraint details beyond that inference.

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?

States a specific verb and resource ('Declare war on a civ') with a precondition ('I have met'), which clearly separates it from the sibling make_peace. It does not explicitly name or contrast any sibling, so it falls short of the top band.

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 precondition 'a civ I have met' implies when the tool is applicable, but there is no explicit when-to-use guidance, no statement of when NOT to use it, and no pointer to alternatives like make_peace or war_consequences for related actions.

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 does well: it discloses the screen sequence, the diplomatic penalty for a refused demand, the war/AI-leader preconditions, and the return shape ('accepted', 'reply', 'measured effects like propose_deal'). It omits how `effects` are measured and whether the demand is reversible, so it falls just short of a 5.

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?

One dense paragraph with the core action front-loaded; parentheticals are information-bearing rather than filler, though the density and stacked asides (war/AI-leader/from_us/catalog) make it harder to scan than a chunked split would be.

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, annotation-free, output-schema-free diplomacy mutation, the description covers preconditions, execution path, item semantics, and return values. An agent has everything needed to call it correctly and interpret the result.

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 0%, so the description must compensate, and it largely does for `items`: it names the shape source (propose_deal), the required `from_us:false` flag, and concrete types (GOLD, GOLD_PER_TURN, RESOURCES, CITIES, OPEN_BORDERS, ALLOW_EMBASSY) plus where to pick them (trade_catalog's `them` side). `player_id` is only implicitly defined as the target leader, leaving a small gap.

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?

States a specific verb and resource ('tell an AI leader to hand over `items` for nothing') and immediately distinguishes itself from propose_deal ('through the game's real screens (Demand -> table -> DEMAND -> answer)'). An agent can select this over the sibling trade/diplomacy tools without opening a schema.

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?

Explicit when-to-use and when-not: AI leaders only ('a human seat has no leader screen: propose_deal sends them a table') and blocked at war ('the button is greyed at war (make_peace instead)'), each naming the alternative tool. It also warns to use it deliberately because refusals are remembered.

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 burden. It does disclose a meaningful behavioral trait beyond the schema: best/worst identities are masked when unmet, which tells the agent some fields may be withheld. However, it says nothing about read-only status, cost, caching, or update timing.

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?

A single front-loaded sentence naming the tool and its contents, followed by one short caveat sentence. The metric list is dense but every item earns its place by telling the agent exactly which stats come back.

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 parameters, no annotations, and no output schema, the description is the sole source of information, and it adequately covers what is returned plus the masking caveat. It could be stronger if it noted the read-only nature or how rankings are scoped (own civ vs. all known civs).

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 takes zero parameters, so there is nothing for the description to clarify and the baseline is 4. Schema coverage is 100% and the empty object is unambiguous.

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 (demographics) and enumerates the exact metrics reported: population, food, production, gold, land, soldiers, approval, literacy, each with value/rank plus public best/average/worst. That is far more specific than a tautology, though it does not explicitly distinguish itself from sibling overview/status tools like 'overview' or 'turn_status'.

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 when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. An agent must infer from the name alone that this is the read-only rankings/report tool rather than 'overview' or 'players'.

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 and does so well: it discloses two key behavioral traits beyond the name — that relations worsen with the target AND their friends (third-party effects), and that the action is irreversible ('cannot be undone'). It omits permission/auth requirements, but for an irreversible diplomatic action this is strong disclosure.

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 tight sentences with the action front-loaded and consequences appended. Every clause earns its place; nothing is redundant.

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 single-parameter mutation with no output schema, the description covers consequences and irreversibility adequately. The remaining gap is the lone parameter's meaning, which neither the schema nor the description pin down, leaving the agent unclear on how to specify the target.

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% — player_id has only a type and title. The description's 'another civ' loosely identifies the target, but says nothing about how to supply the player_id, whether it is the civ name, index, or ID, or where the agent obtains a valid value.

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?

States a specific verb and resource: 'Publicly denounce another civ.' This is distinct from siblings like declare_war, propose_friendship, and propose_deal. It stops short of explicitly contrasting those alternatives, but the action 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?

No when-to-use or when-not-to-use guidance. There is no mention of opting for declare_war, demand, or other diplomatic tools instead, nor any prerequisite for denouncing. The agent must infer usage from the name alone.

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 usefully discloses the event-name convention and the dependency on reading turn_digest to determine data1/data2, but it says nothing about side effects, permission requirements, reversibility, or what happens with an invalid event, which is a notable gap for a mutating dispatcher.

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?

Three sentences, front-loaded with the escape-hatch purpose, then the event-name convention, then the workflow tip. Minimal waste, though the parenthetical example list is slightly long relative to the essential 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 4-parameter, 0%-coverage, no-output-schema dispatcher, the description is reasonably complete on intent and workflow but leaves the valid event vocabulary in an external file and never addresses player_id or return behavior, so an agent cannot fully self-serve from the definition alone.

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%, so the description must compensate. It explains `event` well (a FromUIDiploEventTypes name, optionally with the FROM_UI_DIPLO_EVENT_ prefix, list in docs/NOTES.md) and gives context that data1/data2 depend on the pending message, but it defers valid values to an external document and says nothing about player_id.

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 defines this as the catch-all 'escape hatch for any other diplomatic action not covered above' and gives concrete examples (coop-war offers, denounce responses, agreeing to work with someone), which distinguishes it from specific siblings like propose_friendship, denounce, and make_peace. The verb is inherently generic (a dispatcher), so it is not a 5, but an agent can tell it apart from the named diplomacy tools.

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 states the selection condition clearly ('any other diplomatic action not covered above') and prescribes a workflow prerequisite: read a pending leader_message in turn_digest first to learn what is being asked. It does not spell out when-not to use beyond the 'not covered above' framing or name each alternative explicitly, so it falls short of a 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 must carry the behavioral load, and it does disclose the return content (war status, major scores, city-state ally/friend status) plus the omission rule for unmet players. However it says nothing about read-only nature (implied), ordering, or freshness, so it is only partially 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?

One dense, front-loaded sentence with no filler; the scoping rule is stated last. It is slightly telegraphic ('score (majors)'), which costs it the top mark.

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 parameterless info tool with no output schema, the description sketches the returned categories but does not explain the format, what 'score' represents for majors, or how the foundation of unmet players interacts with the rest. Adequate but with clear gaps.

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 takes zero parameters, so there are no parameter semantics for the description to cover; the baseline of 4 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 the resource (civs and city-states I have met) and the states being reported (at war, score, ally/friends), so an agent can tell this is a diplomatic-status overview rather than a deal or event tool. It lacks an explicit verb like 'list' and doesn't name a sibling it is not, so it falls short of 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?

There is no statement of when to use this versus siblings such as relationship, current_deals, players, or diplo_event. 'Unmet players are omitted' is a scope note about the result, not guidance about when to invoke the tool.

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 and largely succeeds: it declares the operation irreversible and specifies the side effects (freed gold maintenance and strategic resources). It also discloses the return payload shape. It stops short of covering prerequisites or failure modes for this mutation.

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?

Three sentences, front-loaded with the verb and object, then the destructive warning, then the effect and return detail. Every sentence carries distinct information with no padding.

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 single-parameter destructive action with no annotations and no output schema, the description covers irreversibility, side effects, and the shape of the return value, which is most of what an agent needs. Only prerequisites and error behavior are unaddressed.

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?

There is a single required unit_id parameter at 0% schema description coverage. The description only implies it identifies 'one of my units' and adds no format, sourcing, or validity detail beyond that. For a simple integer id this is adequate but not additive.

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?

Names a specific verb and resource ('Disband (delete) one of my units') and ties it to a concrete UI affordance ('the unit panel's Disband button'). It is clearly distinguishable from siblings like upgrade_unit, move_unit, or unit_mission without opening any schema.

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 the outcome (frees gold maintenance and consumed strategic resources), which implies when it is useful, but it never states explicit when/when-not conditions or routes the agent to alternatives like unit_home_options or available_unit_actions. Usage is inferable rather than 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?

With no annotations, the description carries the behavioral burden and mostly does: it enumerates the return payload (leader, mood, speech, buttons with id+text, deal) and flags the special screen="greeting" case that yields nothing to decide. It does not explicitly state that calling is side-effect-free, but the read-then-branch framing makes the read-only nature clear.

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 dense sentences front-load what the tool returns before covering the branch cases and the follow-up routing. Every clause carries information, though the packing of button/deal/greeting details into one sentence makes it slightly heavy.

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 zero-param, no-annotation, no-output-schema tool, the description supplies the return shape and the decision routing that structured fields cannot. It is nearly complete; only an explicit statement of read-only/no-side-effect behavior is 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 tool takes zero parameters, so the schema provides no argument semantics to compensate for; baseline 4 applies. The description's mention of screen="greeting" clarifies a value the caller will observe rather than an argument.

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 purpose: it reads the open leader/diplomacy screen and returns the leader, mood, speech, buttons and any deal on the table. It distinguishes itself from the action siblings (respond_discussion, accept_deal, refuse_deal, dismiss_discussion) by being the read that precedes them, though the bare name 'discussion' alone would not convey this.

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 an explicit trigger ('whenever turn_status or wait_for_my_turn reports discussion_pending') and then routes to the exact alternatives for each outcome: respond_discussion(button_id), accept_deal/refuse_deal on a trade screen, dismiss_discussion for the no-button greeting case. When-to-use and which-tool-next are both spelled out.

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 and does well: it discloses bulk side effects (closes every greeting queued behind the current one, reported via closed_count), a stopping condition ('stopping at a screen that needs an answer'), and the shape of the pending-answer response (still_pending, next, gate). It does not say whether dismissing carries diplomatic consequences (relationship/attitude penalties), which is the main remaining behavioral gap.

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?

Front-loaded with the core action and alternative, and every sentence carries information. It reads as one dense paragraph with jargon ('the gate it raises', 'discussion() read needed') that costs some readability, but there is no 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?

With no output schema and no annotations, the description compensates by documenting side effects and the fields returned in the multi-leader case (still_pending, next, gate), including the guidance that no discussion() read is needed afterward. For a zero-parameter tool this is 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?

The tool takes zero parameters, so the schema is complete by definition and no parameter semantics are needed. Baseline 4 applies; the description correctly spends no space on nonexistent inputs.

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?

States a specific action ('leave an AI leader's negotiation/demand/trade-offer screen without agreeing') with a clear scope, and explicitly distinguishes itself from the trade-handling siblings by naming incoming_deal + refuse_deal. An agent can separate this from discussion/respond_discussion/incoming_deal without opening any schema.

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?

Gives an explicit routing rule ('For a trade already on the table, prefer incoming_deal + refuse_deal') plus the second use case (plain leader greetings, including queued ones). It also tells the agent what to do next when another leader is pending, so the when-to-use decision is fully specified.

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 exist, so the description carries the full burden and does: it explains that the first refusal (ok=false) halts the batch by default, that remaining orders land in `skipped` because the assumed state is now uncertain, that stop_on_refusal=false overrides this, that action_id replays already-executed orders on retry after a transport timeout, and that force seizes the turn from another client holding the seat.

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?

Front-loaded with purpose and example, then ordered by importance (limits, refusal behavior, action_id, force). Every sentence carries information, though the two external cross-references (server instructions, end_turn) and stacked parentheticals make it denser than it needs to be.

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 batch-dispatch tool with no annotations and no output schema, the description covers the return shape (`results` with index/tool/result, plus `skipped`), the failure model, size limits, and the replay protocol. Nothing an agent needs to invoke it correctly is 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?

Schema coverage is 0%, so the description must compensate and largely does: `actions` is defined as an ordered list of named-tool-plus-args orders with an optional action_id, stop_on_refusal is defined with its default-off effect, and force is defined as taking the turn from another client. Only the raw JSON default values themselves are left to 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?

States a specific verb and resource ('Carry out a list of orders in one call, in order') and immediately shows the payload shape with a concrete example. This clearly distinguishes it from the many single-action siblings like unit_mission or set_production, which this tool batches.

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?

Gives explicit when-to-use (batch ordered orders), explicit when-NOT (wait_for_my_turn, finish_turn, end_turn, load_*, lua, do are not allowed inside), and the exhaustion rule (at most 40 orders). It also routes the agent to end_turn for the force-takeover semantics.

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 and does disclose useful traits: masking of unrevealed coordinates and unmet holders, plus inclusion of team control flag. It doesn't clarify read-only nature explicitly, but 'progress' strongly implies a read.

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?

A single dense sentence that front-loads the core content. Slightly heavy with clauses, but nothing extraneous.

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 and no annotations, so the description is the sole source. It covers masking and control status but omits return structure or pagination considerations; adequate for a zero-param query but not fully 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?

The tool takes no parameters, so per the rubric the baseline is 4. Schema coverage is 100% and there are no params to document.

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?

Names a specific resource (original capitals of met civilizations, current holders, our control status) which is distinct from siblings like demographics or overview. The verb is implicit (a status/progress read), but the content is clearly scoped to domination victory progress.

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?

No indication of when to use this versus siblings such as overview or demographics. The description states what data it returns but offers no usage context or exclusions.

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 zero annotations the description carries the full burden and delivers: default-on quicksave (single-player only), the turn_claim refusal condition with owning pid/timings, the 180 s idle window, and that force=true seizes ownership. This is exactly the behavioral context an agent needs before a mutating, potentially contested operation.

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?

Front-loaded with the primary intent, then layered with operational detail. The sentences are dense but each carries real information; the description is on the long side but avoids padding.

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 annotations and no output schema, yet the description covers blockers, the diagnostic sibling, default side effects, refusal semantics, recovery timing, and the override — everything needed to invoke correctly and interpret a refusal.

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%, so the description must compensate, and it fully does: autosave is explained as default-true, single-player-only insurance, skippable via autosave=False, and force is explained as the turn-claim takeover switch. Both parameters gain meaning unavailable in the bare 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?

Opens with a specific verb+resource, 'End my turn,' and immediately scopes the operation by naming the blocker conditions (unit orders, research/production). However, it never addresses the close sibling 'finish_turn,' leaving the agent to guess which of the two terminates a turn — no 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?

Gives clear context: it may be refused, and it points the agent at turn_status to diagnose blockers. It explains the autosave default and how to skip it, plus the refusal/override path. It stops short of explicitly telling the agent when to prefer this over finish_turn.

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. It discloses the popup/blocking precondition and that custom_name is ignored unless the game asks for one, which is useful mutation context. However, it does not state permissions, reversibility, or what happens if the blocking condition is not met.

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 dense but front-loaded sentence that starts with the action and then provides parameter mappings. It avoids filler, though the cryptic game terms and semicolon-separated clauses reduce 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 6-parameter mutation tool with no annotations and no output schema, the description covers the special popup precondition and most parameter roles. It still omits the meaning/format of the religion argument and the outcome of a successful or invalid call, leaving gaps an agent may need to resolve.

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%, so the description must explain the six parameters. It maps belief4 to a follower belief, belief5 to an enhancer belief, and city_x/city_y to the holy city in the pending popup, and notes custom_name behavior. It leaves the required religion parameter and the popup data1/data2 mapping opaque.

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 verb and resource: enhancing a founded religion by assigning belief4 and belief5 in a particular holy city. It also ties the operation to the pending BUTTONPOPUP_FOUND_RELIGION, distinguishing the enhancement step from founding. It does not explicitly name found_religion as the alternative, so sibling differentiation is present but not fully explicit.

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 a clear validity gate: only valid when blocking_name is ENDTURN_BLOCKING_ENHANCE_RELIGION, and it points to available_beliefs for selecting beliefs. This tells the agent when the tool is usable, though it does not provide broader when-not or alternative guidance beyond that gate.

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 full disclosure, and it does tell the agent what the payload contains (turn, spy, discoverer, player-visible message). It does not, however, state that the tool is a side-effect-free read, so the safety profile remains unconfirmed.

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?

A single compact clause with no filler; the resource is front-loaded and the field list follows. It is efficient, though the missing verb slightly weakens the lead.

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 zero-param, no-output-schema tool the description should explain what the agent gets back, and it does name the four fields. It stops short of describing ordering, scope, or how to act on the intrigue, so it is adequate but not fully 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?

The schema declares zero parameters and 100% coverage, so there is nothing for the description to clarify. Baseline 4 applies for a parameterless tool.

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 identifies the resource — the Espionage Overview intrigue log — and lists the fields it surfaces (turn, spy, discoverer, message). However it is phrased as a noun with no verb, so it never explicitly states that it retrieves/lists the log, leaving the action implied.

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 when-to-use guidance and no routing to alternatives such as spies, available_spy_cities, stage_coup, or notification_log. The agent must infer that this is an espionage-intrigue view purely from the name.

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 discloses the required unit type (caravan/cargo ship), but says nothing about what happens on failure, whether the unit is consumed or relocated, gold/maintenance costs, or the resulting state of the route. For a mutating action this is a significant gap.

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 front-loaded sentences with no filler; the primary action comes first and the parameter modes follow. The second sentence is dense but every clause carries information.

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 6-parameter tool with no annotations and no output schema, the description covers the parameter modes well but omits unit preconditions and the outcome of the action. It is minimally adequate but leaves real gaps an agent would want filled.

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%, so the description must compensate, and it largely does: it explains that dest_x/dest_y/trade_type come from available_trade_routes(unit_id) and that the alternative mode uses city_name with kind = international/food/production. Only unit_id is left implicit, and the mutually exclusive modes are made clear.

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?

States a specific verb ('Send a caravan/cargo ship') and resource ('establish a trade route'), making the action unambiguous. It implicitly distinguishes itself from siblings like plunder_trade_route and available_trade_routes by being the action that consumes the coordinates those tools produce.

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 clearly explains the two calling modes and names available_trade_routes(unit_id) as the source for dest_x/dest_y/trade_type, which is strong conditional guidance. It does not, however, state when to prefer this tool over adjacent ones (e.g. plunder_trade_route) or any preconditions such as the unit being idle.

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 must carry the full behavioral burden, and it does well: it discloses the implicit quick-save side effect, the multiplayer consequence ('ends the game for them too'), and the blocking wait for the main menu. It stops short of stating what happens to unsaved state when save=false, which is the one remaining gap.

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?

Four sentences, front-loaded with the core purpose and the save/multiplayer caveats, with no wasted words. Dense but each sentence adds a distinct operational fact.

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 annotations and no output schema, the description covers the essential behavior: purpose, side effects, multiplayer etiquette, blocking semantics, and turn-availability. Only the unsaved-state outcome under save=false is unaddressed.

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 0% and the single parameter has no description, but the tool description compensates by explaining exactly what save does ('Quick-saves first when it is my turn in a solo game; save=false skips that'), implying the sole effect of the flag.

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?

States a specific verb and destination ('Leave the loaded game for the main menu') and immediately identifies the downstream siblings this enables (load_save / load_latest). An agent can distinguish this from the many load/turn tools without reading the schema.

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 names the alternatives and the condition that selects them ('so load_save / load_latest can open another save'), specifies a when-to-ask-human rule for multiplayer, and states the unusual allowance 'Usable while it is not my turn.' Nothing is left to inference.

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