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

With no annotations, the description fully carries the burden. It discloses that it creates a game and board, returns specific snippet fields, and explains how optional parameters alter behavior (e.g., anti-cheat, identity strategy). 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 a single paragraph but front-loads the primary purpose. While dense, every sentence adds value. Could be more structured, but appropriate for the complexity.

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

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

Despite having 10 parameters and no output schema, the description thoroughly explains the response structure (snippets.sdk, snippets.widget, recommendation) and how each optional parameter affects the output. Complete for a complex 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 has 100% description coverage, so baseline is 3. The description adds high-level context, like which combination of options yields the 'simplest anonymous + client-only setup', enhancing understanding beyond 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 it creates a new game and its first board in one call, returns integration code, and distinguishes itself from sibling tools by specifying 'when starting from scratch' and not to call if games already exist.

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 to use when starting from scratch and not to call if developer already has games, with an alternative action ('call list_games first'). Provides clear context for decision-making.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the board is added to an existing game and that the created board is returned with its id, but it omits auth requirements, error conditions, duplicate-slug behavior, and side effects.

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

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

Four tightly written sentences, with the core action and scope front-loaded. Every sentence adds routing or usage value, and there is no redundant filler.

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

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

The schema fully documents parameters and the description states that the created board and its id are returned. For a creation tool with no annotations, it is nearly complete, but it stops short of describing permissions or failure modes.

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

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

Schema description coverage is 100%, so all nine parameters are already documented in the schema. The description adds no parameter semantics beyond what the schema provides, including repeating the sortDir and gameId explanations.

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

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

States a specific verb and resource: add a leaderboard board to an existing game. It also distinguishes itself from the sibling bootstrap_leaderboard by explaining that this tool works only for already-existing games.

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 to use this tool for existing games and names bootstrap_leaderboard as the alternative for brand-new games. It also tells the agent where to get gameId (list_games), leaving no ambiguity about when to invoke it.

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

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

With no annotations, the description carries the burden and does disclose meaningful behavior: the result is an *empty* game (no boards or keys), it returns a gameId, and it is explicitly a precursor to create_board/mint_key. It does not state auth requirements, slug-uniqueness/conflict error behavior, or whether the call is idempotent, so it stops short of full behavioral coverage.

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

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

Three compact sentences, front-loaded with the action and followed by usage and follow-up guidance; every sentence carries routing information. Slightly dense with parenthetical asides, but no filler.

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

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

For a simple 2-param creation tool with no output schema, the description covers the critical missing piece (returns gameId) plus the create ordering context. The main residual gaps are permission requirements and duplicate-slug error behavior, which are meaningful for a mutating create call.

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

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

Schema description coverage is 100% — both 'name' and 'slug' are documented in the schema, including the slug pattern, length, and derivation hint. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Create a new (empty) game in the developer's account') and immediately distinguishes it from sibling tools by naming bootstrap_leaderboard, list_games, create_board, and mint_key. An agent can tell exactly what this produces and what it does not.

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

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

Explicit when-to-use ('when they ALREADY have a game'), when-not ('For a first-ever game from scratch, prefer bootstrap_leaderboard'), and prerequisite ('call list_games first to check'). It also names the correct follow-up tools in sequence, leaving no routing decision to inference.

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

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

No annotations are provided, so the description must cover behavioral traits. It implies a read operation and mentions a testing use case but does not explicitly state read-only nature, authentication needs, rate limits, or error conditions. Falls short of full disclosure.

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

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

Two sentences with clear front-loading of purpose. No extraneous words. Every sentence contributes value.

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?

Lacks details on output format and error conditions. Given the absence of an output schema, the description could briefly mention the structure of returned entries. Use cases are covered but operational completeness is lacking.

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 parameters are already well-documented. The description adds no additional meaning beyond the schema's definitions. Baseline 3 is appropriate.

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

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

The description clearly states it gets the top-ranked entries on a leaderboard. It distinguishes from siblings like list_boards or bootstrap_leaderboard by specifying leaderboard context and adding specific use cases.

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

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

The description provides explicit when-to-use scenarios: after submitting a test score to verify integration and for displaying standings. However, it does not discuss when not to use or mention alternative tools, which would further aid decision-making.

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

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

With no annotations, the description fully discloses behavior: it returns public key plaintext, secret key plaintext is always null over MCP, and provides rotation/revocation timestamps. It also warns about what it cannot do (return full secret key). No contradictions with annotations since none exist.

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

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

