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

No annotations are provided, so description carries the burden—it exposes the join fee/402 escrow flow, price timing, fee distribution, and the prerequisite about not already being in an alliance. Good disclosure beyond just 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?

Solid single paragraph without fluff; important constraints front-loaded. No wasted words, though could be structurally tightened into bullets.

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

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

Given the complexity of the fee/escrow behavior, the description provides necessary context. Missing output details but not critical for the most useful call context.

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 already fully describes both params (api_key, alliance_id) with 100% coverage, so baseline is 3. Description adds behavioral context about what the alliance_id refers to and the fee, but no extra param-level syntax needed.

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

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

Description uses specific verb ('accept'), resource ('alliance invitation'), and immediately distinguishes itself from siblings like decline_alliance_invite and leave_alliance. It also explains what happens when accepting, so the agent can select it correctly.

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?

Description explicitly states when you cannot use it (already in another alliance), and mentions leave first. However, no explicit alternative tool is named but the context is clear enough.

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 meaningful behavior: the leader-only authorization requirement, the public attribution in the chronicle naming the actor, and the paid-alliance nuance where approval converts into a payment-gated invitation. Gaps remain on error/idempotency behavior (e.g., what happens if no pending request exists) and the success response.

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, then escalating to permission and side-effect detail. The parenthetical on paid alliances is dense but earns its place by flagging a non-obvious state transition.

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 permission, public side effects, and the paid-alliance variant well. It stops short of describing the return value or failure conditions, leaving a small completeness gap.

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

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

Schema description coverage is 100% — api_key, alliance_id, and kingdom_id are all documented in-schema with clear intent. The description adds no parameter-level detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Accept a kingdom's request to join your alliance'), making the direction of the action unambiguous — a leader approves an inbound request. It doesn't explicitly name or contrast with siblings like reject_join_request or accept_alliance_invite, so the differentiation is only implicit.

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 a precondition ('Only alliance leaders can do this') that tells the agent who may invoke it, which is useful context. However, it never states when to choose this over reject_join_request or how it differs from accept_alliance_invite, so the routing guidance is only implied.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It richly discloses domain guarantees—system execution/verification, money guarantee, atomic territory transfer, non-revocable passage, true-state information delivery, escrowed bounty, and mercenary hiring mechanics—but does not state that browsing is read-only, whether permissions are needed, or how results are returned.

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 then explains the order-type vocabulary. The content is dense and relevant, but it is one long unbroken paragraph where a short bulleted list would be easier to scan, and some game-flavored phrasing is not strictly minimal.

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 browse tool with no output schema, the description supplies the domain vocabulary needed to use the order_type filter, but it never states that the result is a list of available orders or what fields each listing contains. That missing return-shape context keeps it from being 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?

Schema coverage is 100% and order_type already has an enum, but the description goes far beyond the schema's 'Filter by order type' by defining each enum value: territory, passage, information, bounty, and mercenaries. It explains atomicity, non-revocability, escrow, and the bounty/mercenary distinction, giving the agent the semantic detail needed to choose a filter correctly.

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 ('Browse') and resource ('marketplace of STRUCTURAL deals'), so the agent knows this is a viewing/listing tool rather than a transaction tool. It implicitly separates itself from create_market_order and buy_market_order through the verb, but never names those siblings to make the distinction 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?

The only actionable guidance is 'Filter with order_type.' There is no when-to-use or when-not statement, no mention of alternatives like buy_market_order or my_market_orders, and no prerequisite context. Usage must be inferred entirely from the verb 'Browse'.

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 that tier prices are quoted by a 402 and charged automatically, that only one build per tile is allowed at a time with a 429 refusal issued before any money moves, and that builds on different tiles run in parallel. It also flags castle as upgrade-only and walls as overlay-capable, giving the agent real behavioral expectations for a write 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?

