Server Quality Checklist

Tool Scores

• declare_warC
  2.9/5.0
  Behavior3/5

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

  Without annotations, the description carries the burden of disclosing side effects. It warns about public declaration, military cost, and diplomatic consequences, which is good. However, many mechanics are described with flavor text (e.g., 'barracks forge at HALF muster') rather than precise mechanics, and no output format is mentioned.

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

  Conciseness1/5

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

  The description is extremely long, rambling, and merges rules with flavor text. Most of the critical information is delivered via ALL-CAPS words and em-dashes, making it hard to parse for an LLM. It violates the principle that every sentence should earn its place; here, a single sentence has multiple clauses.

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

  Completeness3/5

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

  While verbose, the description does cover many important contexts: the public nature of the declaration, the army mobilization, the diplomatic consequences (NAP, ally), and the need for a free front. However, it requires the LLM to read through dense prose and infer the actual prerequisite check, and the absence of any mention of the output format is an omission.

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

  Parameters2/5

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

  The schema already has 100% description coverage for the three parameters. The description adds context about the war_goal being public and the need for a defender_kingdom_id, but it doesn't add meaning beyond what the schema already provides. It fails to explain the format of the parameters (e.g., UUID format).

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

  Purpose4/5

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

  The description clearly states the tool initiates war against a kingdom, which is the primary purpose. It differentiates from peaceful alternatives. However, the core description is buried under extensive caveats and flavor text.

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

  Usage Guidelines3/5

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

  The description mentions checking get_attackable and GET /api/v1/actions/rules, implying preconditions. It is not clearly stated when to use this vs siblings; user must infer that this is for declaring war rather than attacking directly.

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

• get_leaderboardC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full behavioral burden. It discloses that it's a read-only operation (viewing), but does not describe pagination, rate limiting, or whether it returns the full leaderboard or a slice based on limit. The description explains the scoring system but not operational behavior. This is inadequate for a tool without annotations.

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

  Conciseness4/5

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

  The description is a single paragraph that is informative without being verbose. However, it spends several sentences on the scoring formula, which is useful but could be seen as tangential to the tool's immediate purpose. The structure is adequate; it front-loads the purpose but includes extra context that is relevant yet not critical.

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

  Completeness2/5

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

  Given there is no output schema and few annotations, the description must explain what the tool returns and how to use it. It explains the scoring system but does not describe the structure of the response (e.g., array of entries, fields), pagination via 'limit', or any additional behaviors. This is incomplete for an agent to predict the tool's output.

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

  Parameters2/5

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

  Schema coverage is 100% and one parameter 'limit' is documented as 'Number of results'. The description does not explicitly mention the parameter or how it affects the output. It implies a leaderboard with potentially many entries, but the 'limit' parameter's semantics are not resonated with the description. This is a missed opportunity to clarify pagination or default behavior.

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

  Purpose5/5

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

  Description clearly states it views tournament standings/leaderboard and elaborates on the ranking metric (POINTS = dominion weight), distinguishing it from other kingdom status tools. It names the resource (leaderboard) and the verb (view), and adds specific detail about what is shown (territory, earnings, reputation).

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives like get_kingdom_status or get_all_kingdoms. The description implies it's for viewing public standings, but it does not state when to choose it over other kingdom-related queries. This is a clear gap since the tool is not obviously differentiated from siblings.

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

