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

Discloses mutation (mutates live config), auto-injection of projectId, and destructive nature of delete paths. Annotations indicate readOnlyHint=false and destructiveHint=false, but description adds critical context. No contradiction.

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

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

Description is moderately long but well-structured with clear sections: purpose, usage instructions, warnings. Every sentence adds essential information without redundancy.

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

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

As a generic tool, providing exhaustive output details is impractical. Description offers references for endpoints and essential safety warnings, making it sufficiently complete for the intended use.

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

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

Schema has 100% description coverage for all 3 params. Description adds value by explaining path format (without /v1/ prefix) and auto-injection behavior for injectProjectId, beyond what schema provides.

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

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

Description clearly identifies the tool as an escape hatch for any /v1 admin endpoint lacking a dedicated tool. It lists example paths and references endpoint indices, making the purpose specific and distinct from sibling tools.

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

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

Explicitly instructs to find exact path and body in references, warns about mutation, requires user confirmation, flags 'delete' as destructive, and advises to prefer staging. Provides clear when-to-use and precautions.

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

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

The description discloses key behavioral traits beyond annotations: it grants the reward to wallet/inventory and flips status from pending to completed. Annotations indicate it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), consistent with the description. No contradiction.

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

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

The description is concise: two sentences, no filler. It front-loads the main action and then explains the effect and identification method. Every sentence earns its place.

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

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

Given no output schema, the description explains the tool's effect and input identification well. It mentions 'test player' which may be domain-specific but is clear. It does not detail return values, but that is acceptable without output schema. The complexity (3 params, no nesting) is fully addressed.

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

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

The schema has 3 parameters with 67% description coverage. The description adds meaning by explaining that 'source' is the slug/id and that 'type' identifies the source (e.g., task). However, it does not add detail beyond the schema for 'instanceId' or enumerate the type enum values. The added value is moderate, meeting the baseline expectation.

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

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

The description clearly states the verb (claim) and resource (pending reward from a source), explains the effect (grants reward, flips status), and distinguishes from sibling tools by specifying it's for claiming ON-CLAIM rewards from completed tasks/missions. It is specific and actionable.

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

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

The description provides context for when to use (after an ON-CLAIM reward completes, to claim pending rewards) and how to identify the source (by slug/id and type). It does not explicitly exclude alternatives like specter_grant_reward, but the context implies this tool is for claiming pending rewards, not direct granting.

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

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

Annotations indicate readOnlyHint=false and openWorldHint=true, which align with the description of a POST operation that mutates game state. The description adds transparency by revealing that it sends the test-player bearer token by default and that asPlayer=false switches to api-key-only catalog reads. It does not contradict annotations.

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

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

The description is two concise sentences plus a key note on asPlayer. Every sentence adds value: the first defines the purpose, the second provides usage guidance and examples, the third clarifies authentication behavior. No wasted words.

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

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

Given that this is an escape hatch tool with 3 parameters and no output schema, the description is complete enough. It points to external references for exact paths and bodies. It could mention error handling or response format, but for an escape hatch tool, the provided guidance is sufficient.

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

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

Schema coverage is 100%, but the description adds significant value beyond the schema: it explains that path should be without the '/v2/client/' prefix, that body should be found in client API references, and that asPlayer defaults to true (test player) but false for catalog reads. This is highly informative.

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

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