The purpose and the type enumeration are front-loaded, and most clauses carry load-bearing game mechanics. It is a single dense paragraph, though, and a few asides such as 'the score the table weighs' add rhetorical weight without new 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 complex mutation with no output schema and no annotations, the description covers types, upgrade semantics, pricing, concurrency, and placement restrictions thoroughly. The only real gap is that it does not describe what a successful call returns or confirm the auth expectation behind api_key.

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 100% so the baseline is 3, but the description goes beyond it by explaining the meaning and consequences of each building_type enum value (what market, barracks, watchtower, walls, and castle actually do), which is the decision-relevant semantics for the only non-obvious parameter. api_key and territory_id 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 clear verb and resource ('Build or upgrade on your territory') and then enumerates exactly what each building type does, including the key distinction that market is the only type that moves dominion weight. However, it never addresses the sibling 'place_building', so an agent cannot tell from the description alone which of the two is the correct entry point for construction.

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 usage rules: calling with an existing same-type building upgrades it one tier, castle is upgrade-only, one MAIN building per territory, and walls coexist with any building. It also frames the strategic choice ('walling your castle vs upgrading it vs defending by depth is your call'). It stops short of saying when to prefer this over repair_building, demolish_building, or place_building.

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 it delivers thoroughly. It discloses atomic execution, payment mechanics (x402), per-type behaviors (territory building tiers, passage expiration and one-grant limit, info snapshot delivery), a limitation (doesn't substantiate weak_point claims), and automatic refund on failure. Nothing is hidden, despite the operation's complexity.

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 information-dense, which fits the complexity, but it's structured as a long run-on paragraph with heavy use of dashes and parentheticals. While every sentence earns its place, the lack of formatting (bullets for the three order types) makes it difficult to scan quickly—an opportunity for improvement without cutting 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 tool with three order types, side effects, and no output schema, the description covers all bases: deal outcomes for each type, edge cases (seller loses tile/towers → refund), exclusions (bounties), and follow-up actions. An agent has enough context to invoke the tool and understand the consequences even without backend docs.

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 100%, so the schema already documents both parameters (api_key, order_id) adequately. The description enriches the order_id concept by explaining what kinds of orders exist and the deal lifecycle, but it doesn't—and doesn't need—to add syntax details. This meets the baseline for well-covered schemas.

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 leads with a specific verb+object ('Buy a sell listing') and enumerates the three resource types (territory, passage, information) with distinct semantics for each. It explicitly distinguishes itself from claim_market_bounty ('Bounties are NOT bought'), allowing an agent to select it correctly without opening sibling 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?

The description provides explicit when-not guidance by calling out bounties as out of scope and naming the alternative tool (claim_market_bounty). It also references my_market_orders as a follow-up endpoint, giving the agent clear routing context for related operations.

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

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

With no annotations provided, the description carries the full burden of disclosing effects. It does this well by explaining that sell listings cancel freely, that bounty escrow is refunded, and that an earned bounty cannot be cancelled if a qualifying deed already exists. It does not mention edge cases like order-not-found behavior or whether cancellation is idempotent, but the core side effects and money implications are covered.

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

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

The description is three sentences and every sentence earns its place: the core verb statement, the simple free-cancel case, and the important escrow exception. It is front-loaded and contains no fluff while still conveying complex cancellation rules.

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

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

Given the simple two-parameter schema and the absence of an output schema, the description is complete enough for an agent to call the tool correctly. It tells the agent what can be cancelled, what happens to money, and the critical case where cancellation is blocked.

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

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

Schema description coverage is 100%, so the schema already documents both api_key and order_id. The description adds helpful context about the order types but does not add parameter-specific semantics beyond what the schema offers. A baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Cancel your own open market order.' It clearly distinguishes this from sibling tools like buy_market_order and create_market_order by scoping the action to the caller's own orders. The sell-vs-bounty nuance further clarifies what kind of order is affected.

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 makes the core condition explicit: only your own open market orders can be cancelled. It also gives concrete when-to/cannot-cancel guidance for bounties when a qualifying deed already exists. It does not explicitly name alternative tools, but the conditions for using this tool are clear enough.

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 burden of behavioral disclosure. It does well: it tells the agent that the operation is a mutation (changing a color), that a conflict can be detected by the mentioned error, and that the API may return a 409 status if the new color conflicts with a neighbor. This is actionable behavioral detail beyond the 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?

Three sentences, zero fluff. The purpose is stated first, then the trigger condition, then the parameter guidance and a note on conflict behavior. Front-loaded and 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 simple mutation with two parameters and no output schema, the description covers the essential context: why to call it, what precondition to check (get_colors), and what error to expect. The only omitted detail is whether the change is immediate or reversible, but that is minor given the low complexity and clear guidance.

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 100%, so the description doesn't need to repeat parameter meanings beyond what the schema already describes. The description adds value by linking color_id to the get_colors palette and advising the agent to use the picked value, enriching the bare schema definition of 'Color index from the palette'. api_key is generically described in the schema, but that's acceptable given full coverage.

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 ('Change your kingdom color'), identifies the resource ('kingdom color'), and distinguishes it from siblings by referencing the 'color-conflict error' and the get_colors palette lookup. It clearly differentiates change_color from adjacent tools like get_colors and get_neighbors by specifying its purpose is to modify the color to resolve conflicts during claims/builds.

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

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

The description explicitly says when to use the tool: 'when a neighbor kingdom has the same or visually-similar color and your claim/build actions fail with a color-conflict error.' It also gives a clear directive to pass the color_id from get_colors, effectively naming the related tool to consult first. There is no exclusion statement, but the context is so specific that the agent knows the trigger condition and the prerequisite.

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 behavioral burden. It does disclose the returned content (participants, unread counts, last activity) and the read-only nature is implied by 'List'. However, it omits details like empty-channel behavior, pagination, or ordering, which a listing tool might exhibit; with no annotations to fall back on, slightly more behavioral disclosure would be expected.

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 that states the main purpose first, then the scope, then the returned fields, ending with a sibling pointer. Every clause earns its place, and there is zero 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 listing tool with a fully documented parameter schema, the description is complete enough to call correctly: it names what is listed and which fields come back. Without an output schema, it could add exact field names or structure, but the key information an agent needs to invoke and interpret the result is present.

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 100% — the single api_key parameter is fully described in the input schema. The description adds nothing about parameters, but the schema already documents them, so the baseline 3 applies.

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

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

The description uses a specific verb ('List') with a resource ('your communication channels') and enumerates the scope and returned data: public Court, alliance channel, private channels, participants, unread counts, and last activity. It also names the sibling it is not ('Read one via read_channel'), so an agent can distinguish it from read_channel without opening 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?

The description provides clear context for when to call this tool — to get an overview of all channels — and routes to the natural alternative ('Read one via read_channel'). It does not explicitly state when not to use it relative to other siblings like publish_channel, but the listing-vs-reading boundary is clearly drawn.

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 clearly states what information is returned (e.g., urgent items, kingdom state, available_actions with ok/why), implying a read-only status check. However, it does not explicitly state it is non-mutating or mention potential side effects, slight ding.

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 fairly concise and well-structured, listing the categories in a readable list. It uses clear labels like 'urgent[]', 'kingdom state', and 'available_actions' without unnecessary verbosity, though the all-caps 'YOUR MAIN COMMAND' adds emphasis rather than 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?

The description provides a comprehensive overview of the tool's output, covering all major aspects (deadlines, wars, events, messages, neighbors, threats, tournament, available actions). It does not explain return format, but since there is no output schema, that is acceptable. It lacks details on pagination or limits, but those are not critical for a status check.

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 covers 100% of parameters with descriptions, providing a baseline of 3. The description adds meaning to 'since' by explaining it filters events and has a default, but the api_key parameter is only described as 'Your Crowns API key', which adds no extra insight beyond the schema.

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

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

The description explicitly states 'YOUR MAIN COMMAND' and 'Call this first every turn to see your full situation', making the tool's purpose unmistakable. It clearly distinguishes from sibling tools by presenting itself as the comprehensive overview, while siblings are specific actions.

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

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

The description gives direct usage guidance: 'Call this first every turn' and 'to decide your next move'. It also enumerates the content of the response, including urgency, wars, events, messages, threats, and available actions with gating, leaving no ambiguity about when to invoke it.

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

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

No annotations are present, so the description carries the full burden. It explicitly states that the call is free, requires no wallet signature, that Crowns pays gas, and that funds are transferred directly to the user's wallet. This fully discloses the tool's behavior and 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?

The description is a single, flowing sentence that is informative but slightly verbose. It could be trimmed without losing meaning, but it remains concise enough for an agent to parse quickly.

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

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

The description covers the purpose, prerequisites (accrued income and minimum), the mechanism (no gas, no signature), and the outcome (funds to own wallet). Since there is no output schema, it does not need to explain return values, making 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?

The only parameter is api_key, which is already described in the schema. The description does not add additional meaning or constraints beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the action: 'Collect your accrued income.' It identifies the specific resource (income) and is distinct from sibling tools like get_wallet or get_inventory.

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 explains when to use the tool: when accrued income is available, and provides guidance on how to check (check_in and get_wallet show 'collectable_income'). It also mentions the minimum threshold, which helps the agent decide if it's worth calling.

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?

Describes the verification process, payout of full escrow with no rake, and refund to creator if unclaimed. No annotations present, so the description carries the burden; it covers success and expiry, but not error cases.

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?

Description is a single but informative sentence with no fluff. It packs verification criteria, payout, and expiry into a compact form, though it could be split for 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?

Covers purpose, eligibility, payout, and expiry. No output schema exists, so no need to explain return values. Sufficient for an agent to understand when and how to use 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 descriptions already cover both parameters (api_key and order_id) with 100% coverage. Description adds no extra parameter-specific details, so baseline 3 is appropriate.

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

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

States a specific verb 'claim' and resource 'open bounty', and clearly explains verification against game records. Distinguishes from other market tools like buy/cancel/create by focusing on claiming bounties.

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 when to use by describing eligibility criteria (strike or war_participation bounties) and urgency (claim promptly). Does not explicitly list alternatives, but gives enough context to infer appropriate use.

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: free-claim mechanics, x402 auto-payment with live discounts, the compounding price curve past fair share, newborn-shield capping, heraldry-clash blocking, and a 429 refusal for a second concurrent paid claim before money moves. These are exactly the behavioral traits structured fields cannot express.

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, with the core purpose first and conditions following. The all-caps labels and stacked parentheticals make it somewhat run-on, but given the genuine complexity nearly 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 mechanically complex mutation with no output schema and no annotations, the description is remarkably complete, and it explicitly points to the rules endpoint and the checkin claim line for anything left out, so no agent-critical information 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 description coverage is 100%, so api_key and territory_id are already documented (including territory_id as a UUID). The description adds little parameter-level detail, which is the correct baseline when the schema does the heavy lifting.

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 ("Claim a neutral territory") and immediately differentiates from siblings like get_neutral_territories (listing) and change_color (remedying a clash). An agent can tell exactly what this tool does without opening 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 routes the agent: free claims are pre-paid (see free_claims_remaining in checkin), paid claims follow the price curve and are paid sequentially, not in parallel. It names alternatives (change_color for a heraldry clash, the rules endpoint for full constraints) and the conditions that select them.

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

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

With no annotations provided, the description must carry the transparency burden. It does so by stating the tool is 'free' and has 'no body' (i.e., no payload beyond the API key), and it clarifies the action is a fingerprint refresh. This is sufficient to understand that it is a low-cost, non-destructive operation, though it does not detail any potential side effects beyond the stated refresh.

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 concise, consisting of two sentences. It front-loads the purpose and condition, then explains the mechanism and cost. No unnecessary words or redundancy; every sentence contributes to understanding.

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

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

The description fully contextualizes the tool: when to use it (realm changed, stale checkin), what it does (refreshes fingerprint), and its resource footprint (free, no body). It gives enough information for an agent to decide and execute without ambiguity, and it aligns with the sibling tools' thematic context.

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 only parameter is `api_key`, which is fully described in the schema as 'Your Crowns API key'. The description does not add additional meaning beyond the schema, but since schema coverage is 100%, the baseline score of 3 is appropriate. No special semantics need to be conveyed.

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

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

The description clearly states the tool's purpose: to re-confirm doctrine after a realm change. The verb 're-confirm' and resource 'doctrine' are specific, and the context ('after your realm changed') distinguishes it from other kingdom-management actions. It effectively signals that this is a maintenance action rather than a combat or alliance 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?

The description provides explicit usage conditions: use when a checkin shows 'doctrine.stale' or 'needs_reconfirm' after a realm change. It also explains the effect (refreshes the fingerprint so defense stops reading as stale), giving clear guidance on when to invoke this tool and what outcome to expect.

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

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

With no annotations provided, the description carries the full burden and does so well: bounty escrows the price NOW via x402 and pays on verified deed, passage cannot be revoked while paid, information delivers TRUE live vision at fill time, mercenaries drop your barracks ceiling for the term with survivors returning and dead men not, and you receive full price with no marketplace rake. These are exactly the non-obvious behavioral traits an agent needs.

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 technical content is dense and front-loaded on the action, which is good, but the closing philosophical paragraph ('Two readings of this, both true...') and the restated note semantics add length that does not help invocation. Appropriate size for a five-branch type system, but not every sentence earns its place.

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

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

For a 7-parameter, nested-object, no-output-schema, no-annotation mutation tool, the description covers the payload shapes, the economic/escrow mechanics, timing behavior, and private-listing/expiry context that an agent needs to call it correctly. Nothing material 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 100%, but the schema's 'deliverable' field explicitly defers to the tool description, and the description fully compensates by specifying per-type payloads ({polygon_id}, {duration_hours}, {}, {kind, target_kingdom_id, min_committed_army}, {count}). Price, note, and order_type are covered by schema; expires_in_hours and addressed_to are not elaborated in the description, keeping this from 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?

Opens with a specific verb+resource ('Post a deal on the structural marketplace') and then enumerates the five order types with their distinct mechanics, which cleanly separates it from siblings like browse_market, buy_market_order, and cancel_market_order. An agent can identify the create/listing action without opening 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?

It gives rich guidance on which order_type to choose and even a strategic framing for mercenaries ('if you are still racing for the table... if the table has already left you behind...'). It does not explicitly name sibling alternatives or say when *not* to use this tool (e.g., vs cancel/buy), so it stops short of full 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 provided, the description carries the full burden, and it delivers: 'View' signals read-only access, 'addressed to you' reveals authorization scoping, and the explicit routing tells the agent exactly where side effects will happen when it acts on a result here. It also discloses that the response set is filterable/combinable. Minor deduction: it doesn't explicitly state what fields or status the response contains (e.g., whether already-answered actionables still appear), which would have made this 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?

Three sentences, each carrying load: (1) what it shows and where responses route, (2) what it deliberately excludes and where those go, (3) parameter documentation with default. It's longer than most descriptions, but every clause serves a differentiation or routing purpose. Slight deduction for the length – though in this case it's earned density, not bloat.

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 filterable list tool with 2 parameters and no nested objects, this is close to complete. It covers filtering behavior, defaults, exclusions, and routing responses. There's no output schema to rely on, so the description could have briefly mentioned what fields the returned actionables contain (e.g., who sent the invitation). That said, the description itself states what the tool returns ('pending... actionables'), and the agent has enough to call it correctly and interpret results.

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 100% (only `box` and `api_key`), both self-explanatory even from bare schema. The description adds value by explaining the `box` semantics ('received', 'sent', 'both') in the context of actionables rather than just an enum list, and states the default explicitly. It doesn't over-explain `api_key`, which is correct.

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 ('View pending alliance actionables'), then elaborates with the two concrete types: 'invitations and join requests'. It explicitly names the sibling tools it is NOT (declare_war, propose_pact, issue_ultimatum and the four response tools), making differentiation from the ~85 siblings trivial. This is the gold standard of purpose statement.

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

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

Justification: Goes beyond vague usage context to name the exact alternative tools for each exclusion: 'wars are declared (declare_war), peace is a NAP pact (propose_pact), coercion is issue_ultimatum.' It also maps the four response endpoints (accept_alliance_invite / decline_alliance_invite / accept_join_request / reject_join_request) to the actionables this view surfaces. An agent never needs to guess which sibling to call next.

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 so richly: FREE but mobilizes army into the first assault, PUBLIC war_goal (revealing intel), defender prep window, auto-expiry, reduced barracks muster, and the grievance/licence-for-justified-war consequence. This goes well beyond a bare mutation statement.

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 behavior well, but the final paragraph ("AND CONSIDER WHAT YOU AIM AT") is a lengthy strategic essay on supply-line hex-cutting that does not help an agent invoke the tool correctly and bloats the definition. Much of the narrative is flavorful rather than operational.

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 mutation tool with no annotations and no output schema, the description covers prerequisites, consequences, and timing thoroughly. It omits what the call returns on success and relies on external "GET /api/v1/actions/rules" for exact numbers, which is a minor gap.

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 100% so baseline is 3, but the description adds real semantics: war_goal is public and quoted by the realm/chronicles and reveals what your towers can see, and defender_kingdom_id selection is informed by the get_attackable/check_attackable guidance. It slightly exceeds the schema's own field docs.

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 ("Declare WAR on a kingdom") and immediately frames its unique role as "the only path to taking owned land by force," distinguishing it from the peaceful land_deal pact and market territory order as well as siblings like strike/raid.

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 routing: names the peaceful alternatives (pact, market order), directs the agent to call get_attackable first, and lists concrete prerequisites (barracks-fed army, free front, newbie shield). When-not conditions are also implied by the grievance/ally betrayal warnings.

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 that the inviter is notified, that a new invite may follow, that the action is free, and critically that the decline is publicly recorded in the chronicle. That public-consequence disclosure is exactly the kind of side effect an agent needs and would not get from the schema. It stops short of stating auth/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 short sentences, front-loaded with the action, then consequences, then the visibility warning. Every sentence adds a distinct fact (notification, re-invite possible, public record); 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 two-parameter mutation with no output schema, the description covers the outcome and the non-obvious social/public consequence. Missing only prerequisite/auth context and any indication of the response shape, which keeps 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?

Schema coverage is 100% with both parameters documented (api_key, alliance_id UUID), so the schema carries parameter semantics. The description adds no extra meaning about the parameters, which is the correct baseline of 3 when the schema is complete.

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: 'Decline an alliance invitation sent to your kingdom.' The directionality ('sent to your kingdom') distinguishes it from reject_join_request and from the responder side. It does not name accept_alliance_invite as the contrast sibling, so sibling differentiation is implicit rather than 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?

Usage is implied by the resource name and the phrase 'sent to your kingdom', but there is no explicit when-to-use, when-not-to-use, or named alternative (accept_alliance_invite is the obvious one). An agent can infer the context but must do so itself.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses that demolition is FREE, limited to one main building per tile, unavailable during war, and details specific consequences for razing markets and barracks. However, it does not describe effects for the other allowed building types (watchtower, walls), leaving a gap in behavioral completeness.

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 dense sentences, with the core action and scope front-loaded, followed by exceptions and consequences. Every clause carries distinct information: ownership, cost, tile-change semantics, castle exception, war restriction, and economic/military effects. 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?

For a 3-parameter mutation tool with no output schema, the description is largely complete: it covers ownership, limitations, timing restrictions, and notable outcomes. The main gap is the undocumented consequences for watchtowers and walls, and no mention of what a successful response contains, though with no output schema that is less critical.

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 already covers the three parameters at 100% with descriptions and an enum, so the baseline is 3. The description adds meaningful value by clarifying that territory_id must reference an OWN building, that only one main building exists per tile, and by giving concrete building-type consequences that inform how to choose building_type.

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 specific verb 'Raze', the resource ('one of your OWN buildings'), and the key constraint 'one MAIN building per tile'. It clearly differentiates this from other construction tools by explaining demolition is how a tile changes function (barracks → market) and explicitly names relocate_capital for the castle exception.

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

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

The description gives explicit when-to-use guidance ('demolition is how a tile changes what it does'), a direct alternative for the castle case (relocate_capital), and a clear when-not-to-use condition (closed during live war). This is strong, actionable routing guidance with no reliance on 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 burden of behavior disclosure. 'View' clearly indicates a read operation, and the description goes further by explaining what the public record contains, how the feed splits, and what categories include. It could add more about required credentials or output shape, but it is not misleading.

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

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

The description is dense and front-loaded: it defines the tool in the first sentence, then gives filter and category behavior. The long list of event types is useful rather than wasteful, though a bit heavy relative to the overall description length.

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

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

For a listing tool with no output schema, the description covers the main selection behavior and category semantics well. Missing details like pagination, ordering, or exact returned fields would strengthen it, but they are not necessary to correctly call and use the tool in most cases.

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 100%, so the baseline is 3. The description adds meaningful extra semantics by enumerating the event kinds inside 'interaction' and 'realm', and by stating that omitting category returns both. This goes beyond the schema's short field descriptions.

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

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

States a specific verb (View) and resource (game events), and immediately identifies the events feed as the public record of everything that happens. The category breakdown makes it clear this is distinct from notifications or statements by describing the Court vs. household content.

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 guidance for filter values ('all' vs 'mine'), category values ('interaction' vs 'realm'), and tells the agent to omit category to receive both. It does not explicitly name sibling tools as alternatives, but the selection rules are otherwise clear and operational.

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?

This description exceeds typical transparency. It clearly states the paid nature ('Cost charged automatically'), the irrevocable binding of lands (not just words), the exact consequences (expulsion for attacking allies, everything gone when membership ends), and the fee distribution ('paid to the alliance (founder and members) in full - no rake'). These are non-obvious behavioral traits that an agent must know before calling. No annotations are provided, so the description carries the full burden and does so excellently.

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 information-dense but somewhat rambling and front-loaded with a theatrical clause ('deepest betrayal' is unnecessary). It could be tightened. Still, it's organized with clear cause-effect chains, and the first sentence states the main purpose. Slightly overlong but mostly effective.

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, the description explains the behavioral effects well: membership binds lands, join modes, fee handling, and auto-charging. It covers legal implications and agent workflow. While it doesn't describe the response format, that's a minor gap when the operational consequences are so well covered. For an action with side effects (cost, alliance creation), 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 schema covers all parameters at 100%, but the description adds semantics beyond that: 'join_fee' is explained as 'applies to both paths... paid to the alliance... in full', and 'terms' is hinted at by the invitation flow. The description tells the agent that the cost is automatic and the fee has no rake, which informs how to set join_fee. This goes beyond the schema's basic descriptions.

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

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

The description clearly states the verb ('Create'), the resource ('alliance'), and the key fact that it's paid ('402 quote'). It distinguishes this from siblings like update_alliance and invite_to_alliance by explicitly naming those tools and the flow, so an agent can tell them apart without looking at 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?

The description explicitly explains when/how to use this tool: 'you invite members via invite_to_alliance; agents apply via request_join_alliance' and covers both join paths incl. the join_fee. It does not just describe what the tool does, it tells the agent the workflow around membership, which is exactly the guidance needed to avoid misuse.

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 present, so the description bears the full burden. It clearly discloses that the output is raw, unfinished material (designated as NOT a finished report) and gives explicit post-processing instructions (weave a story, don't list numbers). It doesn't state side effects like read-only or auth requirements, but 'pull a window' strongly implies a read 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?

The description is front-loaded with the core function in the first sentence)Skip then the usage trigger, then output guidance. It is a bit long but every sentence adds behavioral or usage value — 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?

Given there is no output schema, the description compensates well by explaining the return is raw material (events, deltas, curated moments) and instructs on how to present it. It also implies the scope through the 'window' framing and the period parameter. Solid for a narrative-focused 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 input schema already fully describes 'period' and 'focus' with enums and examples, so the description adds little on parameters. The word 'window' in the description is the only additional link to the period 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 clearly states the tool pulls a window of recent history — events, state deltas, and a curated shortlist of dramatic moments — and frames it as raw material for a narrative. It does not explicitly distinguish itself from sibling tools like get_events or get_kingdom_state, but the emphasis on 'backend-curated dramatic moments' and storytelling purpose gives it a distinct identity.

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 explicit triggers: use when the operator asks 'what happened while I was away' or when something merits telling without being asked. However, it never says when NOT to use it or names a specific alternative tool, so the exclusion side is missing.

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 discharges it well: it explains that plans are sealed during a live war, that attack_plan is null unless the strike is your own or the war has ended, and that defenses[]/defense_filed are only populated once finished. It does not cover pagination or what 'recent' means, which are the remaining behavioral gaps.

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 before the sealing/visibility rules, and every clause carries information. The heavy dash-and-parenthesis construction makes it dense to parse, which slightly hurts scannability.

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 the return shape, and it does — naming attack_plan_filed, attack_plan, defenses[], and defense_filed and their live-vs-finished nullability. Only recency definition and result-size behavior are left unspecified.

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

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

Schema description coverage is 100%, so the schema already documents war_id, api_key, and include_resolved. The description restates their effects rather than adding new syntax or format detail, so the baseline of 3 is appropriate.

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

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

Opens with a specific noun phrase — 'Public combat feed: live wars and recent strikes' — that names both the resource and its scope. It is clearly distinguishable from siblings like get_wars and get_war, and it enumerates the strike subtypes (assaults/raids) the feed contains.

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 routes the agent elsewhere: 'Use get_wars for YOUR wars with role/side detail,' and states the conditions for include_resolved and api_key. It stops short of a fuller when-not list (e.g., vs. get_war for a single finished war beyond the war_id mention), but the routing guidance 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 behavioral burden, and it does so well: 'List' implies a non-mutating read, the leader-only constraint is disclosed, and the pointer to accept_join_request / reject_join_request makes clear that viewing requests is separate from acting on them. It could state read-only/no-state-change explicitly, and it does not cover 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?

Three sentences, each earning its place: the main list behavior, the optional variants, and the cross-reference to a related tool. The most important information is front-loaded, 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 a simple listing tool with no output schema, it covers the main return fields, the optional detail mode, the leader-only requests mode, and how to follow up. It does not describe the exact response shape for the requests variant or failure cases, but those are minor given the low complexity.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value by explaining the relationship between alliance_id and requests, the leader-only requirement, and how the output feeds request_join_alliance. These are meaningful semantics beyond the raw schema descriptions.

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

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

The description opens with a specific verb and resource: 'List every active alliance', and enumerates the exact fields returned. It also describes the optional detail and pending-requests variants, which distinguishes it clearly from mutation siblings like form_alliance, update_alliance, and accept_join_request.

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 explicit conditional usage: pass alliance_id for one alliance, and pass requests=true with alliance_id only as a leader. It also signals that this endpoint is the source of alliance_id for request_join_alliance. It does not explicitly state when not to use the tool relative to siblings, but the main listing 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 so: it discloses ordering semantics (land held, not rank), payload width (tens of kilobytes), the pagination envelope (total, has_more), and a critical auth caveat that anonymous reads of unpublished tournaments silently return total=0, which mimics an empty world.

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 immediately followed by the pagination and alternative-tool guidance. Some phrasing is flavorful ('a fallen crown weighs 0 here exactly as it does at the gong'), which is decorative but does encode the points-weighting meaning, so it mostly 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?

No output schema exists, and the description compensates by enumerating returned fields and the pagination envelope. Auth behavior, ordering, and size characteristics are all covered, leaving nothing an agent needs 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 100%, so baseline is 3, but the description adds behavioral meaning beyond the schema: limit defaults to the whole field, offset reads the next slice, and the response envelope carries total/has_more. The api_key visibility consequence is elaborated rather than merely restated.

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 ('View all kingdoms in the current tournament') and enumerates the returned fields (names, territory counts, status, net earnings, reputation, points). It also names its sibling get_leaderboard and explains the differentiator (ordering by land held, not rank), so an agent can distinguish it 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?

Explicitly routes to the alternative tool: 'Use get_leaderboard with format="compact" when all you need is who stands where.' It also gives the operational condition for paging ('on a 200-crown field one page is tens of kilobytes, so page it').

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains that watchtower estimates carry error margins, that the castle garrison is never included in field army estimates, and that it shows supply state and passage grants. These are nuanced behaviors an agent must know, and the description covers them thoroughly.

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 lengthy but extremely well-structured with numbered points, front-loaded with 'YOUR WAR MAP' to immediately establish context. Each sentence delivers substantive information, from data categories to limitations, with no filler or redundancy. It is appropriately detailed for the tool's complexity.

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 complex multi-faceted output and no output schema, this description is remarkably complete. It covers all four major output areas, explains specific intel calculations (error margins, garrison exclusion), and even clarifies the implication for actions. An agent would have a clear mental model of what to expect without needing further elaboration.

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 only parameter is api_key, and the schema description fully covers it as 'Your Crowns API key' (100% coverage). The description adds nothing about parameters because there is nothing more to say. Baseline of 3 is appropriate for high schema coverage with no additional parameter nuance needed.

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

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

The description clearly states it is a 'YOUR WAR MAP' and enumerates four specific outputs: reachable enemy tiles grouped by kingdom, supply state, foreign-army intel from watchtowers, and passage grants. This explicitly differentiates it from generic intelligence or kingdom tools by focusing on attackable targets. It also ties to specific actions ('Call before declare_war / strike / raid'), making the purpose unambiguous.

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

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

The description explicitly instructs when to call it: 'Call before declare_war / strike / raid - unreachable targets are rejected.' This provides clear usage context and warns of a behavioral consequence. It also describes the data categories, informing the agent of what scenarios would benefit. It does not explicitly list alternatives, but the guidance is strong enough for the intended decision.

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

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

The description carries the full burden since no annotations are provided. 'View' implies a read-only operation, and the note that costs are read live from game config adds useful behavioral context. However, it does not disclose any side effects, permission requirements, or return-shape behavior beyond this.

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 sentence with the main action front-loaded. The phrasing is slightly redundant ('all building types' and 'what each building does'), but it remains efficient and readable.

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

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

For a parameter-free read-only tool, the description covers the essential purpose and the key behavioral nuance of reading live game config. It could mention the output format or whether placement rules are detailed in the response, but it is largely complete for selecting and conceptualizing the call.

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 no parameter documentation burden. The description is not required to clarify inputs the schema cannot convey.

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

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

The description clearly states a view operation over building information: types, costs, effects, and placement rules. This is distinct from sibling tools that act on buildings (place_building, repair_building, demolish_building).

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

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

The context for use is clear: this tool is for inspecting building data before acting on buildings. It does not explicitly name alternatives or exclusions, but the read-only framing and action-oriented siblings make the intended usage obvious.

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 bears full responsibility for behavioral disclosure. It states that the tool returns which color each kingdom currently uses and specifies the palette range (60 options, 0-59). This conveys the core read-only behavior and the scope of results. While it doesn't mention rate limits or authentication, 'Get' implies a non-mutating operation, and the provided details are sufficient for safe use.

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

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

The description is two sentences with no redundant words. The core purpose is front-loaded ('Get the full palette'), followed by the return behavior and a clear usage directive. Every sentence earns its place.

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

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

Given the tool has no parameters and no output schema, the description covers everything an agent needs: it states the resource, the range, the return content, and the appropriate usage context. There is nothing missing for correct invocation.

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, and schema coverage is 100% (no properties). According to the rubric, a baseline of 4 applies. The description does not need to explain parameters since none exist, and it adds value by clarifying the range of available colors, which is not present in the schema.

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

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

The description clearly states the verb 'Get' and the resource 'full palette of kingdom colors', and explains the purpose: to see which color each kingdom uses so the agent can pick a non-conflicting color. It also differentiates from the sibling tool change_color by saying 'Use this before change_color', making its role unambiguous.

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

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

The description gives an explicit usage instruction: 'Use this before change_color.' This tells the agent exactly when to invoke this tool (as a prerequisite) and why (to avoid color conflicts). No alternatives are needed because change_color is the only related tool, and this is clearly a prerequisite 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?

With no annotations provided, the description carries the full behavioral burden and does so richly. It discloses the working-watchtower requirement, that radius grows with tower tier, that alliance vision is shared, that null army_intel means fog rather than an armyless kingdom, and that supplied appears on every watched foreign tile. These are exactly the operational details an agent needs beyond a bare 'view intel' statement.

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 then builds out necessary context without filler. It is dense and uses parentheticals and em dashes heavily, which slightly reduces readability, but every sentence carries useful information for a complex tool with no annotations or 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?

No output schema exists, so the description must explain return semantics, and it does: it lists the main intel categories and explains the meaning of null army_intel and supplied. Combined with the prerequisite and alliance-sharing behavior, an agent has enough context to call and interpret this tool correctly.

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

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

Schema description coverage is 100%, and the single api_key parameter is fully documented in the input schema. The description adds no parameter-level information beyond that, so the schema already does the heavy lifting. This matches the baseline 3 for high schema coverage.

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: 'View enemy movements near your watchtowers.' It goes on to specify exactly what intel is shown (enemy territories, battles, diplomacy, army_intel, supplied), which clearly distinguishes it from siblings like get_active_battles or get_neighbors.

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

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

The description gives a clear usage condition and prerequisite: 'Requires at least one WORKING watchtower' and explains that a ruin at tier 0 or a cut tower sees nothing. It also frames why an agent would use it ('the only free intel in the game') and what tasks it supports, such as finding the hex that severs a rival and confirming a cut worked. It does not name alternative tools or explicit when-not-to-use cases, 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?

There are no annotations to indicate read-only or side-effect behavior. The description says 'View' which implies no mutation, but it does not explicitly state that no changes are made, nor does it describe the response format, potential errors, or any limits.

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

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

The description is a single sentence that is clear and front-loaded with the primary action. It avoids unnecessary detail and presents the key clarification about the inventory contents efficiently.

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 read-only inventory tool, the description is fairly complete but lacks explicit confirmation of read-only behavior and any information about the response structure. Since there is no output schema, additional detail about what is returned would improve completeness.

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

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

The input schema already fully describes the only parameter, api_key, with the description 'Your Crowns API key'. The tool description adds no additional parameter semantics, so a baseline score of 3 is appropriate given full schema coverage.

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

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

The description uses the specific verb 'View' and clearly identifies the resource as the user's inventory. It further clarifies that the inventory consists of buildings from treasure rewards, which distinguishes it from building placement or other inventory-related 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?

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention related tools like place_building or clarify when inventory viewing is appropriate.

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 burden of disclosing safety. It presents a read-only snapshot ('territories, buildings, budget, income') with no hint of side effects, which is reasonable and likely accurate, but it doesn't mention API key requirements, potential rate limits, or that the response could be large. Neutral and non-contradictory.

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 compact sentence with zero filler, front-loading the key returns right after the verb. Maximum information density for its length.

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

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

The tool is a straightforward read snapshot, schema documents its single parameter, and sibling names clarify scope. Missing only explicit behavioral notes (caching, freshness of data) and an explicit read-only flag, which are minor given the simple nature of 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 coverage is 100% and the only parameter (api_key) is self-explanatory, so the description doesn't need to add much. It provides no extra usage nuance for api_key, but given the single documented param, baseline 3 is fair.

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?

Clear verb ('Get'), resource ('your kingdom state'), and lists specific returns ('territories, buildings, budget, income'). Distinguishes from siblings like view_kingdom and get_wallet by summarizing a comprehensive status snapshot, so an agent can select it confidently.

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 a read-only status query but doesn't explicitly state when to prefer it over get_wallet, get_buildings_info, or get_inventory. No exclusions or alternatives given. Adequate but leaves routing to the agent.

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 so well: it discloses the ranking formula and its edge case (unsupplied tiles at half), the semantics of rank versus page index, the exact envelope keys, the compact-vs-full size tradeoff, and the critical api_key behavior (an unpublished tournament answers total=0, which mimics an empty world).

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 metric, then layers paging, envelope, and format guidance in a logical order. It is dense and slightly long, with the POINTS explanation bordering on over-explanation, but nearly every sentence conveys actionable 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?

No output schema exists, yet the description specifies the return envelope (total, living, offset, limit, has_more) and the per-row keys for both formats, so an agent knows exactly what it will get. Nothing needed to invoke or interpret the call 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 already 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains why api_key matters (visibility of an unpublished tournament), grounds offset with a worked example, and quantifies the format tradeoff ('roughly three times the context per row').

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 ('View tournament standings - the public leaderboard') and immediately specifies the ranking metric (POINTS = dominion weight). An agent can distinguish this from sibling tools like tournament_results or get_kingdom_status 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 clear operational guidance: page with offset rather than raising limit, and use compact unless you specifically need the extra columns. It stops short of naming a sibling alternative (e.g. tournament_results) for the adjacent use case, so it is context-rich but not fully routing-aware.

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. It explains the output but does not mention potential side effects, read-only nature, rate limits, or error conditions. The hint about building watchtowers might imply prerequisites, but this is not clarified.

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 concise—two sentences with no redundancy. It front-loads the core purpose and provides necessary detail without fluff.

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

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

Given the tool's low complexity (single param, no output schema), the description covers purpose, output, and hints at a related tool. It lacks explicit note on side effects or edge cases, but these are not critical for a simple read operation.

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 only parameter (api_key) is fully described in the schema ('Your Crowns API key'). The description does not add extra context beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'See which kingdoms border yours.' It specifies the output details (neighbor names, color, and number of bordering hexes) and differentiates from a more detailed alternative (get_intelligence).

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 provides a clear pointer for when to use a different tool ('For detailed enemy intel... use get_intelligence'), implying this tool is for basic neighbor info. However, it does not explicitly state when not to use it or provide other selection criteria.

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

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

There are no annotations, so the description carries the behavioral burden. The verb 'find' reasonably implies a read-only lookup, and 'claimable' adds context about the result set. However, the description does not mention whether state changes occur, how results are ordered, or what territory information is returned.

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 one compact sentence with no filler. It front-loads the core purpose and includes the key selection criteria: claimable, neutral, and near kingdom.

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 getter, the description is nearly sufficient, but there is no output schema and the description does not say whether the tool returns a list, what fields a territory includes, or what the agent should do after finding one. These are moderate gaps given the absence of any other behavioral or output documentation.

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 exactly one parameter and the schema description coverage is 100%, so the schema already explains that api_key is required and what it is for. The tool description adds nothing beyond the schema, which is acceptable given the baseline for full schema coverage.

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 operation and resource: find claimable neutral territories, with the important qualifiers 'claimable' and 'near your kingdom'. It is clear, but it does not explicitly distinguish itself from related sibling tools such as inspect_territory or claim_territory.

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 when to use this tool: when the agent wants to discover neutral territories available for claiming near a kingdom. It offers no explicit when-not-to-use guidance and does not point the agent to claim_territory or inspect_territory as 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, the description carries the full behavioral burden and mostly delivers: it explains TRUST's starting value, decay causes, slow regrowth, and immunity to war; defines THREAT; and details grievance expiry and its aggression-justification effect. It does not explicitly state 'read-only/no side effects,' but 'public dossier' plus the get_ verb make that reasonably 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?

The description is dense but well-structured: a short framing line, labeled TRUST/THREAT/GRIEVANCES blocks, and a closing note about attached dossiers. The final sentence is somewhat tangential to invoking this tool, but the rest is information-dense without 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?

Because there is no output schema and no annotations, the description must explain what the caller will receive; it does so for TRUST, THREAT, and GRIEVANCES with meaningful semantics. It leaves some exactness gaps—THREAT's scale, precise horizon values, and the formal return shape—but overall an agent can call this sensibly after reading it.

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 fully documents kingdom_id as 'UUID of the kingdom to look up,' and the description adds no parameter format or constraint information beyond that. Since schema coverage is 100%, the description does not need to compensate, so a baseline of 3 is appropriate.

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

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

The description opens with 'A kingdom's public dossier,' which clearly establishes the resource being inspected, and the detailed field definitions make the lookup intent obvious. However, it never uses an explicit verb like 'retrieve' or 'get,' and it does not differentiate itself from sibling tools such as get_kingdom_status or view_kingdom.

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 the data matters for war and diplomacy—grievances justify war, pacts carry dossiers—but it never explicitly states when to call this tool versus alternatives like get_kingdom_status or get_intelligence. There is no direct when-to-use, when-not-to-use, or alternative-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 provided, the description carries the burden and does well: it discloses that the output is a machine-readable table, includes live-config numbers and battle arithmetic, and is authoritative. It does not explicitly state read-only or side-effect behavior, but the retrieval nature is clear enough for a tool like this.

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, all useful and front-loaded. The first sentence delivers the core purpose, the second establishes authority, and the third provides a useful navigation pointer to a sibling tool. No wasted words.

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

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

For a zero-required-parameter retrieval tool with no output schema, the description gives sufficient context about content, scope, and relation to check_in. An agent can decide when to call it and what to expect.

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

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

Schema description coverage is 100%, and the only parameter api_key is already documented as not required because the manifest is public. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as the source of the full machine-readable constraint table covering every agent action, including costs, preconditions, payload shapes, and live-config numbers. This is a specific resource and distinguishes it from action-oriented 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?

The description says this is the number source the guide points at and contrasts it with check_in's available_actions for live-state gating. This implies when to use get_rules versus check_in, though it does not provide an explicit 'use this when...' or exhaustive alternative list.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'View' signals a read operation and the description enumerates what data is included, but it does not explicitly state the endpoint is side-effect-free, nor does it mention permissions, rate limits, or response format quirks.

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 filler or repetitive phrasing. Every word contributes to understanding the tool's purpose, making it highly concise and well-structured.

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

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

Given the tool's simplicity, a one-parameter schema, and no output schema, the description covers the core return categories (balance, earnings, spending, transactions). It ends slightly short of a 5 by not addressing whether there are pagination limits or explicit no-side-effect guarantees, but those are secondary for a read-only wallet query.

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 only parameter, api_key, is fully described in the schema as 'Your Crowns API key', and schema description coverage is 100%. The description adds no parameter-specific detail, but nothing is needed beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('View') and a clear resource ('your USDC balance, earnings, spending, and transaction history'). It is unambiguous about what data the tool exposes and distinct from sibling getter tools like get_inventory or get_kingdom_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?

The description implies the tool is used when the agent needs an account's USDC financial details, but it does not explicitly state when to prefer this over alternatives, nor does it provide exclusions or routing guidance. No sibling tool is mentioned, so use-case context remains implicit.

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

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

The description discloses a behavioral nuance: 'committed_army visible only for YOUR side - read the enemy's through watchtowers.' This goes beyond a simple getter and informs about data visibility restrictions. No annotations exist, so this transparency is valuable.

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

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

The description is a single, concise sentence that lists key return items without unnecessary detail. It is well-structured and easy to parse, providing clear information in a compact format.

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?

Without an output schema, the description serves as the primary source for expected return data. It enumerates major components (both sides, windows, strikes, participants, readiness, end state) and adds nuance about participant visibility. It does not mention error handling or edge cases but covers the essential output comprehensively.

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 already provides clear descriptions for both parameters (war_id: 'UUID of the war', api_key: 'Your Crowns API key'). The description adds no additional parameter context, and with 100% schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Inspect war' and enumerates the specific data returned (both sides, windows, strikes, participants, readiness, end state). It distinguishes itself from sibling tools like get_wars (list) and get_war_offers by focusing on a single war's details.

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

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

The description implies usage for retrieving details of a specific war but does not explicitly state when to use it versus alternatives. It lacks explicit conditions or comparisons, though the sibling list suggests a distinct role. No direct 'use when' guidance is provided.

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

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

The description gives transparency about the returned data (incoming/outgoing offers, terms, and status). It implicitly indicates a read-only operation without needing annotations. No side effects are mentioned, which is appropriate for a listing tool.

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

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

The description is concise, two sentences, clearly stating the purpose and providing a relevant pointer. No redundant 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 simple GET tool, the description is complete: it explains the type of data returned, the direction (incoming/outgoing), and gives a hint for follow-up actions. No output schema exists, so no return format explanation is required.

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 only parameter is api_key, fully described in the schema. The description adds no extra information, but since the schema covers it completely, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: listing war offers involving the user, both incoming and outgoing. It also distinguishes itself from related tools by specifying the nature of the data (offers) and mentions the companion tool for responding.

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 provides a usage hint by directing users to respond_war_offer for incoming offers. While it doesn't explicitly contrast with get_wars/get_war, the focus on 'offers' makes the appropriate context 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?

Describes the output structure (role, side, enemy, kind, effective status, window deadline, assault gate open) and scope ('wars YOU are in'). While read-only behavior is implied, it is not explicitly stated, and no potential side effects or permissions are mentioned beyond the API key.

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 concise and well-structured, front-loading the main action ('List every war YOU are in') and then detailing the output fields in a clear list. No redundant or verbose language.

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 list operation, the description adequately specifies the returned fields and scope. However, it does not mention pagination, sorting, or potential errors, which might be relevant for a complete understanding. Still, it is sufficient for most use cases.

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 only parameter is api_key, which is already described in the schema as 'Your Crowns API key'. The tool description adds no additional meaning, so it meets the baseline but does not enhance understanding.

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?

Clearly states the tool lists every war the user is involved in, specifying roles (attacker, defender, committed participant). This distinguishes it from sibling tools like get_war or get_war_offers, making the purpose unambiguous.

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

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

The description implies usage for retrieving all wars the user participates in, but does not explicitly contrast it with alternatives (e.g., get_war for a specific war). No explicit guidance on when to choose this over other tools is provided.

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?

Since no annotations are provided (no readOnlyHint, destructiveHint), the description carries the full burden. It discloses the fog-of-war behavior (tier info only for own tile or tower coverage) and the type of information returned. However, it doesn't mention any side effects (e.g., whether this counts as an action that consumes resources or triggers notifications), response format details, or rate limits. It could also clarify whether this is a read-only 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?

The description is a single, compact sentence which is efficient and front-loaded with the most important info (what is returned) followed by the hint 'The numbers a weak_point claim needs.' This hint is useful for decision-making. No fluff. It loses a point because the dense list of fields may be slightly hard to parse, but overall it's well-structured for an LLM.

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

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

Given the tool's simplicity (2 params, no output schema specified), the description covers what it returns, the conditional reveal logic, and its strategic purpose. It doesn't need to detail return structures since there's no output schema and the description lists fields. It could mention whether it's safe to call repeatedly without side effects, but for a read-inspection tool this is a minor gap. The main missing piece is explicit alternative routing.

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

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

Schema description coverage is 100%, meaning the schema already documents both api_key and polygon_id. The description adds the example format 't_04121' for polygon_id, which helps, but otherwise restates that a hex is being inspected. The description doesn't clarify api_key beyond 'Your Crowns API key', which is likely standard across all tools and already in the schema. Overall, borderline 3-4, but 3 as the description's param info is minimal extra 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?

The description explicitly states the specific verb (inspect), the resource (one hex), and the full set of data returned: owner, buildings with tiers, effective income, recent strikes, and neighbours with owners. It also notes the fog-of-war reveal rules, which distinguishes this from generic territory lookup tools like get_neutral_territories or get_neighbors.

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 when to use this tool: when you need full details on a single hex for planning (e.g., weak_point claims). However, it does not explicitly state when NOT to use it or name alternative tools like get_neighbors or get_buildings_info for cases where only neighbours or buildings are needed. This could confuse an agent deciding between detailed inspection and lighter lookup.

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 that the call creates a declaration row, that the target can accept or decline via named siblings, and that the invite and its outcome are public chronicle rows. It does not say what the immediate response looks like or what errors to expect.

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?

Five short sentences, front-loaded with the core action followed by permission and state constraints. Dense but nearly every sentence carries a distinct rule; only the trailing clause about 'silence' is somewhat ornate.

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 must cover preconditions and side effects, which it does (permissions, target state, dedup rule, public declaration). Missing only error/response behavior, a minor gap for this complexity level.

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

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

Schema description coverage is 100%, so the four parameters are already documented in the schema. The description adds only conceptual framing (alliance_id = your alliance, to_kingdom_id = target) and never mentions the optional message parameter, so it stays at the baseline 3.

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

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

States a specific verb (invite) and resource (another kingdom into your alliance) in the first sentence, and implicitly contrasts with the reverse-direction sibling request_join_alliance. An agent can distinguish this from accept/decline invite tools without reading 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 preconditions: caller must be a founder or officer, the target must not already be in another alliance, and only one pending invite per (inviter, target) pair. It stops short of naming alternative tools to use when those preconditions fail (e.g. request_join_alliance for the opposite flow).

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 and does well: it explains enforcement on comply, public recording on refusal/ignore, reduced aggression cost for the next war, and reputation consequences for withdrawing. It doesn't cover all edge cases like response format or exact cost changes, but major behavioral traits are transparent.

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

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

The description is dense and front-loaded with the core action and deadline. Every clause adds behavioral or semantic value; the stylized 'pressure dial' is minor flavor but not wasteful. Slightly long, but justified by the number of demand variants and consequences.

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

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

Given the tool's complexity, absence of annotations, and lack of output schema, the description provides a strong operational picture: what can be demanded, what happens on each outcome, limitations, and reissuing guidance. It leaves some minor aspects unstated, such as whether the narrative field is required for effect and exact war-cost reduction, but the agent can invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantic detail beyond the schema: it maps 'payment' to indemnity with 'amount_usd', 'non_aggression' to forced peace with 'days', and clarifies that leave_alliance exits a bloc. It also highlights the 1-48h deadline constraint and forbids land, making parameter intent much clearer.

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

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

The description uses a strong, specific verb ('DEMAND') and clearly defines the resource: a system-executable ultimatum with an hour deadline. It enumerates the exact demand types and explicitly states what cannot be demanded (land), which distinguishes it from related diplomacy and war 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 gives practical usage context: demands must be executable by the system, land is never an option, negotiation belongs in channels first, and reissuing is possible. It doesn't explicitly name alternative sibling tools for negotiation, but the guidance is concrete enough to steer an agent's decision.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states there's no vote/protection mechanism and that members can leave freely, which frames the action's reversibility and consequences. However, it doesn't mention what the response looks like or whether kicks are repeatable.

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 deliver role-based permissionsrost, consequence framing, and absence of a protection mechanism. Front-loaded with the action verb and immediately useful information, 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 3 fully-described parameters succeeding an actual schema and no output schema, the description covers the rule semantics and consequences. It omits potential failure modes (e.g., what happens if the target is not a member) but is adequate for a simple mutation 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 100% and includes descriptive field names (kingdom_id, alliance_id, api_key). The description adds no parameter-level detail beyond what the schema provides, which is acceptable given the high coverage baseline of 3.

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

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

The description has a specific verb ('Kick'), a clear resource ('alliance member'), and explicitly scopes who can kick whom with a parenthetical role rule. It is immediately distinguishable from the invitation and alliance-construction siblings (invite_to_alliance, request_join_alliance, form_alliance).

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 parenthetical establishes the authorization context (founders vs officers) and implicitly conveys that regular members cannot kick. It doesn't explicitly name alternative tools for member removal (e.g., leave_alliance is self-initiated), but the permission distinction is useful 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 full weight and excels: it reveals succession rules, disband condition, instant loss of NAP/passage/channel access, tile-darkening effects, and the backdating of betrayal. Every behavioral consequence is spelled out.

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

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

The description is dense but every sentence earns its place—core action first, then succession rules, then immediate effects, then the critical warning. No fluff; structure flows logically from action to consequences.

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 no output schema and minimal parameters, the description covers all critical edge cases: founder with members, sole member, instant termination effects, tile mechanics, and betrayal timing. 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?

The only parameter, api_key, is fully documented in the schema with 'Your Crowns API key'. The description adds nothing about parameters because there is nothing more to add; baseline 3 applies given 100% schema coverage.

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 opens with the exact verb and resource: 'Leave your current alliance'. It distinguishes itself from all alliance-related siblings by focusing solely on departure, not formation, invitations, or roles. The added 'always free' and 'writes nothing' clarify the action's nature.

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 alternative is named, but the tool is the only leave action among siblings, making its use self-evident. The description does provide situational guidance on founder vs. member outcomes and when the alliance disbands, which effectively informs when one should call it.

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

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

The description begins with 'View', indicating a read-only operation with no side effects. It also notes that filled orders include a delivered_payload, giving insight into the response structure. With no annotations provided, this level of transparency is adequate.

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 succinct, using two sentences to convey the tool's purpose and a key detail about filled orders. There is no fluff or unnecessary 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?

Given that there is no output schema, the description provides useful context by mentioning that filled orders include delivered_payload and mentioning specific examples. This helps the agent understand what to expect, though it could be more explicit about the exact structure. Still, it is 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?

The only parameter, api_key, is described as 'Your Crowns API key', which is self-explanatory. The schema already provides this description, so there is no 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?

The description clearly states the tool's function: viewing the user's own market orders, including created and bought/claimed orders, across all states. It distinguishes itself from browsing the market (which is public) by explicitly saying 'your market orders'.

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 implicitly indicates when to use this tool: when a user wants to inspect their own market orders. It contrasts with 'browse_market' for public viewing, though it does not explicitly name the alternative or provide conditions. Still, the intent 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 provided, the description must carry the behavioral disclosure burden. It discloses that all pact statuses (active, fulfilled, voided) are visible, and that pacts are public. However, it does not specify response format, pagination, rate limits, or any authentication requirements beyond noting api_key is optional. This is partial transparency but leaves key behavioral details unstated.

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 exactly two sentences with zero redundancy. It front-loads the core action ('Read the treaty record') and immediately pivots to key differentiators (public vs. secrets, filtering use case). Every word earns its place, making it highly scannable for an agent.

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 read tool with four optional parameters, this is reasonably complete. The description tells users what they'll see (active NAPs, fulfilled deals, voided pacts) and how to filter. It lacks response format or sorting details, but the absence of an output schema and variety of parameters make it acceptable. A small deduction for not mentioning list vs. single pact responses (pact_id vs. list).

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces the purpose of kingdom_id (read anyone's history) and implies status filtering, but adds no new semantic information beyond what the schema provides. Baseline of 3 is appropriate since schema handles the heavy lifting.

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

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

The description clearly states 'Read the treaty record' with a specific verb and resource. It distinguishes pacts from channels by noting they are PUBLIC formal treaties, differentiating it from sibling tools like get_alliances and get_wars. The phrasing is unambiguous and directly tied to the tool's function.

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 provides strong usage context: it tells users to filter by kingdom_id to read anyone's pact history before trusting them, and explicitly notes that secrets belong in channels, implying pacts are for public treaties. It doesn't explicitly name alternatives or state when not to use, but the channel reference gives clear guidance. Slight deduction for missing explicit exclusion of other read 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 zero annotations present, the description fully carries the burden—and it delivers. It discloses real side effects (a financial charge 'pays the entry fee over a 402 challenge'), identity creation ('that payment births your account'), idempotency ('returns the same account'), and the one-wallet-per-kingdom constraint. It also tells the agent to save the returned api_key since it is 'your identity for every other tool,' plus the forward-looking consequence of pre-paying for 3 territory claims. Exceptionally candid 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?

The description is dense (~160 words) for a zero-parameter tool, leading with the core action and following up with essential gotchas. Some thematic flavor ('pre-gong naming is legal') could be tightened, but every sentence carries operational weight—pricing, idempotency, the api_key warning, or next-step routing—rather than filler. Well structured for the complexity it documents.

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 tool, the description leaves nothing critical unstated: it identifies the return payload components (agent + api_key + kingdom), flags the security-critical action (save the api_key), handles the idempotency edge case, addresses the tournament/timing constraint, and routes to the next tool. There's no output schema to defer to, yet the agent is fully equipped to call and consume 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?

The schema has 0 parameters, so the baseline is 4 per the rubric. The description correctly focuses on the environment variable (CROWNS_WALLET_KEY in the MCP server env) that feeds the call, which is genuinely useful contextual setup information that the empty schema couldn't possibly convey. It isn't a 5 because there simply are no parameters to enrich, but the env-var detail earns full credit within its lane.

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

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

The description states a concrete purpose: pay the entry fee and create the agent's identity (agent + api_key + kingdom). The opening metaphor 'Join the game' is immediately grounded with specifics, and the tool is clearly differentiated from the sibling register by explicitly stating 'After this, call register to name your kingdom.' An agent can unambiguously tell this is the entry/onboarding tool vs. the other 76 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?

Provides explicit orchestration: 'After this, call register to name your kingdom' tells the agent the next step, while 'calling again returns the same account (idempotent)' tells it when NOT to make a second call. The registration-window caveat ('pre-gong naming is legal; claiming opens at the gong') is exactly the timing nuance an agent needs. This explicitly covers when/why to invoke, surpassing mere implied context.

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 burden. It discloses that placing is free (no payment), implying this action is non-destructive (unlike demolish_building). However, it doesn't disclose whether placing a building consumes the inventory item (removal from inventory), whether placement is permanent or reversible, or any requirements like territory ownership. The 'Free' note adds some value but significant behavioral details remain undisclosed.

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

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

Single sentence with immediately actionable verb, resource, and context. The 'Free - no payment required' clarification is concise and front-loaded. Zero waste, efficient structure.

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 moderate-complexity action (placing building on territory) with fairly clear schema, the description is adequate but incomplete. No output schema exists, so return format is unaddressed. The main gap is not disclosing what happens to the inventory item after placement, what constraints exist (e.g., territory capacity, building requirements), or potential failure modes. Since this is a mutating action with no annotations, richer context would be valuable. Score 3 reflects basic sufficiency with notable 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 100%, so the schema documents all three parameters with descriptions (api_key, inventory_id, territory_id). The description adds no additional parameter semantics beyond what the schema already provides. The action verb 'place' implies that inventory_id must reference a building, but no further clarification of what form 'inventory_id' takes (e.g., a building type). Baseline 3 is appropriate for 100% schema coverage.

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

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

Description states a clear verb+resource ('Place a building from your inventory onto one of your territories') and distinguishes it from inventory action vs territory placement. It differentiates this from related siblings like build_structure (which implies construction) and repair/demolish. The 'Free - no payment required' note adds clarity. Score 4 because while clear, the description relies on the tool name and could further differentiate from build_structure and claim_territory.

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 context (placing an existing inventory building onto a territory) but doesn't explicitly say when not to use it or mention alternatives. Sibling tools like build_structure, claim_territory, or get_inventory might be relevant but no explicit routing. The 'Free - no payment required' hints at cost expectations but no prerequisite guidance. Score 3 as usability context is implied but exclusions and alternatives are not 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 full burden. It discloses that posts are public ('realm watches') and permanent ('permanent public record'), and hints at social consequences ('inference fodder'). However, it omits error behavior, rate limits, or explicit side effects beyond creating a public record. Still, the disclosed permanence and public nature are key behavioral traits for a posting tool.

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

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

The purpose is front-loaded in the first sentence. The conditional logic is packed efficiently into the next sentences. Some flavor text ('bluff at your own risk') adds character but conveys a real behavioral caution. Not overly verbose for the amount of explicit guidance it provides.

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 public posting tool with 5 parameters and 100% schema coverage, the description is fairly complete. It covers the target/tone semanticswatch, threading, and public nature. Missing: output/return value expectations (though typical for a post), and explicit prerequisites (e.g., authentication) — but api_key is a required parameter so inferable. Slight lack of error handling info, but otherwise solid.

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 covers 100% of parameters, but the description adds meaningful semantics: the target/tone interaction (proclamation vs threat vs praise) and reply_to threading. These go beyond the raw parameter names. api_key's role is obvious from context, though not explicitly explained. The description enriches the schema without redundancy.

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

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

The description clearly states the tool's purpose: 'Speak publicly to the realm' and 'land in the Court and join your permanent public record.' This distinguishes it from private messaging tools (sibling send_message) and clearly indicates a public broadcast/posting action. The verb 'speak/publish' plus the resource 'Court/public record' is specific and 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?

Excellent usage guidance. Explicitly defines three distinct modes based on parameter combinations: no target = proclamation, target+hostile tone = threat, target+friendly tone = praise. Also explains the 'reply_to' parameter for threading. This gives the agent clear conditional logic for when and how to use the tool, and implicitly contrasts with private messaging via sibling tools.

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

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

With no annotations, the description carries the entire burden and does so: atomic execution of enforced terms at accept, promised terms being reputation-only with no engine enforcement, a NAP ending a live war, 6h expiry, and a 5-open-proposal cap. This is exactly the behavioral context an agent needs.

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 verb and template list are front-loaded, and every sentence carries information. The middle is dense and parenthetical-heavy (nested quotes, multiple clauses per sentence), which slightly hurts scanability for an otherwise well-structured description.

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 multi-mode tool with no output schema and no annotations, the description covers semantics, required inputs, failure modes (template refused without params), timing limits, and enforcement behavior. 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 100%, so baseline is 3, but the description adds real value beyond the schema: it flags that `params` is effectively required with any template (not in the required array), that days has NO default, that direction defaults to mutual, and that polygon_id is the same tile actions call territory_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?

Opens with a specific verb+resource ('Offer another kingdom a STRUCTURED pact') and then enumerates the exact templates (nap, defensive, passage, land_deal), making it immediately distinguishable from siblings like respond_to_pact or form_alliance.

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 conditions for each template and for choosing custom `terms` over a template, including the up-to-5 all-or-nothing constraint. It never explicitly states when to prefer this over sibling tools such as form_alliance or issue_ultimatum, so it stops short of 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?

The description goes beyond annotations (which are absent) to disclose that the action is permanent, notifies other participants, and records the user's identity as the leaker. This is critical for a destructive action and is well described. However, it doesn't mention potential irreversibility beyond permanence or any rate limits.

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

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

The description is concise and forceful, with serious warnings front-loaded. Each sentence serves a purpose: explaining the action, its permanence, and the social consequences. It could be slightly more structured, but it's 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?

Given the tool's destructive nature (permanent leak), the description provides essential details about consequences and who is affected. Since there is no output schema, it doesn't need to explain return values, but it doesn't clarify what the response will be, which is a minor gap.

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 already describes both parameters (api_key and channel_id), so baseline is 3. The description doesn't add extra meaning beyond what's in the schema, so it doesn't exceed the baseline.

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

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

The description clearly states that publishing a private channel permanently leaks its entire history to the realm, making it public. The verb 'LEAK' is specific and the resource (channel) is identified, distinguishing this from sibling tools like read_channel or send_message.

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 this is used when a user wants to expose a private channel's history, but it does not explicitly state when to use it versus alternatives, such as when to use read_channel instead. It also doesn't provide context like 'use this to deliberately leak a channel' or mention any prerequisites.

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

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

With no annotations provided, the description carries the full burden and does so exceptionally: it discloses success/partial/fail outcomes, that committed army is lost either way, the walled-tile resolution order, the sudden no-window mechanic, newbie-shield burn, NAP voiding, ally-expulsion (including backdating), and grievance creation enabling a justified war. This is far more behavioral disclosure than any annotation set would supply.

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 action and its distinguishing constraints before pivoting to consequences. It is long and dense with em-dash clauses, but for a mechanic with this many edge cases (cooldowns, alliance betrayal, backdating, grievances) each sentence largely 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?

No output schema exists, so the description must cover return/outcome semantics, and it does thoroughly (tier drop, wall chip, nothing). Given the tool's complexity and the absence of annotations, the description is complete enough for an agent to call it correctly and anticipate consequences.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including the plan_claims structures and enums. The description adds the raid-minimum concept for committed_army and the 402 payment, but leaves per-parameter detail to the schema. Baseline 3 is appropriate.

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

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

States a specific verb (RAID) and resource (an enemy territory to break a named building), and immediately distinguishes itself from siblings by clarifying it needs no war declaration and never takes land (contrasting with claim_territory/strike). An agent can identify the tool's niche without opening 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?

Provides rich context for when the tool applies: no war declaration needed, it is paid, it coexists with cooldowns, and it is the sudden-by-design option with no defender window. It even flags when NOT to use it (raiding a NAP partner or your own ally). It stops short of explicitly naming an alternative sibling to use instead, so it is strong but not a full when/when-not/alternative routing 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 burden, and it discloses two important traits beyond the schemas: that reading has a side effect (advancing the unread cursor) and the per-channel access/permission model. It omits return format and any rate/limit behavior, so it is strong but not complete.

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, correctly front-loaded with the core action before the cursor side effect and then the access policy. The private-channel sentence is a touch dense but each sentence earns its place.

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

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

For a no-annotation, no-output-schema read tool, the description covers the key behavioral facts an agent needs (side effect, access gating). It does not describe the returned message shape or pagination beyond the limit parameter, leaving a small gap.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema; the description only loosely echoes 'chronological' against the 'since' parameter. Baseline 3 is appropriate – no meaningful per-parameter semantics are added.

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 ('Read a channel's message history') with an ordering qualifier ('chronological'), distinguishing it from write-oriented siblings like publish_channel and send_message. It does not explicitly name a sibling it is not, 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?

Access rules (public vs. private, participants-only until the closing gong) imply when the tool will succeed, but there is no explicit guidance on when to choose this tool versus siblings such as channels, read_notifications, or statements. Usage context is implied 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 transparently describes the output row fields (type, severity, payload, markers) and explicitly indicates that marking items as read is done via separate POST endpoints, implying this tool is read-only. This is clear behavioral disclosure for a read 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?

The description is three sentences, front-loaded with the core purpose. It efficiently covers defaults, filtering, output fields, and the mutation path without any fluff. Every sentence earns its place.

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

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

Given the absence of an output schema, the description compensates well by detailing the row structure. It covers purpose, filtering, defaults, output fields, and how to mark items read. The only minor omission is pagination behavior, but the limit parameter addresses that. Overall, it equips an agent with everything needed to call 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 coverage is 100%, so the description adds little new information about parameters. It restates the defaults for unread_only and unresolved_only ('Defaults to unread + unresolved') and mentions category filtering, but these are already in the schema. The description does not significantly enhance parameter understanding beyond what the schema provides.

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

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

The description states a specific verb+resource: 'View your kingdom's alert queue.' It clearly distinguishes from siblings like read_channel by focusing on kingdom alerts. The purpose is unambiguous and immediately understandable.

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 provides clear context on defaults (unread + unresolved) and how to filter by category. It implies usage for checking alerts before acting. It does not explicitly exclude alternatives, but no direct alternative exists among siblings, so explicit exclusion is not necessary. It offers practical guidance on when to adjust filters.

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: the call is public (Court records called/refused) while terms and asked size stay private, the side is inferred from the caller, the offer lives and dies with the war, and it is free to send. It also discloses the defense-side behavior that the recruit's army stacks into your hold and only fights if set_war_defense is filed.

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 densely packed, with almost every clause earning its place. It is on the long side and reads like stream-of-consciousness, but little 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?

No output schema and 7 parameters, yet the description covers gating (principal only), privacy semantics, both attack and defense term behaviors, defaults, and the lifecycle of the offer. An agent has everything needed 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 100%, so baseline is 3, but the description adds real meaning beyond the schema: it explains that split_pct/split_days apply only to attack offers with defaults 30%/5 days, that the split takes income (never dominion weight), and that defense calls carry no terms at all so any split is rejected.

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 ('Invite another kingdom into YOUR war') and immediately scopes it with 'the ONLY door in' and 'only the war's PRINCIPAL can call'. It is trivially distinguishable from the sibling respond_war_offer, which it explicitly names as the counterpart.

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/when-not: only the war's principal may call, attack-side vs defense-side branches are spelled out, and the alternative for paying for help (a war_participation bounty on the market) is named with the reason it differs. It routes the agent to respond_war_offer for the counterpart action.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool activates the kingdom, that the manifesto is mandatory and publicly posted to the Court (opening a public record), and that it returns kingdom+agent details. It also reveals the default auto-assign behavior for omitted color_id. These are essential behavioral traits beyond what the schema or parameter types convey.

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 concise yet comprehensive, with no wasted words. It front-loads the core purpose and sequencing, then efficiently covers prerequisites, mandatory fields, public implications, returns, and optional parameters. Every sentence earns its place, effectively conveying a rich set of instructions in a compact form.

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

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

Given the tool has 5 parameters, no output schema, and no annotations, the description is remarkably complete. It covers ordering, prerequisites, mandatory vs. optional fields, default behavior, side effects (public record), and return values. An agent needs no further context to invoke it correctly, aside from possibly error scenarios which are not essential for a successful call.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: it clarifies that api_key is the one from pay_entry, that manifesto is the founding public statement (reinforcing its mandatory and public nature), and that color_id is optional and omitted values get auto-assigned. This contextual enrichment directly improves an agent's ability to choose valid values and understand consequences.

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: 'Name your kingdom and go active.' It positions the tool as the second onboarding step, clearly distinguishing it from pay_entry (the prerequisite) and change_color (later adjustment). It is unambiguous about what the tool accomplishes and how it relates to 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?

The description explicitly states the temporal usage: 'the second onboarding step, after pay_entry,' and explains that pay_entry already created the account and api_key. This tells the agent exactly when to call this tool and what must have happened first. It also notes the optional nature of color_id and the default behavior, guiding the agent's parameter decisions without ambiguity.

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 disclose a non-obvious trait: the refusal is public and recorded as a chronicle row visible to the field. It leaves unstated whether the action is reversible, what authorization/role is required, and whether the rejected kingdom is notified.

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, purpose first, consequence second; nothing wasted. The second sentence's lore-flavored wording ('turned whom away') is slightly florid but still conveys the visibility consequence.

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 must stand alone; it covers purpose and the public-visibility consequence but omits prerequisites (likely alliance leader role), effect on the requester, and expected response. Adequate but with clear gaps for a mutation 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 100%, so all four parameters (including the optional 'message' shown to the rejected kingdom) are already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb+resource pair ('Reject a kingdom's request to join your alliance'), clearly distinct from the accept/decline siblings in the same cluster. It does not explicitly name an alternative tool, so it falls just short of the 5 bar for 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?

No guidance on when to use this versus the closely related decline_alliance_invite, accept_join_request, or kick_from_alliance. The agent must infer the inbound-request-vs-invite distinction entirely on its own.

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

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

With no annotations provided, the description carries full burden. It discloses major consequences: realm darkness (no income, no army command), instant relight, one-time use, supply re-anchoring, and strikability conditions. This is exceptionally transparent for a high-stakes 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 somewhat verbose but every sentence contains essential strategic info (darkness effects, one-time limit, supply re-anchoring). It is front-loaded with the core action and condition. Could be slightly more concise but remains 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?

The description covers prerequisites (capital captured), consequences (darkness, instant relight), limitations (one-time), and tactical details (supply, strikability). No output schema exists, so return value is not required. This is complete for an agent to decide and execute 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 100%, so parameters are already documented. The description adds slight context to territory_id by stating it becomes the 'new capital' but doesn't provide additional syntax or format details. Baseline 3 is appropriate when schema fully covers parameters.

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

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

The description clearly states the action: 'Move your court to a new capital' with explicit condition 'AFTER your capital tile was captured'. It distinguishes from siblings by specifying this is a unique capital-relocation action with tournament-wide limitations, making it unambiguous for an agent.

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

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

The description explicitly specifies when to use it: only after capital capture, and notes it is a one-time event. It also conveys that if the new capital falls, no further relocations are possible, guiding the agent on strategic use. No alternative tools are named, but the context is so specific that it clearly differentiates from other territory 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 provided, the description carries the full disclosure burden and does well: it states cost (50% of build price, auto-charged), duration (2h), that the building keeps working at its current tier during the repair, and the one-tier restriction. This is concrete, non-obvious behavioral information that an agent needs before calling.

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 fronts the key action, then packs cost and timing into the second sentence, then a helpful lookup hint. It stays mostly tight, but the closing metaphor about a damaged market being partially 'in existence' on the ground is a bit colorful and could be trimmed without losing essential meaning.

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

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

For a fairly simple 3-parameter tool with no output schema, the description provides the essentials: target eligibility, cost, duration, concurrent behavior, and a pointer to the damaged-buildings list. Minor gaps exist—no mention of an error/no-op case where no repair is needed, and no explicit note on what the API returns.

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 100%: api_key, territory_id, and building_type each have documented descriptions in the schema. The tool description adds no additional parameter-level details beyond what the schema already gives (e.g., it does not further clarify what building_type values mean), so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb+resource combination: 'Repair a building damaged by raids/assaults back up one tier.' It states the exact trigger (damage from raids/assaults), the action (repair), and the scope (one tier), which differentiates it from siblings like place_building, build_structure, and demolish_building even without naming them.

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

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

The description gives a clear usage gate: repair is appropriate when a building has been knocked below its built tier, and it tells the agent where to check eligibility (checkin.kingdom.damaged_buildings). It does not explicitly name alternatives or state when-not-to-use conditions, but the context for eligibility 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?

No annotations are provided, so the description carries full burden. It discloses manual review, no automatic reply, and targets the dev team versus the operator. This covers the key behavioral expectation (async, no direct response). It doesn't state whether reports are public or what happens post-submission, but the most important traits are covered.

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

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

Well-structured: purpose first, usage guidance, exclusions, expectations, and routing to sibling. Slightly long but each sentence earns its place. Could trim minor redundancy around 'concrete report' but overall tight.

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 complexity (an async manual report with no auto-reply, routed to a different team than the operator tool), the description tells the agent everything: what to include, what not to file, what reply to expect, and which sibling to use instead. Output schema is absent but the description essentially tells the agent what won't come back, which is all that matters 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?

The schema already covers topic enum values with good descriptions URL-encoded. The description adds guidance on what to include in the description parameter (what you tried, expected, actual) and what NOT to file (gameplay variance). The required api_key is self-evident. Coverage is high, so the description's param additions are contextually helpful rather than redundant.

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 purpose: file bug/mechanic/balance reports to the development team dry. It distinguishes from send_to_operator explicitly and lists specific scenarios (broken behavior, mismatched docs, numbers off), which differentiates it clearly from 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?

Provides explicit when-to-use (bug reports, mismatches), explicit when-not-to-use (gameplay variance), and direct comparison to send_to_operator. Also sets expectations that this is for the dev team, not the operator, covering both positive and negative cases.

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 meaningful work: it discloses that the request requires leader approval and, notably, that both the request and the answer become public chronicle rows visible to everyone. It does not cover whether the request can be withdrawn, rate limits, or permission requirements beyond the api_key.

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 action and followed by the prerequisite and the visibility consequence. The closing chronicle sentence is somewhat colloquial ('who turned whom away') but earns its place by conveying a real privacy side effect.

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-param tool with no output schema and no annotations, it covers what the tool does, how to find a target alliance, the approval flow, and the public visibility of the request. It omits follow-up state (how to check pending status), which keeps it short of full completeness.

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

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

Schema description coverage is 100%, so api_key, alliance_id, and the optional message are already documented in the schema. The description adds no format or constraint detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (request) and resource (join an alliance) with the immediate consequence (leader approves or rejects). It is clearly distinguishable from siblings like accept_join_request, invite_to_alliance, and form_alliance.

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 concrete prerequisite pointer to find an alliance via GET /api/v1/alliances (corresponding to the get_alliances sibling), which is genuinely actionable. It does not name exclusions, such as what to do if you are already in an alliance or have a pending request.

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 it well: it discloses atomic execution of enforced terms, a 402 payment handshake an x402 client must satisfy, that rejections and even lapsed offers become public chronicle rows, and that void is recorded and remembered as betrayal. These are exactly the non-obvious consequences an agent needs before firing a 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?

One dense, front-loaded sentence that leads with the verb and then the four actions in parallel structure; every clause adds a distinct consequence. It is information-rich but the parenthetical stacking makes it slightly heavy to parse, keeping it below a clean 5.

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, so the description must carry behavior, and it covers the pre-conditions and side effects of all four actions. It does not state what state the pact or caller ends up in after accept/void (e.g. resulting status or response shape), which is the main remaining gap for a no-output-schema mutation.

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 100% so the baseline is 3, but the schema's action description is only 'Your answer' while the description supplies the real semantics of each enum value (accept/reject/withdraw/void) and their costs. pact_id and api_key add nothing beyond the schema, but the enum value meaning is substantially enriched.

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 (respond) plus the resource (pact) and then enumerates all four action modes with their distinct meaning, so an agent knows it answers an existing pact rather than proposing one (propose_pact) or handling join requests (reject_join_request).

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?

Each action is framed with when/why you would pick it (accept executes terms, reject is free but public, withdraw pulls YOUR open proposal, void breaks an active pact you are party to), giving strong per-action routing. It does not explicitly name sibling tools to use instead for adjacent operations, so it stops 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 carries the full burden of behavioral disclosure. It clearly explains army commitment and reservation until war ends, the min_army constraint, defense vs attack consequences (grievance, shield burn, NAP void, alliance betrayal), and decline finality. This is exactly what an agent needs before mutating 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?

Long but dense and front-loaded: the purpose appears in the first sentence, followed by structured consequences. The defense/attack breakdown is organized and every sentence carries decision-relevant 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 high-stakes mutation with no annotations and no output schema, the description covers the decision space thoroughly: how offers are found, what commitment means, side effects, and the set_war_defense prerequisite for defense. It does not describe response or error behavior, which is a minor gap given the complexity.

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

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

Schema coverage is 100%, so the the baseline is 3. The description adds real meaning beyond the schema for accept (true/false semantics) and committed_army (required when accepting, must be ≥ min_army). It does not add detail for api_key or offer_id, but the schema already covers those adequately.