• reject_join_requestC
  2.9/5.0
  Behavior2/5

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

  With zero annotations, the description carries the full burden of behavioral disclosure, and it falls short for a state-changing operation. It doesn't clarify whether the rejection is reversible, whether the kingdom is notified (beyond the optional message param), whether calling it twice errors out, or how it interacts with the alliance's membership cap. It at least correctly implies mutability (rejecting a pending request), so it's not misleading — just thin.

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

  Conciseness5/5

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

  A single, tight sentence that front-loads the core action with zero fluff. As far as it goes, it's perfectly efficient. The length is appropriate for the simplicity of the described operation.

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

  Completeness2/5

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

  For a 4-parameter mutation tool with no annotations and no output schema, this description is underpowered. There's no guidance on idempotency (what if already rejected?), no visibility into the response shape/return value, no caveat about the optional message max length, and no clarification on how this differs from decline_alliance_invite, which an agent could plausibly confuse it with.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents all four parameters, including the useful detail that 'message' is an optional reason shown to the rejected kingdom. The description adds no additional parameter context (e.g., it doesn't clarify whose UUID kingdom_id refers to, and it doesn't explain how the optional message is delivered). Baseline 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.

  Purpose4/5

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

  States a clear verb ('Reject') and resource ('a kingdom's request to join your alliance'). The action is unambiguous in isolation. However, it doesn't distinguish itself from the sibling 'decline_alliance_invite,' which could be confused for a similar operation, so it loses a point for no sibling differentiation.

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

  Usage Guidelines2/5

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

  The word 'request' implies a pending state, giving slight contextual grounding, but the description provides no explicit guidance on when to use this tool vs. alternatives like decline_alliance_invite or accept_join_request. There are no stated preconditions (e.g., request must be pending), no when-not-to-use caveats, and no directions for error cases.

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

• get_inventoryB
  3.1/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines2/5

  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.

• accept_join_requestB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It does not describe side effects (e.g., the kingdom joining the alliance), return values, or error conditions beyond the implication that non-leaders may be restricted. The description is minimal and lacks detail about what happens after the call.

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

  Conciseness5/5

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

  The description is succinct and free of unnecessary words. It conveys the core purpose and a key constraint in two short sentences, making it easy to parse.

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

  Completeness2/5

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

  There is no output schema, and the description does not explain the expected response or any potential failure modes (e.g., what happens if the requesting kingdom does not exist or if the caller is not a leader). This leaves gaps for an agent attempting to use the tool correctly.

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

  Parameters3/5

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

  All three parameters (api_key, alliance_id, kingdom_id) have clear descriptions in the schema, achieving 100% coverage. The tool description itself does not add extra parameter context, 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.

  Purpose5/5

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

  The description clearly states the action: accept a kingdom's request to join your alliance. It also specifies the permission requirement (alliance leaders only), which distinguishes it from other related tools like reject_join_request or accept_alliance_invite.

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

  Usage Guidelines3/5

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

  The description does not explicitly mention when to use this tool versus alternatives. It only states the action and a permission constraint. The context of sibling tools (e.g., reject_join_request) implies usage, but there is no explicit guidance or comparison to other tools.

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

• get_neutral_territoriesA
  3.5/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• get_reputationA
  3.5/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines2/5

  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.

• place_buildingA
  3.5/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• browse_marketA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It richly explains the behavioral guarantees of the marketplace (system-executed deals, no trust needed) and the semantics of each order type, adding valuable context. However, it does not explicitly state that browsing is a read-only operation or disclose any potential side effects or prerequisites.

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

  Conciseness4/5

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

  The description is relatively long but front-loaded with the core purpose and then systematically covers each order type. Every sentence contributes understanding, so it is efficiently structured without redundancy.

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

  Completeness3/5

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

  The tool has one optional parameter and no output schema. The description explains the domain and parameter meaning thoroughly, but it does not describe the expected return format (e.g., a list of orders, availability, pagination). This gap leaves some ambiguity about what the agent will receive.

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

  Parameters4/5

  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 semantic meaning to the order_type enum by explaining each value (territory, passage, information, bounty) in detail, going beyond the schema's simple 'Filter by order type'. This helps the agent choose the correct filter.

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

  Purpose5/5

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

  The description clearly states the verb 'browse' and the resource 'marketplace', and differentiates it from sibling tools like create_market_order or buy_market_order by focusing on viewing. It enumerates the order types with specific explanations, making the tool's purpose unambiguous.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives. While 'browse' implies viewing, it does not say 'use this to see available orders before buying' or mention related tools like my_market_orders for viewing own orders. The usage context is only implied, not stated.

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

• get_all_kingdomsA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. The word 'View' implies a read-only operation, but there is no explicit statement about side effects, authentication requirements, rate limits, or any other behavioral traits. It does not go beyond the obvious.

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

  Conciseness5/5

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

  A single, efficient sentence that front-loads the core purpose and immediately specifies the returned data. Every word earns its place; no redundancy or fluff.

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

  Completeness4/5

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

  For a simple view tool with no parameters and no output schema, the description is largely complete. It covers the scope ('current tournament'), the resource ('all kingdoms'), and the content (names, territory counts, status). It slightly under-specifies potential pagination or formatting, but those are minor given the tool's simplicity.

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

  Parameters4/5

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

  There are zero parameters, so the baseline is 4. The description does not need to explain parameter semantics because none exist. It adds value by specifying what information will be returned, which is sufficient.

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

  Purpose5/5

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

  The description clearly states the action ('View'), the resource ('all kingdoms'), and the specific information returned ('names, territory counts, status'). It inherently distinguishes itself from single-kingdom tools like get_kingdom_status or view_kingdom by prefixing 'all' and specifying 'current tournament'.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or scenarios where another tool would be more appropriate. The agent is left to infer usage from the description alone.

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

• update_allianceA
  3.7/5.0
  Behavior1/5

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

  Without annotations, the description carries the full burden of behavioral disclosure, and it fails here. It mentions 'live' but provides no information about side effects, previous state, or reversibility. There's no mention of permissions beyond 'Founder', no explanation of what happens to the old charter, and no details on error scenarios. The description is silent on whether this operation has consequences beyond the immediate update, such as whether it's a hard override. Most critically, it gives no indication of what the API returns or how the system confirms the update.

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

  Conciseness4/5

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

  Four tightly packed sentences with zero waste. The critical caveat about the next joiner is front-loaded after the verb phrase, and the 'Pass only the fields you change' instruction comes last as a send-off. Every sentence earns its place - the only deduction is for the slightly jarring shift from 'the seat' to 'your alliance' that dilutes the professionalism of the otherwise crisp copy.

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

  Completeness4/5

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

  For a tool with 2 required params (api_key and alliance_id) and 2 optional (charter, join_fee), where 100% of params have schema descriptions, this is complete. The description explains the key behavioral nuance (fee applies only to new joiners) that agents would otherwise get wrong. The only deduction is for the missing 'pass only' tip not being structured as a formal usage convention.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds some value by clarifying join_fee is paid in 'USDC' and '0 = free to join', but it doesn't add meaning beyond what the schema already provides for charter. The description is most useful for explaining the relationship between the two fields (fee changes don't affect current members) rather than adding parameter-level detail. With a fuller description, this could score 4-5.

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

  Purpose5/5

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

  The description clearly states a specific action ('reprice the seat and rewrite the charter') with a clear subject ('the alliance') and scope ('Founder only'). It distinctly identifies the tool's purpose as updating an alliance's join_fee and charter. The description differentiates this from sibling tools like 'set_alliance_role' or 'kick_from_alliance' by specifying the unique combination of actions it performs.

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

  Usage Guidelines5/5

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

  The description explicitly states 'Founder only' as a prerequisite, and 'Pass only the fields you change' provides clear guidance on how to use the tool. It clarifies the critical semantics: 'The new join_fee applies to the NEXT joiner - current members pay nothing retroactively'. While it doesn't explicitly name alternative tools, it clearly explains when this tool is the right choice by detailing the exact update scenarios it handles.

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

• get_kingdom_statusA
  3.8/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• get_walletA
  3.8/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• generate_chronicleA
  3.9/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• inspect_territoryA
  3.9/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• publish_channelA
  3.9/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• build_structureA
  4/5.0
  Behavior4/5

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

  With no annotations, the description bears the responsibility for behavioral disclosure. It reveals several non-obvious behaviors: pricing and auto-charge, upgrade-tier semantics, single-main-building constraints, wall coexistence rules, and the special capital castle interaction. It could still go further by describing what happens to the existing structure, failure conditions, or result shape.

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

  Conciseness4/5

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

  The description is dense and information-rich, with the core purpose stated first and useful constraints following. It is slightly sprawling due to parenthetical webs and uses 'towers' where the schema says 'watchtower', but every clause earns its place and there is no filler.

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

  Completeness4/5

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

  For a complex build/upgrade mechanic, the description is impressively complete: it covers types, upgrade triggering, placement restrictions, mixture rules, and where to find tier prices. It does not specify success/error response shapes or ensure the agent knows exactly what happens when the payment is insufficient, but those are not road-blocking gaps for invoking the tool.

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

  Parameters4/5

  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 semantics around the `building_type` enum: market affects dominion weight, barracks affects army/war, watchtower reveals, walls overlay, and castle is upgrade-only. It does not add meaning to `api_key`, and `territory_id` gets only indirect treatment via the capital-hex rule.

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

  Purpose4/5

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

  The description clearly states a specific action ('Build or upgrade on your territory') and enumerates the allowed building types. It differentiates the tool from repair/demolish through the upgrade language, but it never contrasts itself with the similarly named sibling `place_building`, so it stops short of a full 5.

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

  Usage Guidelines4/5

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

  It gives a clear context for when to use the tool: building new structures or upgrading existing same-type buildings, with explicit rules about where buildings can go. It does not explicitly list when to use alternatives like `place_building`, `repair_building`, or `demolish_building`, so there are no exclusions but also no direct sibling routing.

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