The description is concise yet comprehensive: first sentence states purpose, then describes returned fields, then usage guidance and alternative. Every sentence adds value without fluff. It is front-loaded with the 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?

Given no output schema, the description thoroughly explains what is returned (kind, prefix, timestamps) and what is not (secret key plaintext). It also references the required predecessor tool (list_games) and links to the dashboard for missing functionality, making it complete for the tool's scope.

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 gameId as 'UUID of the game to fetch keys for (from list_games)' with 100% coverage. The description adds context that gameId comes from list_games, but does not add new information about the parameter itself beyond what the schema provides. Baseline is 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 clearly states 'Get a game's API keys,' specifying the verb 'Get' and the resource 'API keys'. It differentiates from siblings by focusing on keys, which none of the other tools (bootstrap_leaderboard, get_board_top_n, etc.) cover.

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 tells when to use this tool: 'to retrieve the public key for a client_only integration, or to check which keys exist / have been revoked.' It also provides an alternative for the full secret key (dashboard). It implies that list_games should be used first to obtain the gameId.

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

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

With no annotations, the description carries full burden. It explains that the tool tailors the snippet based on axis arguments and returns a snippet field. However, it does not disclose side effects, authentication requirements, or rate limits, which would be needed for a 5.

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

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

The description is a single paragraph that effectively conveys key information without unnecessary words. It could be slightly more structured (e.g., bullet points) but is still concise 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 complexity (6 params, 4 enums, no output schema), the description covers primary use cases, distinguishes from siblings, and explains what the output contains. It does not mention potential errors or edge cases, but is sufficiently complete for most scenarios.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining how omission of axis args leads to simplest setup and gives context for each hostingPattern/playerIdentityStrategy beyond the 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 returns a ready-to-paste integration snippet for submitting scores, initializing SDK, or integrating a leaderboard. It distinguishes itself from sibling tool bootstrap_leaderboard by noting that the latter returns a drop-in widget HTML embed.

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 call: whenever the developer asks about integration, after bootstrap_leaderboard, or anytime they need the code again. Provides guidance on omitting arguments for simplest setup and when to use specific hostingPattern values.

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

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

No annotations provided, so description must disclose behavior. It describes the properties of returned boards but does not mention that it is a read-only operation, any side effects, authorization needs, or rate limits. The absence of such details lowers transparency.

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 two well-structured sentences. First sentence states main function. Second sentence provides details and usage context. No redundancy or 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?

Given the simplicity of the tool (one parameter, no output schema), the description covers the key aspects: input source, output characteristics, and usage scenarios. It could mention response format (array), but the list of board properties compensates.

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

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

Schema covers the only parameter with a description. Description adds value by explaining that gameId comes from list_games output, which helps the agent obtain the correct input. This extra context justifies a score above baseline.

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

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

Description clearly states it lists all leaderboards under a given game, and distinguishes from siblings by explaining its role in finding board IDs before using get_sdk_snippet or get_board_top_n. It also specifies the information each board contains, which provides clarity.

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 advises when to use: to find a board's id before generating a snippet or reading standings, or to show existing boards. It also references list_games as the source of the gameId. However, it does not explicitly state when not to use or compare to all sibling tools.

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

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

With no annotations, the description carries full burden. It describes the return structure and scope (owned by authenticated developer), but does not explicitly mention that the operation is read-only and safe. However, the context implies a safe list operation, and the description adds value beyond the name. A minor gap in explicitly stating safety attributes prevents a perfect score.

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

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

The description is three sentences, front-loaded with the primary action, and every sentence serves a purpose. No wasted words, and it is well-structured for quick parsing.

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

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

Given the tool's simplicity (no parameters, no output schema), the description fully covers what it does, what it returns (id, slug, name, createdAt), and provides usage context and alternatives. It is complete enough for an AI agent to use 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?

There are no parameters, and the input schema is empty with 100% coverage. The description does not need to add parameter semantics, so a baseline score of 4 is appropriate as per guidelines.

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 lists all games owned by the authenticated developer, and distinguishes itself from siblings by suggesting an alternative tool (bootstrap_leaderboard) for a specific scenario. The verb 'list' and resource 'games' 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?

Explicitly states to use this first for orientation before creating or inspecting resources, and provides a conditional guideline: if the result is empty and the developer wants to add a leaderboard, to call bootstrap_leaderboard. This gives clear when-to-use and when-not-to guidance.

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

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