The description clearly states it is an 'escape hatch' for the game-facing API, specifically POST to any /v2/client/* endpoint as the sandbox test player. It provides concrete examples like 'player/me/get-inventory' and distinguishes itself from the many dedicated sibling tools that exist for specific endpoints.

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

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

The description explicitly says 'Use for client calls that lack a dedicated tool', giving clear direction on when to use it. It also explains the asPlayer parameter (true for test player, false for api-key-only reads). While it doesn't explicitly list when not to use it, the implication that dedicated tools should be preferred is strong given the sibling list.

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

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

Annotations indicate it's not read-only (readOnlyHint=false) and has open world implications (openWorldHint=true). Description adds valuable detail: 'MUTATES live game config' and recommends staging, clarifying side effects and safety. No contradiction with annotations.

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

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

Two concise sentences with no extraneous information. Front-loaded with 'Create a battle pass.' Each sentence serves a purpose: stating the function and adding behavioral guidance.

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

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

No output schema and 5 parameters with 60% coverage. Description covers the core function and mutation behavior. References external documentation for `fields`. Could specify return values or error handling, but sufficient for admin tool with cautionary note.

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

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

Schema coverage is 60% (3 of 5 params have descriptions). Description explains the key `fields` parameter: 'tiers (free/premium rewards per tier) go in `fields`' and references the admin skill for full schema. This adds meaning beyond the schema's generic description.

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

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

Clear verb 'Create' and specific resource 'battle pass'. Mention of 'tiers (free/premium rewards per tier) go in `fields`' adds specificity. Distinguishes from many other create_* sibling tools by focusing on battle pass.

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

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

States mutation warning: 'MUTATES live game config — confirm with the user and prefer staging.' This provides clear usage context and caution. Does not explicitly name alternatives, but the warning is strong guidance.

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

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

The description adds value beyond annotations by specifying that the tool mutates live game config and advising confirmation and staging preference. Annotations indicate readOnlyHint=false but do not convey the severity (live config mutation). No contradiction with annotations.

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

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

Two sentences with no wasted words. The first sentence front-loads the core action, and the second adds essential behavioral nuance and parameter hints. Every sentence earns its place.

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

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

For a mutation tool without output schema, the description covers the key patterns (gacha/pity) and safety advice. However, the `typeId` parameter is not explained, and the `fields` parameter points to an external reference. Minor gaps but overall adequate for admin tool.

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

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

With 75% schema coverage, the description provides essential guidance for the `fields` parameter (e.g., isGacha, pity, contents, prices), which is not detailed in the schema. This adds significant meaning for bundle creation, though the fields description still references an external skill for full schema.

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

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

The description clearly states the tool creates a bundle, with specific use cases for gacha/loot boxes (isGacha, pity fields). It distinguishes from many sibling create_* tools by focusing on bundles and noting admin context in the title.

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

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

Explicitly says 'MUTATES live game config — confirm with the user and prefer staging,' providing clear context for when to use and caution. Does not explicitly mention when not to use or compare to alternatives, which is acceptable given the detailed mutation warning.

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

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

The description explicitly warns 'MUTATES live game config — confirm with the user and prefer staging.' This adds critical behavioral context beyond the annotations (which show destructiveHint=false), making the risk clear. No contradiction with annotations.

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

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

The description is two sentences and includes inline explanations. It is front-loaded with the core purpose ('Create a competition') and supplies necessary details without fluff.

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

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

Given the tool's complexity (6 parameters, nested fields, no output schema), the description covers purpose, usage guidelines, and mutation warning. However, it does not describe the return value or error states, which would be helpful for the agent to handle responses correctly.

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

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

Schema description coverage is 50%. The description adds meaning for competitionFormatTypeMasterId (maps IDs to types) and the `fields` parameter (explains matchId+gameId usage and entry details). However, other parameters like name, competitionId, and isSpecialEvent lack additional explanation beyond the schema, which only provides types/required status.

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

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

The description clearly states 'Create a competition' and explains the different format types (tournament, instant battle, etc.) with specific IDs. This differentiates it from sibling tools like specter_create_battlepass or specter_create_event.

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

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

The description provides explicit guidance on when to use specific parameters (matchId+gameId for match-based, entry prices/prizes/schedule in `fields`). It also warns that the tool mutates live game config and recommends user confirmation and staging. However, it does not explicitly distinguish when to use this tool over alternatives like specter_create_event.

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

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

The description explicitly states that the tool mutates live game configuration and advises caution, which goes beyond the annotations. Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false (non-destructive), but the description adds valuable context about the mutation's impact and the need for confirmation.

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

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

The description is exceptionally concise: two sentences that cover purpose, parameter details, and behavioral warnings without any redundancy. Each sentence earns its place, making it efficient for an AI agent to parse.

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

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

While the description is clear about inputs and behavior, it lacks information about the return value since there is no output schema. Mentioning what the tool returns (e.g., the created currency object) would improve completeness. Otherwise, it adequately covers the mutation context.

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

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

With 75% schema description coverage, the schema already documents most parameters. The description adds value by explaining the 'type' parameter's meaning (virtual vs. real) and noting the auto-derivation of 'currencyId'. This compensates for the missing parameter description in a few cases.

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

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

The description clearly states the tool creates a currency, specifying both virtual and real-money types. This distinguishes it from related tools like 'specter_create_currency_conversion' and 'specter_create_currency_policy', which handle different aspects of currency management.

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

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

The description provides context that the tool mutates live game config and advises confirming with the user and preferring staging. It does not explicitly exclude usage of sibling tools, but the clear purpose and behavioral warning offer sufficient guidance for appropriate use.

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

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

Annotations already indicate this is a mutation (readOnlyHint false) and not idempotent. The description adds that it 'mutates live game config'—reinforcing the mutation nature—and reveals a key behavioral detail: it resolves currency slugs/names to IDs automatically. This goes beyond what annotations state.

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

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

Only three sentences, each serving a distinct purpose: defining the action, explaining input handling, and warning about mutation. No wasted words. The most critical information is front-loaded.

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

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

Given there is no output schema, the description could mention what the tool returns (e.g., the created conversion). However, for an admin mutation tool with clear input documentation and behavioral warnings, the description is fairly complete. It covers purpose, parameter semantics, and important cautions.

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

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

The description explains that source and target parameters accept slugs/names and are resolved to IDs, adding meaning beyond the schema's 'slug/name' description. It provides a concrete example for conversionRate ('e.g. 0.01 for 100:1'). Other parameters (isEnabled, conversionFee, projectId) rely on schema descriptions, but the description covers two of the three required params with extra context.

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

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

Description clearly states 'Define an exchange rate from one currency to another' with an explicit example. The tool's name and title reinforce this. Among the many 'create' sibling tools, this one is uniquely identifiable as creating currency conversions, so it is well-differentiated.

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

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

The description includes a warning 'MUTATES live game config — confirm and prefer staging.' This provides clear context for when to use the tool (admin tasks, with caution) and implies it should not be used in production without confirmation. It does not explicitly mention alternatives or when not to use it, but the staging advice is valuable guidance.

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

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

Discloses mutation behavior ('MUTATES live game config') and advises staging, which adds value beyond annotations (readOnlyHint=false, destructiveHint=false). Notes that it changes live configuration, crucial for agent decision-making.

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

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

Two sentences, front-loaded with key action and policy types, then mutation warning. No wasted words; efficient for quick scanning.

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

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

Covers main purpose and mutation risk but lacks details on parameter dependencies per policy type (e.g., which params are required for 'currency_decay'). Given 13 parameters and no output schema, more explicit mapping would improve completeness.

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

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

Description mentions policy types and currency identification, partially mapping to parameters (min/max, decay rate, cap). However, with 46% schema coverage, many parameters (e.g., projectId, threshold, includePurchases) are not explained. The description adds some context but not enough to fully compensate for low schema coverage.

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

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

Clearly states the tool attaches a policy to a currency, listing three specific policy types (balance_limits, currency_decay, earning_caps). Distinguishes from sibling tools which create other entities. Explicitly mentions the currency identifier (slug/name).

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

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

Provides clear context: 'MUTATES live game config — confirm and prefer staging' advises caution and environment preference. However, no explicit comparison to alternative tools, though sibling tools are for different resources so implicit distinction is sufficient.

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

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

Discloses mutation ('MUTATES live game config') beyond annotations, which already indicate not read-only and not idempotent. Adds user confirmation and staging preference. No contradictions with annotations.

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

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

Two sentences plus a warning, all earning their place. Front-loaded with purpose and example.

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

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

Adequate for a tool with 6 parameters and no output schema: covers purpose, ordering, and mutation. Lacks detail on fields and parameters, but sufficient for basic usage.

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

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

With 50% schema coverage, description adds value by explaining eventId auto-derivation from name and giving an example for parameters. However, fields and projectId remain unexplained, and compensation is not full.

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

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

The description clearly states the verb ('Create'), resource ('custom event'), and purpose ('that tasks/achievements can be triggered by'), with an example. It distinguishes from sibling create_* tools by focusing on events.

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

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

Provides explicit ordering advice: 'Create the event BEFORE the task that references it' and cautions to 'confirm with the user and prefer staging' due to mutation. No explicit alternatives mentioned, but context is clear.

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

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

Adds behavioral context beyond annotations by explicitly stating mutation of live config and advising confirmation. Annotations already indicate mutability (readOnlyHint=false) and open world, but description reinforces and adds practical guidance.

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

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

Two sentences: first states purpose, second gives parameter hint and mutation warning. Front-loaded and efficient with no wasted words.

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

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

Covers purpose, parameters, and mutation warning. Missing description of return value or success behavior, but given no output schema, this is acceptable. Adequate for a simple create tool.

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

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

Provides concrete examples for the 'fields' parameter (consumable/equippable, prices, unlock conditions) which adds meaning beyond the schema's vague description. Schema has 75% coverage, but this clarification is valuable.

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

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

Clearly states 'Create an inventory item' with specific properties (consumable/equippable) and mutation warning. Distinguishes from sibling create tools by focusing on inventory items.

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

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

Explicitly warns about mutating live game config and advises user confirmation and staging preference. Lacks explicit when-not-to-use or comparison with alternatives, but the staging advice provides clear context.

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

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

Annotations already indicate readOnlyHint=false, so mutation is expected. The description adds valuable context: the warning about confirming with the user, preferring staging, and the fact that it mutates live config. No contradiction with annotations.

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

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

The description is short (three sentences) and contains useful specifics. The first sentence is slightly tautological, but overall it is concise without unnecessary content.

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

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

Given the complexity (7 parameters, nested objects, no output schema), the description covers enum mappings and usage warnings but lacks information about the return value or behavior of leaderboardOutcomeDetails beyond a single note. It is adequate but incomplete.

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

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

Schema coverage is 71%, with most parameters described. The description adds meaning by noting that prizeDistributionRule/prize config goes in `fields`, which is not in the schema. This helps understanding beyond the schema alone.

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

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

The description clearly states the tool creates a leaderboard and provides specific enum mappings for outcomeType and sourceType. However, it does not explicitly differentiate from sibling create tools like specter_create_battlepass or specter_create_competition, relying on the resource name.

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

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

The description warns that the tool mutates live game config and advises confirming with the user and preferring staging. This gives some usage context but does not explicitly state when to use this tool versus alternatives or 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.

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description explicitly states 'MUTATES live game config' and advises caution and staging use. This significantly enhances the agent's understanding of the tool's impact, which the annotations alone do not convey.

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

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

The description is three short sentences that front-load the core purpose and critical warnings. Every sentence serves a purpose with no wasted words.

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

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

The description provides enough context for a creation tool: purpose, key parameter hints, and mutation warning. No output schema exists, but the description does not explain returns; however, that is acceptable given the tool type.

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

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

Schema description coverage is 83%, so the schema already explains most parameters. The description clarifies levelSystemTypeId and levelDetails, but this adds only marginal value beyond the existing schema descriptions.

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

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

The description clearly states the tool creates a level system and identifies two types (XP-based, event-based). It does not explicitly differentiate from sibling tools like create_battlepass or create_currency, but the specific resource (level system) and mention of levelDetails set it apart adequately.

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

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

The description advises to 'confirm with the user and prefer staging,' providing explicit caution about when to use this tool. It does not mention alternatives or conditions for not using it, but the warning adds valuable guidance.

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

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

Annotations indicate non-readonly and non-destructive; the description adds specific behavioral context by stating 'MUTATES live game config', which goes beyond the annotations. It could also mention side effects or permissions.

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

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

Three sentences with clear front-loading: first sentence states purpose, second explains key parameters, third gives behavioral warning. Every sentence earns its place without redundancy.

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

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

Covers purpose, key parameters, and mutation warning, but lacks information about return value, required permissions, or how to handle idempotency (annotation says not idempotent). Missing parameter explanations for name and projectId.

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

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

Schema coverage is only 43%, but the description explains the meaning of format (single/multi/team), outcome (how winner is decided), game (resolved by name/slug), and fields (matchmaking rules). This adds substantial value for four parameters, though name and projectId are not covered.

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

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

Clearly states the verb 'Create' and resource 'match template', explaining it's the config for real-time sessions. Distinguishes from sibling create_* tools by specifying multiplayer match template and key fields like format and outcome.

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

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

Explicitly warns that the tool mutates live game config and advises to 'confirm and prefer staging', providing clear usage context. Lacks explicit comparison to alternatives but the warning serves as a guideline.

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

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

The description adds that the tool mutates live game config and advises confirming and preferring staging, which goes beyond annotations (readOnlyHint=false, openWorldHint=true). It does not detail side effects, but the warning suffices.

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

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

The description is extremely concise: three short sentences front-loaded with the definition, usage guidance, and a safety warning. No wasted words.

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

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

Given the tool's complexity (11 parameters, nested objects), the description provides a clear mental model and usage context. It could mention more about return values or configuration, but the essentials are covered.

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

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

Schema coverage is 55%, so baseline is around 3. The description does not add extra details for individual parameters beyond what the schema provides; it gives a high-level overview but no compensation for lacking param descriptions.

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

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

The description clearly defines the tool as creating a mission (task pool) with typeId 1, gives concrete use cases (daily missions, rotating challenges), and explicitly distinguishes from sibling tools (specter_create_step_series for sequential, specter_create_time_series for streaks).

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

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

The description explicitly states when to use this tool ('daily missions', 'rotating challenges', 'pick N of these') and when not to use it ('sequential use specter_create_step_series; for streaks use specter_create_time_series').

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

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

The description adds behavioral context beyond annotations by highlighting mutation of live game config. Annotations indicate readOnlyHint=false and destructiveHint=false, so the warning about mutation is valuable. It does not detail auth needs or specific side effects, but the warning is sufficient.

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

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

The description is two sentences, both front-loaded with the purpose and a key warning. No extraneous information; every sentence earns its place.

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

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

The description covers the core purpose and a crucial behavioral warning. However, it does not explain return values or handle the 'fields' parameter vagueness. Given the tool's complexity (3 params, no output schema), more completeness could be beneficial, but it is minimally adequate.

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

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

Schema description coverage is 67%, so the baseline is 3. The tool description does not add any additional parameter meaning beyond what the schema provides. The fields parameter points to an external schema, but no further clarification is given.

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

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

The description clearly states the tool creates a progression marker, exemplified as a named counter like XP or trophies. This specific verb-resource combination distinguishes it from sibling create tools such as specter_create_currency or specter_create_mission.

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

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

The description warns that the tool mutates live game config and advises confirming with the user and preferring staging. However, it does not explicitly state when to use this tool over alternatives or provide when-not conditions.

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

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

Annotations indicate readOnlyHint=false (mutation) and the description reinforces this with 'MUTATES live game config'. It adds the advice to prefer staging, which is useful behavioral context beyond the annotations. No contradictions.

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

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

The description consists of two concise sentences. The first sentence defines the tool's purpose, and the second provides usage context and a mutation warning. Every sentence adds value without redundancy.

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

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

Given the complexity (nested objects, 9 parameters, no output schema), the description covers the core purpose and mutation warning adequately. However, it lacks details on return values or error conditions, which an agent might need. Still, it is sufficient for a create tool with a detailed input schema.

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

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

Schema description coverage is low (33%). The description adds meaning for the 'tasks' parameter by explaining that array order or sortingOrder defines the sequence. However, it does not elaborate on other parameters like name, projectId, levelLocks, or groupRewards, leaving gaps for the 9 parameters. The additional clarity on tasks raises the score above baseline but not enough to compensate fully.

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

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

The description clearly states the tool creates a 'STEP SERIES' (typeId 2) with ordered tasks that unlock sequentially, given concrete examples like 'quest lines' and 'tutorial chains'. This distinguishes it from sibling tools like specter_create_time_series (which likely handles parallel tasks).

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

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

The description explicitly states when to use the tool ('quest lines', 'tutorial chains', 'finish step 1 before step 2') and includes a warning about mutation ('MUTATES live game config — confirm and prefer staging'). It lacks explicit exclusions for alternatives but provides clear context.

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

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

Annotations indicate mutation (readOnlyHint=false) and description reinforces 'MUTATES live game config', adding caution about user confirmation and staging preference. This provides useful behavioral context beyond annotations.

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

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

Two concise sentences with no wasted words. First sentence states function, second provides critical warning. Efficient and front-loaded.

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

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

Given the tool's mutation nature and zero output schema, the description covers purpose, usage caution, and a key parameter hint. It references an external skill for full schema, which is acceptable but slightly vague. Complete enough for a creation tool.

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

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

Schema coverage is 75%, and the description adds meaning for the `fields` parameter by specifying its content (storeCategories[]). Other parameters are documented in schema. This adds value for a key parameter.

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

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

Clearly states 'Create a store' identifying the verb and resource. The description adds context about categories/contents/platforms going into `fields`, making it distinct from other specter_create_* tools for different entities.

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

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

Gives explicit guidance: 'confirm with the user and prefer staging' due to mutation of live config. This helps the agent decide when to use the tool responsibly. Lacks explicit exclusions or comparison to alternatives, but context is clear.

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

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

The description explicitly states that the tool mutates live game config ('MUTATES live game config'), which aligns with readOnlyHint=false. It adds useful context such as 'confirm with the user and prefer staging' and explains that recurring is just intent. While annotations already indicate non-read-only, the description adds behavioral nuance. No contradiction with annotations.

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

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

The description is concise, consisting of three sentences that front-load the main purpose and sibling differentiation. Each sentence adds value without unnecessary verbosity.

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

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

Given the complexity (13 parameters, nested objects) and no output schema, the description covers the core aspects needed for tool selection and basic usage. It references the schema for details. While some parameters like completion or businessLogic are not mentioned, the schema provides sufficient documentation. Overall, it is complete enough for an agent to understand when and how to use the tool.

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

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

Schema coverage is high (85%), so baseline is 3. The description adds meaning to key parameters: event is resolved automatically, rewards use slug/name, recurring captures cadence intent. This goes beyond the schema descriptions. However, not all parameters are explained in the description, but the schema covers them adequately.

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

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

The description clearly states that the tool creates a single-objective achievement with one trigger and one reward, and explicitly distinguishes it from sibling tools for multi-objective achievements (specter_create_mission, specter_create_step_series, specter_create_time_series). The verb 'create' and resource 'achievement' are specific and unambiguous.

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

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

The description provides explicit guidance on when to use this tool (single-objective achievements) and when to use alternative tools. It explains key parameters like event, rewards, and recurring, and warns that recurring captures cadence intent only, not actual scheduling. It also advises confirming with the user and preferring staging for mutation.

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

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

Annotations indicate readOnlyHint=false and idempotentHint=false, which align with the description's explicit statement that the tool 'MUTATES live game config'. The description adds the caution to 'confirm and prefer staging', which is valuable context beyond annotations. It does not contradict any annotations.

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

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

The description is concise with only three sentences, front-loading the core purpose and key parameters. It uses clear examples and a warning without fluff. Every sentence serves a purpose, making it highly efficient.

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

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

Given the tool's complexity (13 parameters, nested objects, no output schema), the description covers the high-level concept but lacks details on return values, error handling, or full parameter semantics. The example provides some context, but completeness is insufficient for complex cases.

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

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

Schema description coverage is 54%, so some parameters are already documented. The description adds meaning for two critical parameters ('stageLength' and 'interval') by explaining their roles with examples. However, many other parameters (e.g., tasks, rewards) are not explained in the description, relying heavily on the schema. This is a moderate compensation.

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

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

The description clearly states the tool's purpose: creating a TIME SERIES for per-window recurring tasks like streaks. It distinguishes from siblings by specifying the use case (e.g., daily login streak) and referencing typeId 3. The verb 'create' and resource 'time series' are specific and unambiguous.

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

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

The description provides explicit usage scenarios ('streaks', 'login N days in a row', 'weekly recurring that resets on miss') and includes a critical warning about mutating live game config and preferring staging. However, it does not explicitly mention alternatives or when not to use this tool, missing some guidance.

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

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

Annotations already indicate destructiveHint=true. The description adds that the delete is 'soft-delete' and advises 'prefer staging', which provides behavioral context beyond the annotations. No contradictions.

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

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

The description is two sentences: the first states the action and scope, the second provides critical usage warnings. No unnecessary words; every sentence is functional.

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

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

With destructiveHint and openWorldHint annotations present, the description covers the core functionality and safety precautions. It lacks details on the 'soft-delete' behavior (e.g., reversibility) and the meaning of projectId, but for a delete tool with annotations, it is fairly complete.

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

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

Schema coverage is 67% (2 of 3 parameters described). The description adds meaning by connecting kind values ('task' vs group kinds) and refs ('slugs/names/ids'). The projectId parameter is undocumented in both schema and description, but overall the description adds value beyond the schema.

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

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

The description clearly states the tool soft-deletes a single task or a group, specifying the kinds (task, mission, step_series, time_series) and what refs to provide (slugs/names/ids). It distinguishes from siblings like create, edit, and list tools by using the verb 'delete' and the resource 'achievement'.

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

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

The description provides explicit guidance: 'DESTRUCTIVE — confirm with the user first, and prefer staging.' This tells the agent when to use it (only with confirmation, possibly in staging) but does not explicitly mention alternatives or when not to use it. However, for a delete tool, this is clear and actionable.

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

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

Adds 'MUTATES live game config' beyond annotations (readOnlyHint=false, destructiveHint=false). Confirms mutating nature and provides risk warning, adding value over structured fields.

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

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

Two concise sentences that front-load the action and identifier, then add a critical behavioral note. No wasted words.

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

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

For a mutation tool with 7 parameters and no output schema, the description is adequate but lacks details on required vs optional parameters and what is returned. The staging warning is valuable, but more parameter context would improve completeness.

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

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

Schema coverage is low (29%). Description mentions 'slug/name' for the currency parameter but does not detail other parameters like code, name, type, fields, projectId. Provides general field list but insufficient compensation for low coverage.

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

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

The description clearly states 'Update an existing currency' and lists specific fields (name, description, code, type). It distinguishes from sibling tools like specter_create_currency and specter_list_currencies.

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

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

Explicitly warns 'MUTATES live game config — confirm and prefer staging', advising caution when to use. Does not name alternative tools but provides clear context for safe usage.

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

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

Annotations already indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false), but description adds crucial context: 'MUTATES live game config — confirm and prefer staging', and mentions diff-semantics on rewards. This adds value beyond structured fields.

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

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

Two concise sentences with front-loaded purpose and critical warnings. No unnecessary words, earns its space.

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

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

Given the tool's complexity (8 params, nested objects, no output schema), the description covers the main use case, addresses the tricky reward scenario, and warns about production effects. Lacks details on return values and some parameter semantics, but sufficient for an admin editing tool with many siblings.

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

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

Schema description coverage is only 13%, so description must compensate. It lists editable fields (name, description, rewardClaim, recurrence, businessLogic) and explains identification by slug/name for the required 'task' parameter. However, it does not explain other parameters like projectId, fields, or recurring object structure, leaving gaps.

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

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

Description clearly states the verb 'Update' and specifies fields: name, description, rewardClaim, recurrence, businessLogic. Also identifies the resource as an existing single task by slug/name. Distinguishes from create siblings and addresses a specific limitation with rewards.

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

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

Explicitly tells when to delete and recreate instead of edit for rewards: 'To CHANGE REWARDS, delete and recreate the task'. Also advises confirming live changes and preferring staging, providing clear guidance on usage context.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true; the description adds that it uses real keys and slugs, which is consistent and provides useful context about side effects (no mutations). No contradictions.

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

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

Two concise sentences that include key purpose, features, and language guidance without waste. Front-loaded with main action.

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

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

With only 2 parameters and no output schema, the description covers the main aspects of what the generated code does. It could mention the output format (code text) but the phrase 'ready-to-paste' implies that. Lacks details on error handling or prerequisites but still complete for the tool's simplicity.

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

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

Schema coverage is 50% (only language has a description). The tool description adds context about language usage (JS vs C#) and hints at projectId's role, but does not fully compensate for the missing schema description of projectId. Adequate but not excellent.

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

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

The description clearly states it generates ready-to-paste game integration code, lists covered features (login, events, tasks, wallet), and distinguishes from sibling tools which are all API calls, making the purpose specific and clear.

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

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

It provides context that the code is wired with a real api-key and event slug, implies project context, and gives guidance on language selection (JS works anywhere, C# for Unity with a recommendation for production SDK). Could be more explicit about when not to use, but sufficient.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds that the tool 'signs in the sandbox test player,' which is additional behavioral context beyond the annotations. No contradiction.

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

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

Two sentences, front-loaded with purpose, no wasted words. Each sentence contributes essential information.

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

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

Given the tool has few parameters and rich annotations, the description covers purpose, usage, and scope. It implies a sandbox environment, which is appropriate.

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

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

Schema coverage is 100% with one optional 'include' parameter that has a clear enums. The description adds 'default all' but does not provide additional meaning beyond the schema.

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

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

The description clearly states the tool reads test player state including tasks, wallet, and inventory. It uses specific verbs 'read' and 'inspect' and distinguishes itself from sibling tools that create or list individual resources.

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

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

The description provides explicit use cases: 'inspect what a player currently sees, or to check an achievement's progress.' It does not mention when not to use or alternatives, but the context is clear.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, lowering the bar. Description adds value by detailing that entries have sourceType, sourceId, amount, and status (pending→completed), and that pending rewards are included. No contradictions.

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

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

Two sentences, concise and front-loaded. First sentence states purpose and key feature (pending rewards). Second sentence adds filter example and field details. No unnecessary words.

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

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

Explains entry fields (sourceType, sourceId, amount, status) sufficiently for a read-only query without output schema. However, does not mention pagination or behavior of limit parameter, leaving minor gap.

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

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

Schema description coverage is 67% (status and rewardGrant have descriptions). Description adds context about status filtering and entry fields but does not explain limit or rewardGrant beyond schema. Adequate but not compensatory for missing limit description.

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

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

Clearly states 'Read the test player's reward history', identifying verb and resource. Distinguishes from siblings like specter_claim_reward and specter_grant_reward by focusing on reading history versus claiming or granting.

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

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

Provides some guidance: 'Filter by status ('pending' shows claimable)' implies when to use for pending rewards. But lacks explicit comparison to alternatives like specter_claim_reward or specter_grant_reward, and doesn't state when not to use.

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

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

The description adds behavioral context beyond annotations by explicitly stating 'MUTATES live game config' and 'confirm with the user and prefer staging.' This is valuable despite annotations already indicating non-readOnly and non-destructive. No contradictions.

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

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

The description is extremely concise: two sentences that cover purpose, parameter structure, and a critical behavioral warning. No wasted words.

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

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

For a mutation tool with 3 parameters and no output schema, the description covers purpose, parameter details, and behavioral warning. It could mention return value or error handling, but the core is well-covered.

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

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

Schema coverage is 100%, but the description adds meaningful structure for rewardDetails (describing the array entries with items/bundles/currencies/progressionMarkers), which is not present in the schema. The userId parameter is briefly described. The fields parameter is noted as 'any other fields' with a cross-reference.

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

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

The description clearly states the action ('Grant'), the resource ('items/bundles/currencies/markers'), and the target ('to a player'). The title adds '(admin)', distinguishing it from player-side actions like specter_claim_reward.

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

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

The description explicitly warns that the tool mutates live game config and advises to confirm with the user and prefer staging. This provides strong usage guidance, though it does not list alternative tools or 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.

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds value by explaining that the tool returns ids/slugs and requires prior login, which is useful behavioral context not present in annotations."

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

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

The description is two sentences long with the main action in the first sentence. Every word serves a purpose: stating the action, specifying return value, and noting a prerequisite. No redundancy or unnecessary detail."

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

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

The description explains the return value (ids/slugs) and prerequisite, which is helpful given no output schema. However, it omits details on pagination (limit) and filtering (search), leaving gaps for a list operation with those parameters."

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

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

Schema description coverage is only 33% (only projectId has a description). The description adds no parameter information, such as meaning of limit or search. With low coverage, the description should compensate but fails to do so."

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

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

The description clearly states the tool lists battle passes from a Specter project and specifies that it returns ids/slugs for use in creating other entities. This is a specific verb+resource combination that distinguishes it from sibling tools like specter_list_bundles or specter_list_currencies."

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

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

The description notes a prerequisite (requires a one-time browser sign-in via specter_login) and implies usage when needing ids/slugs for entity creation. While it does not explicitly state when not to use or list alternatives, the provided context is clear enough for an agent."

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

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

Annotations declare readOnlyHint and openWorldHint, and the description adds the behavioral trait of requiring a browser sign-in. This is valuable beyond annotations.

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

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

Two sentences that efficiently convey purpose, return value, and prerequisite with no unnecessary words.

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

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

Covers purpose and prerequisite but lacks details on parameter usage, pagination, or response structure. Without output schema, this leaves gaps for an agent.

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

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

Schema description coverage is low (33%) yet the description provides no information about the 'limit' or 'search' parameters. It fails to compensate for the schema gaps.

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

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

Clearly states it lists bundles/loot boxes and returns ids/slugs for reference, effectively distinguishing it from other list tools by specifying the resource.

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

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

Mentions prerequisite of one-time sign-in but does not explicitly provide when-to-use guidance or compare to sibling list tools. The context implies usage for bundle listing but lacks exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds some value by noting return content (ids/slugs) and login requirement. However, it doesn't specify pagination, sorting behavior, or handling of no results, which would be useful.

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

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

The description is two sentences long, front-loaded with the main action, and every sentence adds value without unnecessary words.

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

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

For a listing tool with no output schema, the description covers the primary purpose, return value, and a prerequisite. It could improve by addressing parameter usage, but overall it provides sufficient context.

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

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

The schema has 3 parameters with only 33% description coverage (only projectId has a description). The tool description does not elaborate on 'limit' or 'search' parameters, missing an opportunity to compensate for the low schema coverage.

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

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

The description clearly states the verb 'list', the resource 'currencies', and the purpose: to return ids/slugs for referencing when creating other entities. It effectively distinguishes from sibling tools like specter_create_currency and specter_edit_currency.

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

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

The description mentions the prerequisite of a one-time browser sign-in (specter_login), providing clear context for when to use this tool. It does not explicitly state when not to use it or list alternatives, but the listing context is sufficient.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, indicating safe read behavior. The description adds value by specifying the return of ids/slugs for referencing in other entities and the authentication requirement. No contradictions with annotations.

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

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

The description is two sentences long, front-loaded with the primary purpose, and each sentence adds distinct value (purpose, return value, prerequisite). No wasted words.

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

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

The description mentions return of ids/slugs but lacks details on output structure, pagination, or how limit/search parameters affect results. For a list tool with no output schema, more behavioral context would improve completeness.

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

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

Schema description coverage is low (33%), with only projectId having a description ('Defaults to the auto-detected project'). The tool description does not explain the limit or search parameters, relying on the schema which lacks detail. This forces the agent to infer meaning from parameter names alone.

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

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

The description clearly states the tool lists custom events in a Specter project. It uses specific verbs and resource ('List custom events') and distinguishes itself from sibling tools like specter_create_event and specter_send_event by focusing on querying existing events.

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

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

The description explicitly mentions the prerequisite of a one-time browser sign-in (specter_login), which guides the agent on setup. However, it does not explicitly state when not to use this tool or provide direct comparisons to alternatives like specter_create_event.

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

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

Annotations already indicate read-only and open-world hints. Description adds value by stating authentication requirement (specter_login) and return type (ids/slugs), beyond annotations.

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

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

Two sentences, front-loaded with main action, no unnecessary words. Efficiently conveys core purpose and key context.

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

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

Covers purpose, return value, and prerequisite. However, lacks explanation of pagination (limit) and search behavior, which are relevant for a list tool. Adequate but not fully complete.

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

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

Schema coverage is low (33% with only projectId described). Description provides no parameter details, failing to compensate for undocumented limit and search parameters.

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

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

The description clearly states the tool lists items in a Specter project and returns ids/slugs for referencing. It distinguishes from other list_* siblings by the resource type, but lacks explicit differentiation.

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

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

Implies use before creating other entities via returned ids/slugs. Mentions prerequisite (specter_login), but does not specify when not to use or compare to alternatives.

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

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

Adds the login requirement beyond what annotations provide (readOnlyHint, openWorldHint). Description is consistent with annotations; no contradiction. Could mention result size limits or pagination, but the added value is solid.

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

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

Two short sentences, each adding meaningful information. No filler, concise and well-structured.

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

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

Describes purpose, return value, and a prerequisite. Missing details on parameter roles (limit, search) and return structure beyond ids/slugs. Adequate but not thorough.

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

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

Schema description coverage is only 33% (only projectId described). The description does not explain limit or search parameters, nor their effect. Relies too heavily on the schema without adding clarity.

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

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

Clearly states verb 'List' and resource 'leaderboards', and explains that it returns ids/slugs for referencing in other entities. Effectively distinguishes from sibling tools like specter_create_leaderboard.

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

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

Mentions a prerequisite (requires specter_login), providing context for when the tool can be used. Does not explicitly state when not to use or suggest alternatives, but the context is clear enough.

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

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

Discloses that the tool returns 'ids/slugs you can reference', which aids in understanding the return value. Also mentions the login requirement, adding behavioral context beyond the readOnlyHint and openWorldHint annotations. No contradiction with annotations.

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

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

Two concise sentences: one stating purpose, the second adding return value and prerequisite. No redundant information, efficient and front-loaded.

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

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

Provides the core purpose, return intent, and prerequisite. However, it does not describe optional parameters (limit, search) or output structure in detail. Given the presence of annotations and no output schema, the description is mostly complete but could be slightly richer.

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

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

With only 33% schema description coverage, the description should compensate but does not mention any parameters. It provides no additional meaning for 'limit', 'search', or 'projectId' beyond what the schema minimally offers.

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

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

Clearly states the verb 'list', the resource 'progression markers', and the context 'in this Specter project'. It distinguishes from siblings like specter_create_progression_marker by focusing on listing and providing reference IDs/slugs.

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

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

Specifies a prerequisite ('Requires a one-time browser sign-in (specter_login)'), which guides when to use the tool. It implies use before creating entities that reference markers, but does not explicitly state when not to use or provide alternatives.

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

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

Annotations already declare readOnlyHint and openWorldHint; the description adds that it requires a browser sign-in (specter_login) and specifies return values (ids/slugs), which is useful behavioral context beyond annotations.

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

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

The description is two sentences with no wasted words: first sentence states purpose, second adds usage context and prerequisite. Front-loaded and efficient.

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

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

For a simple list tool with annotations covering safety, the description covers purpose, return value hints, and a prerequisite. Could be improved by detailing the output structure more, but overall adequate.

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

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

Schema coverage is only 33% (only projectId has a description). The description adds no information about the parameters (limit, search, projectId), failing to compensate for the low coverage.

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

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

The description clearly states it lists progression systems and returns IDs/slugs for referencing in other entities. It distinguishes from sibling list tools by specifying the resource type.

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

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

The description mentions a prerequisite (one-time browser sign-in via specter_login) and implies usage before creating entities that need progression system IDs, but does not provide explicit when-to-use or alternatives.

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

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

Annotations already declare readOnlyHint=true (safe read) and openWorldHint=true. The description adds the important prerequisite of a one-time browser sign-in and clarifies the return format (ids/slugs). No contradictions and valuable behavioral context beyond annotations.

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

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

Two concise sentences, front-loaded with purpose, then additional useful context (return values and prerequisite). No wasted words.

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

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

Given moderate complexity and no output schema, the description covers the core purpose, return value, and a prerequisite. However, it omits parameter details like limit and search, which could affect usability. Adequate but leaves gaps.

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

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

The description does not explain any of the three parameters (limit, search, projectId). Schema description coverage is only 33%, with only projectId having a description. The description adds no value for parameters, failing to compensate for the gaps.

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

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

The description clearly states the tool lists stores in a Specter project, distinguishing it from other list tools (e.g., specter_list_battlepasses) by specifying the resource. It also notes the return of ids/slugs for reference, which adds useful context.

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

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

The description implies usage before creating entities that need store references, and explicitly mentions the prerequisite of a one-time browser sign-in via specter_login. It does not exclude alternative tools, but as the only list stores tool, clear context is provided.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description adds the login requirement and the return of ids/slugs. Yet it omits details on pagination (limit parameter) or error behavior (e.g., if not logged in). This is adequate but not rich.

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

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

The description is two sentences with no fluff. The first sentence states the action and result, the second adds a key prerequisite. Every word earns its place.

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

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

Given the tool has 3 parameters, no output schema, and annotations that are only partially descriptive, the description provides enough to understand the basic goal but lacks details on sorting, pagination, error handling, or the shape of the returned ids/slugs. It is minimally complete for a simple list operation.

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

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

Schema coverage of parameters is only 33% (projectId has a description). The description does not explain the 'limit' or 'search' parameters, nor their formats or defaults. Despite the low coverage, the description adds no value for these parameters, so the score is below the baseline of 3.

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

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

The description explicitly states 'List the tasks / achievements' and explains the return value (ids/slugs). This clearly differentiates it from sibling tools like specter_create_task or specter_edit_task.

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

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

The description mentions a prerequisite ('Requires a one-time browser sign-in (specter_login)'), which helps the agent know when the tool can be used. However, it does not explicitly contrast with siblings or state when not to use it, though the context among many create/edit tools implies its use for reference.

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

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

Annotations already declare readOnlyHint=true (safe read) and openWorldHint=true (may not exist). The description adds the critical behavioral detail that a one-time browser sign-in (specter_login) is required, which is beyond what annotations provide.

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

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

Two concise sentences that front-load the core purpose and add valuable return info and a prerequisite. No wasted words.

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

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

The description covers the main purpose and a key requirement, but lacks detail on parameter behavior (e.g., pagination with limit, search behavior) and expected output format beyond ids/slugs. Given no output schema, more completeness would improve the tool's usability.

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

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

With schema description coverage at only 33%, the description should compensate for missing parameter documentation, but it does not explain the 'limit' and 'search' parameters at all. Only 'projectId' has a description in the schema, but the description adds no parameter semantics.

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

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

Clearly states 'List the tournaments / competitions configured in this Specter project', providing a specific verb and resource. It distinguishes from siblings by being the only list tool for tournaments, and also mentions returning ids/slugs for referencing.

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

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

Mentions that the tool returns ids/slugs useful for creating other entities, implying a typical use case before creating related entities. However, it does not explicitly state when not to use or compare to alternatives.

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

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

Describes key behaviors: opens browser, no password shared, required once. Annotations are minimal, so description carries burden. No contradiction; adds value beyond annotations.

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

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

Two sentences, front-loaded with purpose, every sentence adds value. No waste.

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

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

Adequately explains purpose and when needed. Given zero parameters and no output schema, provides sufficient context for agent to know when to invoke. Could detail post-auth state, but still solid.

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

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

No parameters, schema coverage 100%. Description adds no param info, but baseline is 4 for zero-parameter tools.

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

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

Clearly states the tool opens a dashboard for sign-in and authorization. Distinguishes itself from sibling tools by specifying it's a prerequisite for creating currencies/tasks.

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

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

Explicitly says 'Required once before creating currencies/tasks,' providing clear when-to-use context. Could hint at when already authenticated, but still strong.

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

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

Description adds critical behavioral context beyond annotations: it explicitly states 'MUTATES live game config — confirm and prefer staging', indicating the tool modifies live state and advising caution. This complements annotations (readOnlyHint=false, destructiveHint=false) without contradiction.

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

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

Description is concise (3-4 sentences) with key information front-loaded. Every sentence adds value: action, parameter constraint, behavior nuance, and warning. No wasted words.

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

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

Given tool complexity (7 params, nested objects, no output schema), description covers purpose, key constraints, and behavioral implications. It is adequate but lacks explicit mention of projectId's role or timezone impact. Overall sufficient for an agent to invoke correctly.

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

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

Description adds meaning beyond the schema by clarifying mutual exclusivity of taskRef and groupRef, and the effect of omitting startDate. Schema coverage is high (71%+), so the description provides useful constraints not fully covered by schema alone. However, it doesn't explain projectId or timezone beyond defaults.

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

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

Description uses specific verb 'Activate' and clearly identifies the resource as a created task or task-group. It distinguishes from sibling tools by focusing on scheduling achievements and mentions mutation. The purpose is unambiguous.

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

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

Description provides clear context: pass exactly one of taskRef or groupRef, and omitting startDate makes it go live immediately. It warns about mutating live config and suggests confirming and preferring staging. However, it does not explicitly exclude alternatives or mention when not to use this tool over siblings like specter_schedule_liveops.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false. The description adds 'MUTATES live game config — confirm with the user and prefer staging', providing behavioral context beyond annotations. It does not contradict annotations.

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

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

Two sentences, each with essential information: first states purpose and constraint, second adds behavior warning and recurrence hint. No wasted words, front-loaded.

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

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

Given the tool's six parameters, open world hint, and no output schema, the description covers the key aspects: purpose, parameter constraint, mutation warning, and recurrence hint. It references an external skill for full fields schema, which is acceptable. Could mention projectId default behavior, but overall complete.

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

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

Schema coverage is 67%, and the description adds meaning by specifying mutual exclusivity of competitionId/leaderboardId and hinting that recurrence config goes in fields. It provides value beyond the schema's own descriptions.

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

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

The description states a specific verb 'Schedule' and resource 'leaderboard / competition', and clearly distinguishes from siblings like 'specter_create_competition' and 'specter_create_leaderboard' which are for creating, not scheduling. The constraint 'Provide exactly one of competitionId / leaderboardId' adds precision.

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

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

The description gives clear context: 'Provide exactly one of competitionId / leaderboardId' and 'Recurrence config goes in fields'. It warns about mutation and suggests confirmation. However, it does not explicitly state when to use this tool versus alternatives like 'specter_schedule_achievement' or 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.

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true. The description adds behavioral context: it fires the same event as the game would, as the sandbox test player, and is used for verification. No contradictions with annotations.

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

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

The description consists of two concise sentences. The first sentence states the core action and purpose, and the second adds parameter context. No fluff, every word earns its place.

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

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

For a test tool, the description adequately covers purpose and parameters. However, it lacks information about return values or confirmation of success. Given there is no output schema, the description could provide more detail on what happens after sending (e.g., triggers tasks/achievements and returns status). It is minimally viable but has gaps.

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

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

The input schema provides descriptions for both parameters ('event' and 'params') with examples. The description adds meaning by explaining that 'params are the event parameters (statistics/states) your rule references,' which clarifies their role in triggering rules. Schema coverage is 100%, but the description enhances understanding.

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

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

The description clearly states the verb ('Send'), resource ('custom event'), and purpose ('trigger tasks/achievements and verify they respond'). It distinguishes from sibling tools like specter_test_achievement and specter_create_event by specifying it's for firing events as the test player.

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

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

The description explicitly says 'Use to trigger tasks/achievements and verify they respond,' which gives clear context for when to use. However, it does not mention when not to use it or provide direct alternatives, but the context is clear enough.

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

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

Discloses mutation ('MUTATES live game config'), non-destructiveness ('keeps the record; reversible by scheduling again'), aligning with annotations (readOnlyHint=false, destructiveHint=false). Adds value by explaining reversibility.

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

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

Two efficient sentences with no redundancy. First sentence states core action and exclusive parameter choice; second adds caution and advice. Every word earns its place.

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

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

Given no output schema and 0 required params, description covers purpose, usage, and behavioral traits. Could elaborate on effects on players or state after stopping, but current level is sufficient for a straightforward tool.

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

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

With 0% schema coverage, description partially compensates by mentioning taskRef/groupRef and the exclusive choice. However, does not explain what these references are or describe projectId. Meaning added but incomplete.

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

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

Clearly states 'Halt a live task or task-group (keeps the record; reversible by scheduling again)'. Uses specific verb 'halt' and identifies the resource (task/group). Distinguishes from siblings like specter_schedule_achievement and specter_delete_achievement.

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

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

Provides explicit instruction to pass exactly one of taskRef/groupRef. Advises caution with 'MUTATES live game config — confirm and prefer staging'. Lacks explicit when-not-to-use or comparison to alternatives, but sufficient given context.

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

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

Annotations are present (readOnlyHint=false, etc.) and description adds the polling and reporting behavior. However, it doesn't clarify if the test fires persist or are simulated, which is a minor gap for a testing tool.

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

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

The description is two sentences, front-loaded with action steps, and includes a usage tip. Every word earns its place.

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

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

While the process is explained, the description does not identify the test player or expected output format. Without an output schema, more detail on the report would improve completeness.

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

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

Schema description coverage is 100%, so baseline is 3. The description repeats the event parameter's purpose but adds no new detail beyond the schema's descriptions. The overall context adds minor value.

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

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

The description clearly states the tool's purpose: testing an achievement by reading status, firing an event, polling, and reporting progression. It distinguishes from sibling tools like create/delete by being a verification tool.

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

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

Description explicitly says 'Use right after creating a task to verify it actually fires,' providing clear timing context. It doesn't mention alternatives or when not to use, but the single-use context is strong.

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

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

Beyond annotations (readOnlyHint=false), the description emphasizes that the tool mutates live game config and advises confirmation and staging preference. This adds valuable behavioral context without contradicting annotations.

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

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

Two concise sentences front-load purpose and list entity types, followed by usage instructions and a warning. Every sentence adds value with no redundancy.

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

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

Covers key aspects: entity types, how to use id and fields, mutation warning. Could mention admin-only nature implied by title, but still fairly complete for a generic update tool without an output schema.

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

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

The schema already describes id, entity, and fields adequately; the description adds context about id sourcing and fields purpose. However, it does not add significant meaning beyond the schema for projectId or enum values, and schema coverage is moderate.

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

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

The description clearly states it is a generic editor for updating multiple entity types, listing them explicitly. It distinguishes itself from sibling create tools by being an update tool and from specific edit tools by being generic.

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

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

Provides clear guidance on passing the entity's id from list_* tools and the fields to change, and warns about mutating live config and preferring staging. Does not explicitly exclude other tools or mention when not to use, but context from siblings implies alternatives.

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

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds value by detailing the scope of the smoke-test (api-key, project info, currencies, etc.), providing behavioral context beyond the annotations.

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

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

Two sentences, no wasted words. The key action 'smoke-test' appears first, and the purpose is immediately clear.

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

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

For a tool with no parameters, no output schema, and clear annotations, the description fully explains what it does and when to use it, covering all necessary context.

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

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

No parameters exist, so the description doesn't need to explain them. Baseline 4 applies given 100% schema coverage and no param description needed.

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

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

Description clearly states the tool performs a smoke-test of the Specter project, listing specific components checked. The verb 'smoke-test' is precise and distinguishes it from sibling tools that perform individual operations.

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

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

Explicitly recommends using this tool first to verify backend setup, implying it's a preliminary check. However, it doesn't mention when not to use it or provide alternative tools for specific verification needs.

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