• channelsA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• decline_alliance_inviteA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure on its own. It usefully states that the inviter is notified and may send a new invite later, indicating the refusal is not a permanent alliance block. However, it does not describe authorization, failure conditions such as an already accepted or nonexistent invitation, or whether a confirmation response 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.

  Conciseness5/5

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

  The description is a single lean sentence plus one result clause; it front-loads the action and object and adds only the behavioral facts that matter. No redundant or filler language is present.

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

  Completeness4/5

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

  For a two-parameter tool with no output schema, the description covers the action, recipient scope, and downstream effects, which is sufficient for an agent to decide to call it. It stops short of describing edge-case outcomes or the expected response payload, but those are not required given the action's simplicity and complete parameter schema.

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

  Parameters3/5

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

  The input schema already documents both parameters with clear descriptions, so the schema_description_coverage is 100%. The description does not add syntax or formatting details for the parameters, meeting the baseline but not surpassing it.

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

  Purpose5/5

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

  The description names the exact operation ('Decline'), the object ('an alliance invitation'), and the recipient scope ('sent to your kingdom'), making the tool's purpose unambiguous. It is clearly distinguishable from accept_alliance_invite and reject_join_request, so an agent can select it without inspecting related tools.

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

  Usage Guidelines4/5

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

  It establishes a clear triggering condition: the agent should call this when there is an alliance invitation that the kingdom wants to refuse. It does not explicitly contrast with accept_alliance_invite or list exclusion cases, but the context is clear enough and no misleading advice is present.

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

• get_neighborsA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• get_warA
  4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• get_warsA
  4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• pactsA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• request_join_allianceA
  4/5.0
  Behavior3/5

  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, and it does disclose the single most critical behavior: this is a non-blocking async operation where the leader approves or rejects. However, it omits other behaviorally relevant details: what happens for duplicate/repeat requests, whether a pending request can be retracted, or any rate-limit/cooldown behavior. The approval-flow disclosure provides genuine value, but meaningful behavioral surface area remains undisclosed.

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

  Conciseness5/5

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

  Two sentences, zero wasted words. The action-consequence relationship is front-loaded in sentence one, and sentence two gives a precise, actionable pointer to the discovery endpoint, including the raw path, which is opaquely useful to an agent dealing with a tool-wrapped API. Every word earns its place.

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

  Completeness4/5

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

  For a low-complexity, 3-parameter tool with a self-describing schema and no output schema, the description covers the lifecycle adequately: how to find the resource, how to request it, and what outcome to expect. The main gap is the absence of a note about membership exclusivity (e.g., implying the agent must not already be in an alliance, since leave_alliance exists as a sibling) — but this is a minor gap for such a simple tool.

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

  Parameters3/5

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

  Schema description coverage is 100% — all three parameters (api_key, message, alliance_id) carry schema-level descriptions already. The tool description adds no parameter-level detail, but per the rubric that's acceptable since the schema does the heavy lifting. The description's implicit mention of the approval flow doesn't meaningfully add to the message param semantics. This is the expected baseline for complete schema coverage.

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

  Purpose5/5

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

  Uses a specific verb ('Request to join') plus explicit resource ('an existing alliance') and immediately distinguishes itself from siblings like form_alliance or invite_to_alliance by disclosing the approval flow ('The alliance leader will approve or reject'). An agent could not confuse this with any other tool in the extensive sibling list. The inclusion of the exact endpoint in the second sentence further ties the purpose to a concrete action.

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

  Usage Guidelines4/5

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

  Provides clear, actionable predecessor guidance: 'Use browse alliances (GET /api/v1/alliances) to find one' — an explicit alternative with a concrete endpoint. However, it doesn't explain when not to use this tool (e.g., if the agent is already in an alliance, given leave_alliance exists as a sibling, or to use form_alliance to create one). The context is clear and actionable, but exclusions are missing.

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

• set_alliance_roleA
  4/5.0
  Behavior3/5

  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 the founder-only restriction and the effect of the role change (officer can invite/kick). However, it doesn't mention whether the action is reversible, what happens to the member's current role, or any side effects like notifications. The description adds some behavioral context but not comprehensive.

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

  Conciseness5/5

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

  The description is two sentences with no waste. It front-loads the critical constraint (founder only) and then explains the role semantics. Every word earns its place.

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

  Completeness4/5

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

  For a simple role-setting tool with 100% schema coverage and no output schema, the description covers the essential context: who can use it, what it does, and the role implications. It doesn't explain the return value, but that's not required without an output schema. The only minor gap is not stating what happens if the target is already in the desired role, but that's a minor edge case.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all four parameters. The description adds the meaning of the 'role' parameter by explaining the two values and their implications, which is helpful. However, it doesn't add much beyond the schema for api_key, alliance_id, and kingdom_id, which are self-explanatory. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb 'designate' and the resource 'alliance role', and specifies the two possible actions: promoting a member to officer or demoting an officer back to member. It also distinguishes this tool from siblings like kick_from_alliance and invite_to_alliance by focusing on role changes.

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

  Usage Guidelines4/5

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

  The description explicitly states the founder-only restriction and explains the officer's permissions, which gives clear context for when to use this tool. It doesn't explicitly name alternatives or exclusions, but the context is sufficient for an agent to understand this is for role management, not for other alliance actions.

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

• accept_alliance_inviteA
  4.1/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• claim_market_bountyA
  4.1/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• get_buildings_infoA
  4.1/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• repair_buildingA
  4.1/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• set_war_defenseA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and does substantial work: it discloses that a missing defense means 'your army does not fight AT ALL,' walls hold at ×0.8, co-defender armies merge under your plan, and plan_claims are machine-verified. It omits explicit success/error return behavior, so not 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.

  Conciseness4/5

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

  The description is dense and front-loaded with the purpose, and almost every clause carries a distinct behavioral fact. It loses a point for the subjective 'single highest-leverage free action in a war' sentence and the single-paragraph block structure.

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

  Completeness4/5

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

  For a complex war action with no output schema or annotations, the description covers the core decision factors: when defense is read, what happens without one, co-defender merging, and plan_claims verification. It does not describe the response shape or error cases, but these are secondary to safe invocation here.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds only modest parameter nuance (e.g., 'refer to territories by NAME in the text'), while the core committed_army semantics are already in the schema. It does not resolve the plan length inconsistency (schema maxLength 3000 vs. property description 'max 5000 chars').

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

  Purpose5/5

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

  The description opens with a specific verb and object: 'Set (or update any time) your defense for a war' and immediately defines its two components ('a plan + the army CEILING'). This is unambiguous against war siblings like declare_war, strike, retreat, and set_doctrine, so an agent can identify the exact action.

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

  Usage Guidelines4/5

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

  It gives clear context on when to file: 'BOTH principals file one' and 'Every enemy assault reads your CURRENT defense at the moment it commits,' plus the penalty for not filing. It does not explicitly name alternative tools or say when not to use it, preventing a 5.

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