With no annotations, the description carries the full burden and does so well: it names the return values (publicKey pk_, secretKey sk_), flags the 'shown ONCE' non-idempotent nature, tells the caller to have the developer store it immediately, and warns that the secret leaks into the MCP transcript. These are exactly the traits annotations could not have supplied anyway.

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

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

Front-loaded with purpose, return shape, and lifecycle warning; no sentence is filler and each one (return types, one-time visibility, revocation location, transcript caveat) earns its place despite the longer length.

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

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

There is no output schema, so the description must describe the return, and it does so precisely (pk_ vs sk_, one-time display). For a single-param credential-minting tool the description leaves nothing an agent needs in order to call it and handle the result safely.

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

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

Schema coverage is 100% and the gameId description already documents the UUID format and its source (from list_games). The prose reinforces that the game must be EXISTING and keyed by gameId, but adds no new syntactic or semantic detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Mint) and resource (public/secret key pair) scoped to an EXISTING game by gameId. It is clearly distinguishable from siblings like create_game (creates the game) and get_keys (retrieves existing keys), so an agent can route correctly without opening a schema.

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

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

'Use when a game needs keys, or to add another pair' gives the triggering condition explicitly, and 'Key revocation/rotation is done in the dashboard' states where the adjacent operation lives, effectively excluding it from this tool. Both when-to-use and where-not-to-go are covered.

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

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

With no annotations the description carries the full burden, and it delivers the key mutation semantics: only supplied fields change (PARTIAL), a bound can be cleared by passing null, and the call returns the full updated board. It omits permission/auth requirements, error behavior, and rate limits, which keeps it short of a 5 for an unannotated write tool.

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

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

Front-loaded with the action and the partial-update contract, then use cases, then the return value — every sentence carries information. Sentence structure is dense and heavily parenthesized, which costs a little readability but not enough to be wasteful.

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

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

For an unannotated mutation tool with no output schema, the description covers partial-update behavior, null-clearing, identifier provenance, and the return shape ('full updated board'). What remains absent is authorization/permission disclosure and failure behavior, which is the only real gap given 6 parameters and full schema coverage.

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

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

Schema description coverage is 100%, so maxScore/minScore/retentionPolicy/retentionN are already fully documented by the schema, including 'Pass null to clear it'. The description's parameter content (maxScore as anti-cheat cap, minScore as floor, null-clears) largely restates the schema rather than adding new syntax or constraints, so baseline 3 is appropriate.

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

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

States a specific verb+resource (update a board's scoring config) and pins the timing distinction 'AFTER creation', which separates it from create_board. It also names where the required identifiers come from (gameId from list_games, boardId from list_boards), so the agent can identify and call it without opening the schema.

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

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

Gives concrete use cases (cap scores for anti-cheat via maxScore, set a floor via minScore, change retention) and notes the partial-update contract. It does not explicitly say when not to use it versus update_game_config, but the 'board scoring config AFTER creation' framing implies the boundary clearly enough.

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

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

With no annotations, the description carries the full burden and does well: it discloses replace-not-merge behavior, the empty-array default (allow all), the 20-origin cap, the returned normalized list, and the non-obvious enforcement scope that only browser requests with an Origin header are gated. Auth/permission requirements for this mutation are still unstated.

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

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

Three tight sentences, front-loaded with the mutation and its identifier source, then format rules, then return/scope caveats. No filler; each clause adds operative information.

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

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

For a 2-param mutation with no annotations and no output schema, the description covers side effects (full replacement), defaults, limits, and the return shape ('normalized stored list'), leaving little an agent needs that isn't stated.

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

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

Schema coverage is 100% and the schema already documents both params (UUID source, exact-or-wildcard validation, maxItems 20, full replacement, empty = allow all). The description mostly restates that and adds concrete example patterns, which is marginal added value. Baseline 3 applies.

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

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

States a specific verb (Set) plus resource (a game's allowed-origins allowlist) and pins the operation to post-creation config, explicitly separating it from the at-creation path owned by siblings like create_game. An agent can identify the tool without opening the schema.

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

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

Says when to use it ('AFTER creation') and where the identifier comes from ('by gameId — from list_games'), which implies create_game handles the initial config. No explicit when-not or named alternative tool, so it stops short of a 5.

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