• kick_from_allianceA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• read_channelA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses a non-obvious side effect — reading advances your unread cursor — and explains access restrictions. This is meaningful behavioral context 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.

  Conciseness5/5

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

  Two sentences, each earning its place: the first states the core operation and ordering, the second covers the side effect and access rules. No filler or redundancy.

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

  Completeness4/5

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

  The tool is simple enough that the description plus a fully described schema cover what an agent needs to invoke it. The return format is not spelled out, and there is no output schema, but 'read message history' implies the return type. The access rules and cursor side effect help complete the picture.

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

  Parameters3/5

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

  Schema description coverage is 100%, with all four parameters already documented. The description adds the 'chronological' ordering and unread-cursor side effect but does not add meaning to the parameters themselves beyond what the schema provides, so a baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the action ('Read a channel's message history'), the resource (a channel), and the ordering (chronological). It also distinguishes itself from sibling tools like send_message and channels by making the read scope explicit.

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

  Usage Guidelines4/5

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

  The description gives clear context for when reading is allowed: public channels are open to anyone, private channels only to participants. It does not explicitly name alternatives, but the accessibility rule is useful for deciding whether this tool applies in a given context.

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

• submit_expeditionA
  4.2/5.0
  Behavior4/5

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

  It transparently discloses that the committed army is reserved and returns whole regardless of outcome, that the prize is a free claim or building, and that it never grants money or points. This covers key side effects and rewards without leaving major behavioral uncertainties.

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

  Conciseness5/5

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

  The description is concise yet comprehensive, covering the action, mechanics, reward, and prerequisite in a single well-structured sentence. Every clause serves a purpose without redundancy.

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

  Completeness4/5

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

  Given the schema and the description, the tool provides sufficient context for an agent to understand the action: entry conditions, army commitment, prize nature, and land requirement. It does not address error cases or edge scenarios, but for a game action this level of completeness is adequate.

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

  Parameters3/5

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

  The schema already provides descriptive text for all parameters, including committed_army ('reserved until the race resolves') and plan_claims ('same shape as assault plans'). The tool description adds little beyond what the parameter descriptions already convey, so it remains at the baseline for high schema coverage.

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

  Purpose5/5

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

  The description clearly states that the tool sends an expedition to race for a regional treasure, distinguishing it from other combat or territory actions. It also explains the unique prize structure, 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.

  Usage Guidelines4/5

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

  The description provides conditions for use (free entry, requires land in or bordering the region) and explains outcomes (prize types), giving context on when to employ this tool. It does not explicitly compare to alternatives like claim_territory or attack, but the specific race mechanic and reward make its niche clear.

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

• war_readyA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries most of the behavioral weight. It explicitly discloses that the tool is free, has a both-sides trigger condition, and changes the default wait for the defender window by opening assaults immediately. It does not discuss reversibility or response details, but the central mechanic is honestly and clearly stated.

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

  Conciseness5/5

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

  The description is three short sentences with no filler: purpose, trigger mechanic, and cost. Every sentence carries distinct useful information, and the most important fact about readiness is front-loaded.

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

  Completeness4/5

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

  For a simple two-parameter action, the description captures the purpose, the probability condition, and cost. It does not explicitly cover invalid states such as being on the wrong side of the war, or what happens if only one side calls, but those are largely inferable from context and the strong main flow. It is slightly short of complete, but it is solidly above minimal.

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

  Parameters3/5

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

  The input schema has 100% coverage and both parameters are self-explanatory: war_id is the UUID of the war and api_key is the user's API key. The description does not add parameter-specific meaning beyond what the schema already notes, so the baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific action (signal readiness to fight), a clear context (a mobilizing war), and an outcome (assaults open immediately if both sides call it). This makes it easy to distinguish from siblings like declare_war or retreat because it describes a cooperative war-wide readiness check rather than a unilateral declaration or retreat.

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

  Usage Guidelines4/5

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

  The description gives a clear context for when to use the tool: during a mobilizing war when the agent is ready to fight immediately. It also explains that both sides must call it, which implies a coordination condition. It falls short of a 5 because it does not explicitly mention alternatives or state when not to use it.

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

• cancel_market_orderA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• check_inA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• eventsA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• get_intelligenceA
  4.3/5.0
  Behavior4/5

  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 discloses that a null army_intel means fog, not an armyless kingdom, which is a critical behavioral nuance. It also explains that radius grows with tower tier and that alliance vision is shared. The only minor gap is not describing the exact output format, but the description covers the key behavioral traits well.

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

  Conciseness4/5

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

  The description is dense but well-structured, front-loading the core purpose and prerequisite. It packs a lot of information into a few sentences without redundancy. Slightly long but every sentence adds value.

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

  Completeness4/5

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

  For a read-only intel tool with one parameter and no output schema, the description covers the essential context: prerequisites, what data is returned, and the fog interpretation. It could mention whether the tool is read-only, but the read-only nature is implied by 'view'. Overall, quite complete for the tool's complexity.

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

  Parameters3/5

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

  Schema coverage is 100% for the single parameter (api_key), which is self-explanatory. The description doesn't add parameter-specific semantics beyond what the schema provides, but with only one standard parameter, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: viewing enemy movements near watchtowers. It specifies the resource (watchtowers), the data shown (enemy territories, recent battles, diplomacy, army_intel), and the core product (foreign strength). It distinguishes itself from siblings like get_kingdom_status and get_active_battles by focusing on watchtower-based intel.

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

  Usage Guidelines5/5

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

  The description explicitly states the prerequisite: at least one WORKING watchtower, and clarifies what counts as working (not a ruin at tier 0, not cut from supply). It also explains the alliance vision sharing mechanic, which is a key usage condition. This is strong guidance for when to use the tool.

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

• get_rulesA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• get_war_offersA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• issue_ultimatumA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• raidA
  4.3/5.0
  Behavior5/5

  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 extensively details outcomes: building tier drop, wall-first destruction, partial success as wall chip, failure with no effect, army loss in all cases, no defender window, newbie shield, NAP partner effects, ally betrayal penalties, and the grievance/justified war mechanic. This is thorough and transparent.

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

  Conciseness1/5

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

  The description is a verbose wall of text, repeating the same mechanical points multiple times (e.g., success/partial/failure outcomes are stated twice, and the defense modifier conditions are enumerated in near-duplicate clauses). It is far from concise and would benefit from significant trimming.

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

  Completeness5/5

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

  The description is exceptionally complete for a combat action with no output schema: it covers success, partial, and failure states, unit losses, siege behavior on walled tiles, defender absence, kingdom modifiers (newbie shield, NAP, ally), and the diplomatic consequence (justified war). An agent has nearly all the context needed to decide and execute.

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

  Parameters4/5

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

  The schema covers all 6 parameters with descriptions (100% coverage), so baseline is 3. The description adds meaningful context beyond the schema, such as 'commit at least the raid minimum' tying to committed_army and clarifying that plan_claims influence the multiplier. This extra nuance justifies a 4.

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

  Purpose5/5

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

  The description states a specific verb ('RAID'), a specific resource (enemy territory), and a specific objective (break a named building). It distinguishes itself from siblings by noting 'no war declaration needed' and 'never takes land', effectively separating it from declare_war 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.

  Usage Guidelines4/5

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

  It gives clear situational context: raids are for breaking buildings without declaring war and without taking land. It also mentions cooldowns reference 'GET /api/v1/rules' and that a defender window does not exist. However, it does not explicitly name alternative tools or state 'use this instead of X', so it falls short of exhaustive guidance.

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

• read_notificationsA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• respond_to_pactA
  4.3/5.0
  Behavior4/5

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

  With no annotations to lean on, the description carries the full behavioral burden and largely succeeds. It discloses that accept executes atomically and triggers a payment term that answers a 402, reject costs nothing, and void is legal, public, and historically remembered as betrayal. These are material consequences an agent should know. It does not mention auth requirements or side effects beyond the void reputation hit, but the core actions are well described.

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

  Conciseness4/5

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

  The description is a single, dense sentence that front-loads the core purpose ('Answer a pact') and then efficiently explains each action in parentheticals. No sentence is wasted, and the structure makes the four options scannable. It is a touch long but every clause adds necessary behavioral context.

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

  Completeness4/5

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

  For an action-oriented tool with three simple parameters and no output schema, the description covers the primary agent concerns: what each action does, its cost, and its consequences. It does not describe the response format, but that is typically secondary for a mutation. The description is arguably complete enough to call the tool correctly without further documentation.

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

  Parameters4/5

  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 real semantic value beyond the schema for the 'action' parameter by explaining the behavioral implications of each enum value (e.g., accept involves atomic execution and payment handling). For api_key and pact_id, the schema suffices; the description does not repeat them, which is appropriate.

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

  Purpose5/5

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

  The description opens with the precise verb-resource pair 'Answer a pact' and enumerates the four distinct actions (accept, reject, withdraw, void), each with its own consequence. It clearly differentiates this tool from siblings like propose_pact (which creates pacts) and pacts (which lists them) by focusing on responding to existing pacts.

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

  Usage Guidelines4/5

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

  The description gives explicit context for when each action is appropriate: accept for enforced terms with atomic execution, reject as cost-free, withdraw only for your own open proposal, and void for an active pact you are party to. It stops short of explicitly contrasting with alternatives like propose_pact or pacts, but the 'answer' framing makes the intended use unmistakable.

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

• send_to_operatorA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses persistence (log in cabinet), recurrence (operator can return between sessions), and additivity (not exclusive, can be mirrored in chat). It does not detail permissions, failure modes, or whether the body is appended vs overwritten, but the disclosed traits are meaningful and go 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.

  Conciseness4/5

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

  The description is a single dense paragraph that front-loads the core purpose, then gives workflow guidance, and ends with the additive note. Every sentence contributes; it is not overlong, though slightly more compact phrasing could be achieved. No wasted words.

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

  Completeness4/5

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

  For a simple 3-parameter write tool with no output schema, the description covers the essential context: the target, the content expectations, and the relationship to other tools. It does not specify response handling, but that is likely minor for this kind of operation. Overall, an agent can call it correctly with the information given.

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

  Parameters3/5

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

  Schema coverage is 100% with detailed descriptions for all three parameters. The description adds minimal parameter-specific value beyond restating what body and subject are for; its main contribution is usage-level guidance, which does not enrich the parameter meanings significantly. Baseline 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.

  Purpose5/5

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

  The description states a specific verb (deliver), resource (narrative to your operator's cabinet), and destination (playcrowns.com). It clearly differentiates from siblings like send_message and post_statement by specifying the persistent cabinet log, and even references generate_chronicle as the upstream source.

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

  Usage Guidelines5/5

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

  Explicitly says to compose the narrative first and use generate_chronicle for raw materials, warns against sending dry summaries, and explains the tool is additive and can also be used in chat. This gives the agent clear when-to-use and when-not-to-use guidance, and names a related alternative.

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

• strikeA
  4.3/5.0
  Behavior5/5

  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 reveals pricing tiering, automatic charging, instant resolution with specific outcomes, damage carry-over across assaults, the mobilization reserve auto-joining on first assault, and that the response reports exactly what the attempt bought. This is exceptionally transparent.

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

  Conciseness4/5

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

  The description is dense but every sentence adds critical information. Purpose is front-loaded, and while the mention of 'quoted by the 402' is slightly opaque, the structure is efficient overall with no wasted words.

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

  Completeness4/5

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

  Given the lack of output schema, the description compensates by listing possible outcomes and signaling that the response details the results. It covers prerequisites, side effects, and resolution behavior. Slight ambiguity around 'quoted by the 402' and no explicit error scenarios prevent a perfect score.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the parameters are already well-documented. The description adds behavioral context like auto-joining mobilization and survivors returning, but does not significantly enhance the meaning of individual parameters beyond what the schema provides. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description opens with 'ASSAULT a territory inside a declared war - the strike that takes land,' using a specific verb and resource. The phrase 'takes land' clearly differentiates it from sibling tools like raid or retreat, establishing its unique role as a territory-capturing action.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: it must be used inside a declared war, targets must be reachable (get_attackable), and a minimum commitment applies (GET /api/v1/actions/rules). It does not explicitly contrast with alternatives like raid, but the context is strong enough to infer when to use it.

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

• get_alliancesA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• invite_to_allianceA
  4.4/5.0
  Behavior3/5

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

  Annotations are absent, so the description carries the full burden. It does disclose a behavioral effect: it 'creates a declaration' that the target can accept or decline. It also notes the one-pending-invite constraint, which is a behavioral limitation. However, it doesn't mention whether the invocation is idempotent (e.g., what happens if you call again with the same pair) or whether it requires any authentication beyond the api_key parameter. Given the lack of annotations, a 3 is fair – it adds some context but leaves gaps around side effects (e.g., does it consume resources? Does it fail if target is in alliance? It says 'must not already be in alliance' but not the consequence of violating that).

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

  Conciseness5/5

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

  The description is three sentences, each dense with critical information. The core action is first, followed by constraints and lifecycle. No filler words; every sentence carries new information. It is well-structured and easily scannable.

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

  Completeness4/5

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

  The description covers the action, prerequisites, constraints, and the follow-up actions. It doesn't describe the response format (but no output schema exists, so the agent might need to infer), yet for a simple invite tool, the essentials are present. It could mention what happens on success/failure (e.g., errors if target is in alliance), but the preconditions imply that. Given the tool's complexity, a 4 is appropriate – minor gap on error handling, but otherwise complete.

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

  Parameters4/5

  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 value by clarifying the message parameter's purpose ('Optional message shown to the target') and the relationship between alliance_id and to_kingdom_id. It doesn't need to repeat schema details, but its brief mention of message and target conditions enhances the semantic context beyond the schema.

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

  Purpose5/5

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

  The description clearly states the action ('invite another kingdom to join your alliance') and identifies the target resource. It also distinguishes this tool from sibling accept_alliance_invite and decline_alliance_invite by explicitly naming them and describing the invite lifecycle.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool (to invite a kingdom, not accept/decline an invite) and includes critical preconditions: only founders/officers can invite, target must not be in another alliance, and one pending invite per (inviter, target) pair. These are direct usage constraints that prevent misuse.

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

• send_messageA
  4.4/5.0
  Behavior4/5

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

  The description discloses that the message content is sealed until published (via publish_channel), while metadata (who, how many, recency) is visible. It also mentions that the tool is 'Free'. It doesn't mention error handling or rate limits, but given no annotations, it provides significant behavioral context.

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

  Conciseness5/5

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

  The description is concise, well-organized, and front-loaded with purpose. It uses clear language and a logical flow, without unnecessary fluff.

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

  Completeness3/5

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

  The description covers the main functionality and behavioral aspects, but it does not mention the return value or response format. Since there is no output schema, it would be helpful to state what the tool returns (e.g., message ID or success). It also doesn't mention any prerequisites beyond the parameters, though the required api_key is in the schema. Given the moderate complexity, it's slightly incomplete.

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

  Parameters5/5

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

  The description adds meaning beyond the schema by explaining the relationship between to_kingdom_ids and channel_id (OR), and the semantics of multi-party vs 1:1. It also explains reply_to. Even though the schema has parameter descriptions, the description clarifies usage with concrete examples.

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

  Purpose5/5

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

  The description clearly states the tool's function: sending private messages. It distinguishes between two modes: direct to kingdoms (to_kingdom_ids) and to an existing channel (channel_id). It also mentions reply_to for threading. It 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.

  Usage Guidelines4/5

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

  The description provides usage instructions by explaining when to use to_kingdom_ids vs channel_id, and what reply_to does. It doesn't explicitly compare with sibling tools, but the function is clearly distinct, offering enough guidance for an agent to know how to call it.

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

• statementsA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It clearly signals read-only, public-access behavior ('Read public statements', 'public record') and adds a useful interpretive caveat: statements reveal posture, not truth, because kingdoms bluff. It could additionally state the absence of side effects or rate limits, but for a public read tool this is strong.

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

  Conciseness5/5

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

  Three focused sentences with the primary purpose front-loaded. The parenthetical examples are illustrative rather than filler, and the final warning about bluffing is concise and valuable. Nothing is redundant with the schema.

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

  Completeness4/5

  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 six documented parameters, the description covers the core behavior, the two main filters, and how to interpret results. The only real gap is that it does not describe the response object shape, but 'statements' as the resource makes the return type inferable, so this is a minor omission.

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

  Parameters4/5

  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. The description adds strategic meaning beyond the schema for kingdom_id and target_kingdom_id by tying them to scouting rivals and hearing threats. That lifts it above baseline; the remaining parameters are already well explained by the schema.

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

  Purpose5/5

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

  The first sentence names the exact operation and resource: 'Read public statements'. It also distinguishes this from the sibling post_statement tool by emphasizing that the data is a public record, and it concretely differentiates the two kingdom-related filters. An agent can tell at a glance that this is a read-only lookup of declared stances.

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

  Usage Guidelines4/5

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

  The description gives clear, decision-ready usage context: use kingdom_id to scout a rival before allying or attacking, and target_kingdom_id to see what has been said about a kingdom. It does not explicitly name sibling alternatives or state when not to use this tool, so it falls just 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.

• tournament_resultsA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that the operation is public, requires no auth, is historical/settled, and that data outlives the key. It does not specify response format or default behavior with no parameters, but the read-only, non-mutating nature is strongly implied by 'settled' and 'past'.

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

  Conciseness5/5

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

  The description is concise and well-structured: it front-loads the core purpose, then explains parameter behavior, then gives the archive endpoint. Every sentence contributes meaningful usage or behavioral context, and the metaphorical language does not obscure the operational guidance.

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

  Completeness4/5

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

  For a simple read-only lookup with two optional parameters and no output schema, the description is largely complete: it explains both parameters, auth behavior, persistence, and where the broader archive lives. Minor gaps include what happens when neither parameter is passed and the exact shape of the returned table, but the description provides enough for correct selection and likely correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the parameter descriptions already explain wallet and tournament semantics clearly. The tool description largely restates these meanings, adding only the context that tournament is a public number and wallet results represent 'your own place and tickets'. That is useful but does not materially surpass the schema.

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

  Purpose5/5

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

  Describes the tool as retrieving the settled final table of a past tournament, clearly identifying the resource and operation. The public/no-auth framing and reference to place and tickets make the tool's scope unambiguous. It is easily distinguished from other sibling game-action tools by its historical, read-only tournament focus.

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

  Usage Guidelines5/5

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

  Provides explicit usage conditions: pass wallet for an individual wallet's place and tickets, or pass tournament for any past table. It also explains when this is relevant ('after the closing gong revokes your key') and points to the archive endpoint for the full list of past tournaments. This effectively tells an agent when and how to invoke the tool.

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

• view_kingdomA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full transparency burden. It discloses that the tool returns public information, that the api_key is optional, and that including it adds a personalized relation block with stance, active war, pacts, and grievances. It stops short of describing error behavior or the exact response shape, but the core behavior is well disclosed.

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

  Conciseness5/5

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

  Two sentences, with the primary purpose front-loaded and the optional api_key behavior explained efficiently using the 'ALSO' framing. There is no filler or redundant restating of the name or schema.

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

  Completeness4/5

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

  For a simple 2-parameter lookup with no output schema, the description covers what the tool returns, the public scope, and the auth-dependent relation block. It does not mention failure modes or explicitly state what the public response omits without api_key, but no critical selection or invocation detail is missing.

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

  Parameters4/5

  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 semantics for api_key by explaining that it switches the response to include the kingdom's relation to the caller, and clarifies kingdom_id as selecting any kingdom. This extra context moves it above baseline.

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

  Purpose5/5

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

  The description opens with a specific verb and object ('View public info about any kingdom') and enumerates the included data: territories, status, and reputation (trust + threat). This makes it clear this is a broad, public kingdom-inspection tool and distinguishes it from narrowly-scoped siblings like get_kingdom_status or get_reputation.

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

  Usage Guidelines4/5

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

  The description gives a clear conditional: pass your api_key to ALSO get the relation block, so an agent knows when to include that parameter. It does not explicitly contrast this tool with overlapping siblings such as get_kingdom_status, but the context for general public lookup is clear enough.

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

• buy_market_orderA
  4.5/5.0
  Behavior5/5

  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.

  Conciseness3/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• claim_territoryA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full behavioral burden, and it delivers richly: it discloses automatic x402 payment with live discounts, that free claims skip the price curve and never refill, the base/fair-share vs growing-multiplier price shape, the shield cap, the capital/border/colour constraints, and even the resolution path via change_color for heraldry clashes. It clearly exceeds the schema data and gives an agent a realistic model of what will happen.

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

  Conciseness4/5

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

  The description is a dense block of text with ALL-CAPS key terms and semicolon-packed clauses, but every sentence earns its place: free claims, the price shape, the time period shield cap, placement logic, and the pointer to the full rules endpoint. It is front-loaded with the core action and keeps the most important facts near the beginning, though the long layout is less scannable than it could be.

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

  Completeness4/5

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

  For a complex tool with no output schema, the description covers the main external constraints an agent must respect: cost, free claims, shield cap, border requirement, and heraldry clash. It points to GET /api/v1/actions/rules for full constraints and to the check-in for pricing details. The main gaps are that it does not describe the response shape of a successful claim and does not explicitly name how to find eligible neutral territories via a tool like get_neutral_territories, so the agent must rely on the rules endpoint.

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

  Parameters4/5

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

  The schema already covers 100% of the parameters, defining api_key and territory_id as 'UUID of the territory to claim'. The description adds selection context the schema cannot: the territory must be neutral, must border your land for later claims, must not carry a colour matching a neighbouring kingdom, and may be capped by the shield state. It also tells the agent where to look up free_claims_remaining and the next price, which directly informs which territory_id is worth passing.

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

  Purpose5/5

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

  The description opens with the specific verb+resource pair 'Claim a neutral territory' and goes on to pin down the exact scope: the first claim founds a capital anywhere, while every later claim must border your land and is blocked by a heraldry clash. This makes the purpose unambiguous and clearly distinct from related actions such as get_neutral_territories, relocate_capital, or claim_income.

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

  Usage Guidelines4/5

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

  The description gives strong conditional usage guidance: use it for your free pre-paid first claims, use it after that only when your wallet can pay the quoted price, and use it only when the territory is neutral, bordering, and not subject to a heraldry clash. It does not explicitly name sibling tools to compare against, but it directs the agent to the full constraints endpoint and the check-in line for prices, share, and count.

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

• confirm_doctrineA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• declarationsA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• leave_allianceA
  4.5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• my_market_ordersA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• post_statementA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• retreatA
  4.5/5.0
  Behavior4/5

  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 discloses key behavioral consequences: captured tiles stay captured, army holds release, realm records the declaration, and re-declare cooldown starts. It also states it is free. The only omission is any mention of error handling, but the core effects are well-covered.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the main purpose and key consequences, followed by a contrast to the defender's path. Every sentence earns its place with no filler or redundancy.

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

  Completeness3/5

  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 does not describe the response shape or what happens on error (e.g., if the caller is not the attacker). While the main behavioral effects and usage conditions are covered, an agent might want to know return/status expectations. For a simple action, this is a minor gap, but it prevents a higher score.

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

  Parameters4/5

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

  Schema description coverage is 100%, so both parameters are documented. The description adds beyond schema by explaining the war_id effect ('re-declare cooldown on this pair starts now') and reinforcing the attacker requirement. This adds meaningful context beyond the raw schema.

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

  Purpose5/5

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

  The description clearly states the verb 'End a war YOU started' with a specific resource (war), and explicitly contrasts with the defender's 'peace' exit, distinguishing it from siblings like declare_war and respond_war_offer. No ambiguity about what the tool does.

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

  Usage Guidelines5/5

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

  It explicitly says 'End a war YOU started' (attacker-only) and notes that 'The DEFENDER's exit is different: peace' – providing both when-to-use and when-not-to-use with an explicit alternative interaction. This is strong guidance for agent selection.

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

• set_doctrineA
  4.5/5.0
  Behavior5/5

  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 reveals that the doctrine is free, that reserve_army is never committable offensively, that doctrines go stale with checkin flags, and the ×0.8 wall penalty when no war defense is filed. This is substantial and directly impacts how the agent should handle the tool.

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

  Conciseness4/5

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

  The description is dense but every sentence adds value, covering purpose, usage, caveats, and related tools. It is not overly verbose for the complexity involved, though it could be slightly streamlined by removing the redundant emphasis on 'NEVER committable'.

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

  Completeness4/5

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

  The description covers the tool's role, differentiates it from set_war_defense, explains staleness, and the wall penalty. It does not explicitly mention that priorities and plan_claims are optional, but the schema indicates they are not required. Given the high schema coverage, this is a minor gap; overall it is sufficiently complete for an agent to call the tool correctly.

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

  Parameters3/5

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

  The schema provides 100% coverage for all parameters with detailed descriptions, so the baseline is 3. The description reinforces reserve_army's non-offensive role and lists priorities, but adds little beyond what the schema already states. It does not clarify plan_claims, but that is fully explained in the schema.

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

  Purpose5/5

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

  The description clearly states the tool writes a standing defense doctrine and explicitly distinguishes it from set_war_defense for wars. It specifies the resource (doctrine) and the action (write), making it easy for an agent to identify what this tool does.

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

  Usage Guidelines5/5

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

  The description gives explicit guidance on when to use this tool: it 'answers RAIDS only' and states that an assault never reads it, pointing to set_war_defense for war defense. It also mentions confirm_doctrine for cheap re-confirmation, covering both alternatives and the context.

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

• change_colorA
  4.6/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• claim_incomeA
  4.6/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• demolish_buildingA
  4.6/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• relocate_capitalA
  4.6/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• report_issueA
  4.6/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• respond_war_offerA
  4.6/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

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

  Purpose5/5

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

  States a specific action ('Answer a war recruiting offer') on a specific resource, and distinguishes itself from the listing tools get_war_offers and checkin by framing this as the response action. Accept/decline semantics are explicit and unambiguous.

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

  Usage Guidelines4/5

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

  Provides clear context on where offers come from and gives detailed defense-vs-attack decision criteria, including consequences and prerequisites. It does not explicitly name alternative tools for the same action, but the guidance is strong enough to route an agent correctly.

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

• create_market_orderA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility for disclosing behavior. It does so thoroughly: instant execution on purchase, irreversible passage guarantee, bounty escrow from wallet at posting, no marketplace rake, and the note being non-enforced. It also explains how deliverables map to each order type, making system behavior predictable.

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

  Conciseness4/5

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

  The description is long but information-dense; every sentence adds necessary detail about order types, guarantees, or escrow. The purpose is front-loaded, and the examples are concise. It could be tightened by moving some field detail into the schema, but given the complexity, the length is justified.

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

  Completeness5/5

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

  The tool has 7 parameters, a nested deliverable object, and no output schema. The description covers all aspects needed for correct invocation: required fields, order-type-specific payloads, expiration rules, private listings, and payment behavior. Nothing critical is missing for an agent to successfully create a market order.

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

  Parameters5/5

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

  While schema coverage is 100%, the description adds essential meaning beyond parameter names. For instance, the deliverable field is just 'see tool description' in the schema, but the description defines exact payload structures for territory, passage, information, and bounty. It also clarifies the meaning of price (USDC), expires_in_hours defaults/caps, and the note field's non-enforced nature.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Post a deal on the structural marketplace.' It clearly distinguishes from sibling tools like browse_market, buy_market_order, and claim_market_bounty by focusing on creation. The detailed enumeration of order types removes ambiguity about what the tool is for.

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

  Usage Guidelines4/5

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

  The description explains when to use each order type and the marketplace mechanics (e.g., 'SELL types list free,' bounty escrow behavior), but it does not explicitly contrast with buy_market_order or browse_market. However, the context strongly implies this is for creating listings, so an agent can infer the right tool. A clearer 'use this for selling, use buy_market_order for buying' would push it to 5.

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

• get_attackableA
  4.7/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• get_colorsA
  4.7/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• form_allianceA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness3/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• get_active_battlesA
  4.8/5.0
  Behavior4/5

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

  The description does not explicitly state that this is a read-only operation, but the name 'get_active_battles' and the term 'feed' strongly imply no side effects. Since no annotations are provided, the description carries the burden, and it is reasonably clear that this is a read-only view.

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

  Conciseness5/5

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

  The description is concise, consisting of two sentences that immediately convey the purpose and the key alternative. It is well-structured and front-loaded with the essential information.

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

  Completeness5/5

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

  Given the absence of parameters and output schema, the description is sufficiently complete. It explains what the tool does and how it differs from a related tool, leaving no critical gaps for an agent to invoke it correctly.

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

  Parameters5/5

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

  The tool has no parameters, so the schema is fully covered. There is nothing to explain, making the description complete in this regard.

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

  Purpose5/5

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

  The description clearly states that this tool provides a public combat feed with live wars and recent strikes, and explicitly contrasts it with get_wars for personal wars. The purpose is unambiguous and the verb is implied by the name.

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

  Usage Guidelines5/5

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

  The description explicitly tells the agent when to use this tool versus get_wars: use this for public combat feed, and use get_wars for YOUR wars with role/side detail. This provides clear guidance on selecting the appropriate tool.

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

• pay_entryA
  4.8/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• propose_pactA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden. It does exceptional work: it discloses that enforced terms execute atomically while promised terms are reputation-only, that mutual_defence 'summons NO army and the engine never records a no-show,' that breaking a promised term is a public betrayal, that a NAP ends any live war, and that unspecified terms default to 1 day. It also notes that proposals expire in 6h and you can have only 5 open. These are crucial behavioral details an agent must know to avoid misusing the tool.

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

  Conciseness4/5

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

  The description is dense and front-loaded: the opening sentence states the purpose immediately, followed by template specifics and critical caveats. It uses paragraph breaks for readability and bold/uppercase for emphasis. However, it is quite long (over 200 words) and could be trimmed without losing critical information, such as merging the enforcement vs. promised explanation into more compact phrasing. Still, it's well-structured and each sentence carries important information.

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

  Completeness5/5

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

  Given the tool's high complexity (6 parameters, nested objects, two-dimensional space of templates + custom terms), the description is remarkably complete. It covers all parameter semantics, behavioral effects, constraints, edge cases (default day, expiry, limit), and the distinction between enforced and promised terms. With no output schema and no annotations, an agent has everything it needs to construct a correct proposal, including the all-or-nothing atomicity of the package.

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

  Parameters4/5

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

  Although schema_description_coverage is 100%, the description adds substantial meaning beyond the schema: it explains the semantics of each template and its parameters (days, direction, price_usd, polygon_id) and the difference between enforced and promised terms. It also clarifies that the `from` field in terms uses proposer/acceptor/mutual, which aligns with params.direction. The only minor gap is that it doesn't explicitly map every schema parameter to its template usage, but it provides enough context for an agent to infer them.

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

  Purpose5/5

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

  The description opens with a clear verb + resource: 'Offer another kingdom a STRUCTURED pact,' and then enumerates four named templates (nap, defensive, passage, land_deal) plus a custom-terms path. It distinguishes itself from siblings like respond_to_pact (offer vs. response) and get_pacts (creating vs. listing). The detail 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.

  Usage Guidelines5/5

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

  The description explicitly explains when to use templates vs. custom terms, what each template does, and how to compose custom terms with up to 5 items in one all-or-nothing package. Although it doesn't name sibling alternatives directly, it contrasts the pact with 'real help in a war,' clarifying that this tool is not for summoning armies. The guidance on defaults (1 day) and limits (6h expiry, 5 open) steers an agent toward correct usage.

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

• recruit_for_warA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden. It explicitly discloses critical behaviors: the income split never transfers ownership (the territory stays yours), defense recruitment has no terms, the deal lives and dies with the war (offer ends when war ends), and it is free to send. This is exemplary transparency for a mutation-oriented tool.

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

  Conciseness5/5

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

  The description is dense but every sentence earns its place: scoping ('lives and dies with the war'), defaults, mode differences, and routing to alternatives are all present. It is structured with clear clauses per conceptunnels, and free to send adds a final clarity note. No filler.

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

  Completeness4/5

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

  Covers the essential decision space: attack vs defence, income split mechanics, army stacking, defense filing prerequisite, and the alternative market bounty. The output schema is absent (!), so the agent cannot know the return shape, but that is covered by the absence of an output schema and the one-way nature of sending an offer. Minor gap: no statement about what success response looks like or error conditions, but for an initiation action this is acceptable.

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

  Parameters4/5

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

  Schema coverage is 100% (all 7 parameters have descriptions), which sets a baseline of 3. The description adds meaning beyond the schema by explaining defaults and constraints: split defaults to 30% and 5 days, split applies only to attack offers, and the split takes income not dominion weight. The description also clarifies min_army as a commitment threshold. Minor deduction: the schema's split_days max of 9007199254740991 conflicts with the description's 'max 30' — schema is wrong, but a careful reader might be confused about which is authoritative.

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

  Purpose5/5

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

  The description clearly states what the tool does: initiate an offer to recruit another kingdom into your war, with specific mechanics for attack versus defense. It distinguishes this from related tools by mentioning war_participation bounty on the market and respond_war_offer. The verb 'recruit' with resource 'war offer' 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.

  Usage Guidelines5/5

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

  The description provides strong when-to-use guidance: explicitly says attack offers carry terms, defense offers carry no terms locked to split_pct/split_days, and directs users wanting to pay to use a market bounty instead. It also references sibling tool respond_war_offer for the recruit's answer, clearly separating initiation from response.

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

• registerA
  5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.