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

With no annotations, the description carries the burden of behavioral disclosure. It reveals a non-obvious constraint: names are permanent ('cannot re-roll a name') and only this tool records which name is a bad replacement. It also hints at a temporal caveat (write description while visible). However, it does not disclose side-effects like whether fields are updated or replaced (schema says tags replace, but not in description), or if the tool triggers asset generation. This is partial transparency, not full.

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 four sentences, front-loaded with the core purpose, and every sentence earns its place: function, name-handle explanation, permanence rationale, and timing advice. It is concise, readable, and avoids redundant repetition of schema parameter descriptions.

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 7 parameters, no annotations, and no output schema, the description gives sufficient context for selection and invocation: what it does, when to use it, and a critical behavioral constraint. The schema already documents parameter semantics, so the description doesn't need to enumerate them. Remaining gaps include how updates/merging work for existing notes and what the return value is, but these are not essential for an agent to correctly call the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context for the 'name' parameter (usable in place of path everywhere) and for 'replacedBy' (explains the 'wrong thing' information gap), but these mostly rephrase schema descriptions. No new syntax or format details are added beyond what the schema already provides, so the description adds marginal 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 opens with a clear verb list ('Name, categorize, describe or judge') on the resource 'asset in the bank', and explicitly distinguishes this tool from siblings by noting it can annotate paths not yet scanned. It also frames the unique value proposition (a persistent handle usable across all asset tools), making it immediately clear what the tool does and how it differs from scan/sync/search/preview.

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

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

The description implies when to use the tool: when you can still see the asset ('Write the description while you can still see the asset') and for paths that have not been scanned yet. It gives context that names become reusable handles and that recording 'wrong thing' is only possible here. It does not explicitly name alternative tools or provide when-not-to-use exclusions, but the sibling list and the stated purpose make the usage context sufficiently clear.

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

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

With no annotations, the description fully explains safety: it queries the storage host directly without triggering generation and clarifies that a 404 means not created rather than forbidden. This prevents common misconceptions.

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 focused sentences: purpose, usage scenarios, and safety. No fluff, front-loaded with the primary 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?

The description covers purpose, usage, and safety for a simple 3-parameter tool. With no output schema, it could clarify return format for non-image assets, but the schema and description together are 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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning beyond the schema, mainly reinforcing inline rendering which is already documented in the render parameter.

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

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

The description clearly states the tool checks asset existence and returns images inline for visual inspection. The verb 'check' and 'look at' specify the resource and distinguish it from sibling tools like search, sync, and scan.

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 usage contexts are given: use on unfamiliar paths before building, and after generating a new asset. However, it does not explicitly mention exclusions or alternatives beyond implied context.

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

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

No annotations exist, so the description carries the full burden. It discloses key behavioral traits: 'Spawn generates an asset on first fetch of its path and keeps it there forever', 'there is no catalog API', and 'this bank is the only record of which names you have already used and how they turned out.' This reveals persistence, irreversibility, and sole-source-of-truth nature.

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, each earning its place: first states the core action, second explains the behavioral consequence and rationale, third gives the required operational order. No fluff or redundancy.

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

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

With no annotations and no output schema, the description must cover purpose, side effects, and relationship to siblings. It does all that: it explains what is harvested, why the bank is the only record (no catalog API), and how to use the tool in conjunction with spawn_asset_search. The full workflow is conveyed.

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%, with both dirs and projectDir already well-described. The description adds workflow context ('any directory', 'each of your game projects') but no new syntactic or semantic detail about the parameters beyond what the schema provides.

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

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

The description clearly states it 'Harvest every cdn/ asset path used in a project (or any directory) into the local cross-project asset bank' with a specific verb ('harvest') and resource ('cdn/ asset paths'). It distinguishes from sibling tools by explicitly directing users to spawn_asset_search for searching.

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 usage workflow: 'Run it on each of your game projects once, then use spawn_asset_search before inventing a new asset name.' This names an alternative tool and gives a clear sequence of when to use this scan tool versus searching.

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

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

With no annotations provided, the description carries the transparency burden. It discloses result semantics ('Every result reports how many distinct GAMES use it'), the meaning of good/bad paths, and the facets behavior. It stops short of explicitly stating side effects or output shape, but 'search' implies read-only and the added detail exceeds a bare description.

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

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

Four sentences, each carrying distinct value: purpose, when-to-use, result interpretation, and advanced facet exploration. It is front-loaded with the main purpose and contains no redundancy or filler. Efficient for the tool's complexity.

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

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

Given 13 parameters, no required fields, and no output schema, the description covers the crucial workflow context well: when to call, how to reuse paths, how to judge signals, and how to browse facets. It doesn't enumerate return fields (e.g., pagination or limit behavior), but the rich input schema compensates, making this a strong, near-complete description.

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 high (85%+), so baseline is 3. The description adds extra meaning for key parameters: it explains the `facets` usage pattern, ties result game-count to `minGames` filtering, and links 'bad' verdicts to spelling pitfalls. This supplements the schema descriptions meaningfully.

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

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

The description opens with a specific verb+resource ('Search the local asset bank') and clearly defines the scope ('assets you (or your other projects) have already used'). It also differentiates from siblings by emphasizing 'search' versus scan/sync/note, and by connecting to the workflow of reusing verified assets.

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

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

It gives explicit when-to-use guidance: 'Call this BEFORE inventing a new cdn/ asset name'. It also provides a concrete alternate usage ('Pass facets:true with no query to see what categories, kinds and style families the bank holds') and explains how to interpret results (distinct GAMES usage count, good/bad paths). This is actionable and unambiguous.

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 excels. It discloses the operation is 'SLOW BY DESIGN' with expected duration, explains what it overcomes, and notes the absence of an asset API. It also implies account-wide scope and the authoritative nature of the sync, giving the agent a clear behavioral model.

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 well-structured and front-loaded. It opens with the core action, then explains value, performance, usage triggers, and underlying rationale. Every sentence adds meaningful context without redundancy or filler.

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

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

Given the tool's complexity (account-wide sync, slow, no output schema), the description is remarkably complete. It covers purpose, what it can see beyond local scans, performance expectations, when to run, and why it's necessary. No crucial context is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond the schema, but it provides context for the overall behavior that involves these parameters (e.g., account-wide sync). The schema descriptions suffice.

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

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

The description uses a specific verb ('Sync') plus resource ('asset bank') and method ('list every game you own, fetch each one's current server-side spec, and harvest the cdn/ assets'). It explicitly differentiates from sibling spawn_asset_scan by noting coverage of games without local checkout and assets added by teammates or Savi.

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

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

The description clearly states when to use: 'Run it once to populate an empty bank, and again when the other asset tools say the bank is stale.' It also contrasts with spawn_asset_scan, explaining what this tool covers that the scan cannot, giving an explicit alternative.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it excels. It explicitly states the side effect (writes SPAWN_AGENT_KEY to project .env), the response behavior (full token NEVER returned, only masked prefix), and the key lifecycle (expires in ~5 minutes, works once). This gives the agent a complete picture of what to expect without needing 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 a compact set of four sentences, each serving a distinct purpose: stating the core exchange, the side effect, the security-masked response, and the key's time/usage limits. No redundant phrasing or filler exists. It is front-loaded with the primary action and immediately provides critical operational details.

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 no output schema and no annotations, the description provides a complete operational picture for a 3-parameter tool of moderate complexity. It explains the return value (masked prefix), the persistent side effect (.env write), and the constraints on the input key (expiry and single-use). This is sufficient for an agent to invoke the tool correctly and interpret the result, making it contextually complete.

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

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

The input schema already provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema: it reinforces the bootstrap key format (sbk_…) and its one-time nature, but it does not add value to the 'name' or 'projectDir' parameters beyond their schema descriptions. The schema does the heavy lifting here, so no additional credit is warranted.

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

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

The description uses the specific verb "trade" to explain the exchange of a bootstrap key for a durable agent token, clearly identifying the resource and action. It also mentions the side effect of writing to .env, which distinguishes it from sibling tools like spawn_revoke or spawn_me. The purpose is unmistakable and unique among the listed siblings.

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

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

The description implies when to use this tool (when you possess a one-time setup bootstrap key) and provides critical timing constraints (keys expire in ~5 minutes and work once). However, it does not explicitly name alternatives or situations where this tool should not be used, such as when a durable token already exists. Overall, the context is clear but lacks explicit 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?

There are no annotations, so the description carries the full burden. It discloses the side effect of optionally writing SPAWN_VARIANT_ID to .env and instructs keeping the play URL open, but does not mention permissions, reversibility, or the return format.

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 sentences with no filler: the first states the core purpose, the second adds a side effect and a usage instruction. 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 tool has no output schema and no annotations. The description provides the core purpose and a side effect, but it does not explicitly state what the tool returns (the play URL is only indirectly referenced) nor any error behavior or prerequisites, leaving gaps for the 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 100%, with both parameters already well-documented. The description's mention of writing SPAWN_VARIANT_ID to .env mirrors the schema's setVariant description, adding no new semantic information.

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

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

The description clearly uses the verb 'Create' with the resource 'a new game' and specifies the scope 'in the creator's account'. This distinguishes it from sibling tools like spawn_init or spawn_bootstrap that also relate to game projects.

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

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

The description implies the tool should be used when the goal is to create a new game, and the post-creation instruction ('keep the play URL open') hints at the workflow. However, it does not explicitly state when not to use it or mention 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?

No annotations are provided, so the description carries the full burden. It discloses the optional save side effect ('Optionally save under .spawn/') but is vague about the default behavior (schema default save=true), what 'cheaper' means, and what the tool returns when save=false. This is acceptable but lacks depth.

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

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

Two sentences, front-loaded with the core purpose, and every phrase earns its place. The alternative tool mention is concise and packed with useful guidance without any 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?

For a simple read/fetch tool with 2 optional params, 100% schema coverage, no output schema, the description is mostly complete. It states what is fetched, the save option, and the cheaper alternative. The only notable gap is the absence of return-value description, but 'Fetch' strongly implies the content is returned, so it does not feel under-specified.

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 reinforces that the content includes guide/API/skills but adds no new details beyond schema. Baseline 3 is appropriate because the structured schema does the heavy lifting.

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

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

The description uses a specific verb ('Fetch') and names three concrete resources: engine guide, tome API reference, and skills index. It clearly distinguishes this tool from the sibling spawn_skills by explicitly naming the alternative for skill-only needs.

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 final sentence provides explicit guidance on when to use a different tool: 'For just the skill menu with descriptions, spawn_skills is cheaper.' This gives the agent a clear selection criterion and names the alternative, exceeding a mere context implication.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the read-only nature, the requirement for an active room, the 5xx error condition, and the server-side refusal of SQL. This goes beyond the schema and annotations, giving the agent a complete picture of expected behavior.

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

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

The description is front-loaded with the core action ('Run a read-only JavaScript snippet') and then provides essential caveats in a tight three-sentence structure. Every sentence adds unique and necessary information, with no filler or redundancy.

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

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

The description thoroughly covers prerequisites, restrictions, and error conditions, making it highly actionable. The only minor gap is that it doesn't explicitly describe the return value format, but since the tool is an evaluator, the return is implicitly the script's result. This is a small omission given the otherwise comprehensive 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 already provides thorough descriptions for both parameters, including an example for the script. The description adds the critical constraint that api.sql is not available, which directly influences what the script parameter can contain. This adds value beyond the schema's 100% 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 tool's purpose: 'Run a read-only JavaScript snippet against the live room' with concrete examples like 'query objects, read an object's state'. It distinguishes itself from write tools by noting 'Pushing is the only write path', and from database access by explicitly excluding api.sql.

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

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

Usage is explicitly tied to a live room: 'open spawn_play_open first or you get a 5xx' directly references the prerequisite and alternative. It also states when not to use it: for any database access, since api.sql is unavailable. This provides clear when-to-use and when-not-to-use guidance.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses that it 'reports what this project already has' and 'needs no credentials,' but does not explicitly state whether it modifies anything or describe the return format. The read-only implication is present but not explicit.

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 three-sentence description front-loads the critical 'START HERE' directive and efficiently enumerates workflow contents, project state reports, and credential requirements without 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?

Given no output schema, the description partially compensates by listing the reported project artifacts (token, variant, game.json, docs) and the workflow steps covered. It lacks explicit return formatting, but for an orientation tool the provided context is largely sufficient for an agent to decide when and how to use it.

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

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

Schema has 100% coverage; projectDir is fully described in the input schema. The description does not add parameter-specific meaning beyond mentioning 'project' context, so 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?

Description explicitly states 'START HERE before any other spawn tool' and describes its function as 'The whole workflow in one call' plus reporting project state, distinguishing it from siblings like spawn_init and spawn_status.

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

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

Explicitly instructs to use before any other spawn tool ('START HERE before any other spawn tool'), provides timing guidance ('before building anything visual'), and notes credential-free operation. The directive is clear even though alternatives are not named.

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

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

With no annotations, the description carries the full burden. It reveals key behaviors: creating .gitignore to protect secrets, creating directories, pulling a spec into game.json, materializing scripts, and fetching docs. However, it does not disclose side effects like overwriting existing files, requiring an existing project, or network dependencies. This is a moderate level of transparency for a scaffold 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 a single dense sentence that front-loads the purpose and uses concise step enumeration. It contains no filler, but the long list of actions could be more readable if split into bullet points. Still, every word contributes.

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

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

The tool is relatively simple with one optional parameter and no output schema. The description covers the main scaffold actions but omits prerequisites, return behavior, and error conditions. It is adequate but lacks full contextual depth for an agent to anticipate all outcomes.

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 has 100% coverage for the single parameter 'projectDir', including its default behavior. The tool description adds no parameter-specific information beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the tool scaffolds a Spawn game project, with specific resources: gitignore, world/ + scripts/, game.json, and .spawn/ docs. It uses the specific verb 'Scaffold' and lists concrete actions, distinguishing it from sibling tools like spawn_create_game or spawn_docs.

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

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

The description implies when to use the tool: when setting up a new Spawn project scaffold. It provides clear context but does not explicitly mention alternatives or exclusions. It could improve by contrasting with similar siblings like spawn_bootstrap, but the purpose is unambiguous.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It candidly explains that head pulls write sync scripts and update the base-version rail, while non-head pulls are read-only unless applyLocal:true resets the local rail. It also discloses conflict handling (both-changed → <file>.theirs) and parameter mutual exclusivity, which are critical behavioral traits.

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 dense yet concise, packing modes, defaults, conflict behavior, read-only conditions, and parameter constraints into three sentences. It front-loads the core purpose, and every clause adds useful information with no filler or redundancy.

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

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

Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers purpose, usage, side effects, and parameter interactions thoroughly. However, it does not describe what the tool returns or outputs, which would be helpful in the absence of an output schema. Minor error behavior is also not addressed, so the score is one below excellent.

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?

Though the schema covers all parameters at 100%, the description adds meaningful interaction semantics: it explains the default applyLocal behavior per mode, mutual exclusivity of version and updateSlug, and the rail/reset implication of applyLocal. This goes well beyond what the schema's individual descriptions provide.

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

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

The description opens with 'Pull a saved spec' which is a specific verb+resource, and then enumerates the distinct modes (head, live, version, updateSlug) that the tool supports. It also notes 'use after version_conflict', which frames its role among sibling tools and distinguishes it from related commands like spawn_push or spawn_init.

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

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

The description clearly states when to use head pulls ('use after version_conflict') and contrasts head vs non-head behavior, but it does not explicitly name alternative tools or state when not to use the tool. The guidance is contextually clear without naming siblings, so it falls just short of a 5.

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

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

With no annotations, the description must carry the transparency burden. It discloses the output format and token-based restriction, but it does not explicitly state the operation is read-only, nor does it cover error conditions or authentication details. Some behavior is clarified, but gaps remain.

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

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

The description is a single sentence that efficiently communicates the tool's purpose, output shape, and a follow-up instruction. No wasted words, and the structure is clear 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?

For a simple listing tool with one optional parameter and no output schema, the description covers the core context: what is listed, the return shape, and the next step. It could add a brief note on read-only behavior or how projectDir affects results, but overall 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?

The input schema has full coverage for the single optional parameter projectDir, so the baseline is 3. The description does not add any meaning beyond the schema for this parameter; it focuses on the output and usage, not the 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?

The description clearly states the tool lists games the current token can push to, with a specific verb ('List') and resource ('games'), and it distinguishes itself from sibling tools like spawn_push or spawn_create_game. It also provides the exact output shape, making the purpose unambiguous.

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

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

The description implies usage for selecting a game to push to and instructs asking the creator which one by name, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The guidance is present but implicit.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool shows but not how it behaves (e.g., real-time streaming, return format, side effects, access requirements). The word 'live' hints at streaming but is ambiguous. This lack of detail leaves significant gaps.

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

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

The description is two concise sentences. The first front-loads the tool's purpose, and the second gives a practical usage condition. No fluff or redundancy; 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?

With no output schema and no annotations, the description must explain what the tool returns or provides. It does not describe the format, granularity, or how logs are presented. It also lacks context on prerequisites (e.g., project setup). Given these gaps, the description is not complete enough for an agent to fully anticipate the tool's output.

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% for the single parameter 'projectDir', which is already documented with defaults. The description does not add any extra meaning about the parameter, but it also does not need to because the schema covers it. 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 the tool provides 'Variant logs + live room script logs', identifying its resources and distinguishing it from sibling tools that handle status or console output. The verb is implicit ('get' or 'show'), but the specific resource combination and use-case hint make the purpose reasonably 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?

Explicitly provides a 'Use when' condition: 'behavior doesn't match what you pushed.' This gives clear context for when the tool is appropriate. It does not mention alternatives or when not to use, but the guidance is sufficient for a straightforward logging tool.

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

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

With no annotations, the description carries the full burden. It discloses the key behavioral detail that the tool uses the 'connected Spawn agent token' and specifies exactly what is returned. While it does not explicitly state that the operation is read-only or free of side effects, that is reasonably inferable from the 'whoami' nature, and the description adds meaningful context beyond the tool name.

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

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

The description is a single, front-loaded sentence with no wasted words. It immediately communicates the tool's essence and return format, making it highly scannable and concise.

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 identity-lookup tool, the description is highly complete: it says what the tool does, what token it uses, and what it returns. The only optional parameter is fully documented in the schema. The description could add a note about behavior when no token is available, but the low complexity does not demand it.

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

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

The input schema covers the only parameter (`projectDir`) with a clear description of its default behavior, giving 100% schema coverage. The main description does not mention `projectDir`, but since the schema already fully documents it, the description does not need to compensate. Baseline 3 applies.

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

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

The description clearly states the tool's purpose with a specific verb ('returns') and resource ('connected Spawn agent token'), and explicitly specifies the return shape `{ userId, username }`. This distinguishes it from sibling tools like spawn_list_games or spawn_status, which focus on other aspects of the Spawn environment.

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 intended usage is implied: use this tool when you need the current user's identity. However, there is no explicit when-to-use guidance or mention of alternatives. No sibling tool appears to offer the same functionality, so the lack of exclusions is not problematic, but the description stops at stating what it does.

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

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

With no annotations, the description carries the full burden. It clearly states the primary action (closing the session) but does not disclose edge cases such as idempotency, behavior when no session exists, or resource cleanup details. This is adequate for a simple close operation but lacks depth.

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

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

The description is a single, front-loaded sentence that states the action and target directly. There is no redundant or unnecessary text.

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

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

Given the tool's simplicity (no parameters, no output schema, basic lifecycle action), the description is largely complete. It could mention calling behavior when no session is open, but the core context is sufficient.

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

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

The tool has zero parameters, so per guidelines the baseline is 4. The empty schema fully covers the input contract; no additional semantic explanation is needed.

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

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

The description uses a specific verb ('Close') and resource ('Playwright Chromium session'), clearly distinguishing it from sibling tools like spawn_play_open or spawn_play_screenshot. It leaves no ambiguity about what the tool does.

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

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

There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or consequences. The intended use is implied only by the name and domain, not stated.

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

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

No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. While 'Return' implies a read-only operation, it does not specify whether messages are cleared, the meaning of 'recent' (time window), or any side effects. This lack of detail could mislead the agent about the tool's 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?

Two sentences, no wasted words. The first sentence front-loads the action and subject, and the second provides a cross-reference. Structure is optimal for quick comprehension.

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 captures the essential purpose and context (browser console vs server logs), and the schema covers the filter types. However, without an output schema, it doesn't describe the return format or ordering, and the semantics of 'limit' remain unclear. For a simple read tool, this is adequate but leaves noticeable gaps.

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

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

Schema description coverage is 50%: only the 'types' parameter has a description with example values, while 'limit' has no description. The tool description adds no parameter-specific meaning, leaving 'limit' ambiguous (e.g., count limit, default value, application scope). The description should have compensated for this missing schema detail.

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

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

The description uses a specific verb ('Return') and resource ('recent browser console / pageerror messages from the play session'), clearly distinguishing it from server-side logging. It also explicitly names the sibling tool spawn_logs, making the differentiation 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 guidance by stating 'Pair with spawn_logs for server-side script errors.' This tells the agent when to use this tool (client-side messages) and implicitly when not (server-side errors), offering a clear alternative.

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

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

With no annotations, the description fully carries the transparency burden. It discloses the cross-origin sandbox limitation, that reaching into the frame throws, and that the tool cannot access game UI. It also explains that the script must be an expression, not a function body, which is critical behavioral context.

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

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

The description is front-loaded with the core purpose, then expands into usage scenarios, limitations, and alternatives in a compact, well-organized way. Every sentence contributes meaningful information without redundancy.

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

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

For a simple one-parameter tool with no output schema, the description comprehensively covers purpose, usage, limitations, and alternatives. The only minor gap is not explicitly stating that the expression's return value is returned to the caller, but this is reasonably inferred from 'Evaluate JavaScript'.

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

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

The schema already provides 100% coverage with a detailed description of the 'script' parameter (expression vs. function body, IIFE syntax). The tool description adds contextual value by clarifying what the script can access (top frame) and the sandboxing limitations, which enriches parameter understanding 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 evaluates JavaScript in the play page's top frame, distinguishing it from the Spawn room API and sibling tools like spawn_exec and spawn_play_input. It explicitly lists diagnostic use cases (WebGPU support, network state, document title), making the purpose 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 when-to-use guidance (page-level diagnostics) and when-not-to-use (cannot see/click game UI). It names alternatives: spawn_play_input for clicking UI and spawn_exec for reading world state, making the usage boundaries very 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?

No annotations exist, so the description carries the full burden and does well: it discloses the one-time canvas-center click for keyboard focus, the batching behavior without stray clicks, and the cross-origin iframe limitation. Minor inconsistency: the description says to call spawn_play_screenshot after, but the schema has screenshot=true by default; this is not a direct contradiction but could cause slight confusion.

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

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

Three sentences, each with a clear purpose: definition, focus behavior, and UI workflow. It is front-loaded with the primary action and contains no fluff; every sentence earns its place.

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

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

Given the tool's complexity (5 parameters, 7 action types), the description covers the critical behavioral context: the one-time click, the UI-click method, and the follow-up screenshot step. It does not explicitly describe return values, but since the primary output is a visual screenshot and schema handles details, this is adequate. Could mention the screenshot parameter indirectly but not necessary.

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

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

Schema descriptions cover 100% of parameters, so baseline is 3. The description adds value beyond the schema by explaining the canvas-center click behavior (relevant for click coordinates and refocus), and the pixel-from-screenshot workflow for x/y, improving practical understanding of the actions parameter and coordinate fields.

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 'Send keyboard/mouse actions to the play session' with a specific verb and resource. It also distinguishes itself by noting it is the ONLY way to click the game's UI, separating it from sibling tools like spawn_play_eval.

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

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

Provides explicit when-to-use guidance by explaining that spawn_play_eval cannot reach the cross-origin UI iframe, so this tool is required. It also gives a concrete workflow: screenshot first, read button coordinates, then click those positions, and suggests a follow-up with spawn_play_screenshot.

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 reveals the default headed mode, the critical failure of headless (no WebGPU adapter, 'One graphics fix away' gate), and that the result reports webgpu status. It also explains why screenshot and input are preferred. It doesn't explicitly state that a screenshot is returned by default, but that is covered in the schema.

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

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

The description is six sentences and slightly verbose, but every sentence earns its place—covering purpose, usage context, and the headless pitfall. It is well-structured and front-loaded with the primary action, avoiding unnecessary filler.

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

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

Given no annotations and no output schema, the description is fairly complete: it explains what the tool does, when to use it, the critical headless limitation, and what the result reports. It does not explicitly mention the default screenshot return (though the schema does), and width/height are not described, but overall it provides substantial context for an opening tool in a Playwright-based workflow.

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 78%, just below the 80% threshold, so the description should compensate. It does add one useful semantic: playUrl resolves from the variant if omitted, and it reinforces the headed parameter. However, width and height remain undocumented in both description and schema, and the description doesn't enhance the other parameter meanings beyond what the schema already provides.

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

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

The description clearly states it opens the live Spawn play URL in a local Chromium via Playwright, using a specific verb 'Open' and resource. It distinguishes itself from siblings like spawn_play_screenshot and spawn_play_input by framing itself as the agent's 'eyes/hands' on the game.

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

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

The description provides strong usage context: it should be used as the agent's primary interface, and it explicitly warns against headless mode because it cannot render WebGPU. It does not mention alternatives by name, but implies this is the entry point before using screenshot/input tools, and gives a conditional note about playUrl resolution.

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 burden falls on the description. It states the action (reload) and hints at system behavior (rooms reshape in place), but doesn't disclose potential side effects (e.g., whether state is lost, if it's safe, or if it's synchronous). This is adequate for a simple reload but lacks the depth expected without annotation support.

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 terse sentences: the first clearly states the tool's action, the second provides a practical tip. No redundant phrasing 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 covers the tool's core purpose and a key usage scenario, but with no output schema and partial parameter documentation, it's incomplete. It doesn't mention return values or behavior of the undocumented parameters, leaving gaps for a tool with four optional 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?

The schema only documents format and quality; waitMs and screenshot lack descriptions. The description doesn't clarify these parameters—its 'waiting ~1s' advice refers to waiting before invoking the tool, not to the waitMs parameter. Since schema coverage is only 50%, the description should compensate but doesn't, leaving agent uncertain about half the 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 opens with the specific action 'Reload the play tab' and contextualizes it with an example ('if a push didn't hot-apply to this client'). This clearly differentiates it from sibling tools like spawn_play_screenshot or spawn_play_input, which have different purposes.

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

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

It gives explicit when-to-use guidance ('if a push didn't hot-apply') and a strong recommendation to wait before reloading ('Prefer waiting ~1s after spawn_push first'), which effectively tells the agent when NOT to use this tool. It references the alternative (spawn_push) and explains the expected behavior (rooms usually reshape in place).

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

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

No annotations are provided, so the description carries the burden. It explains the tool's purpose and implies read-only behavior (screenshot), but does not disclose return value semantics (e.g., what is returned when save=false), potential side effects, or authentication requirements. It does add valuable context about interpreting the screenshot, which exceeds a bare description.

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 few sentences long but each one earns its place: action, primary usage, troubleshooting guidance, and optional behavior. It front-loads the core purpose and stays focused, though it could be slightly condensed without losing 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?

Despite having no output schema, the description gives enough context for an agent to know what to do with the result ('look at the image'). It covers workflow timing, failure interpretation, and optional saving. The only notable gap is an explicit statement of the return format when save=false, but the overall guidance is robust for a screenshot 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 80%, so baseline is 3. The description adds no real parameter-level detail beyond the schema; it merely mentions 'Optionally save under the project,' which duplicates the save parameter description. The parameter semantics are adequately handled by the schema, and the description does not add further meaning.

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

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

The description opens with a specific verb and resource: 'Screenshot the open play session.' It clearly differentiates this tool from siblings by identifying it as the primary visual check after spawn_push. No other sibling tool performs screenshots, so 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?

The description provides explicit context: use it after spawn_push and before declaring the change done. It also gives a decision path (interpret the image, identify missing skills, load relevant craft) and notes an optional save. It doesn't list alternatives or when-not-to-use, but the workflow guidance is strong.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists the output fields (open status, URL, headed mode, recent error count) but does not explicitly state that the tool is read-only, has no side effects, or whether it requires an existing session. This leaves key behavioral expectations unstated.

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

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

The description is a single concise fragment that front-loads the key output dimensions. Every word adds information, and there is no redundancy or filler.

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

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

With no output schema, the description adequately lists several return values (open status, URL, headed mode, recent error count). It does not mention error cases or define what a 'play browser session' is, but given the sibling tool names, the context is likely clear. It is sufficiently complete for a simple status query.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema fully covers the input. No deduction needed.

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

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

The description clearly indicates this tool reports the status of a play browser session (open/closed, URL, headed mode, recent error count). It distinguishes itself from the general spawn_status and the other play_* action tools by specifying 'play browser session' as 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?

No guidance is given about when to use this tool versus alternatives like spawn_status or spawn_play_open. The description implies it is for checking session state, but it does not state prerequisites, exclusions, or how it differs from other status/play 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 disclosure burden. It covers key behaviors: every push rebuilds the live room, conflict handling, team-mode rebase semantics, and the fact that a successful push only proves spec parsing, not visual correctness. It also reveals that untextured/plain results imply a missing skill. This is rich and honest about consequences.

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

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

The description is somewhat long but every sentence carries operational value, from the core action to conflict handling and success caveats. It is well-structured, front-loading the main purpose before diving into edge cases and troubleshooting, making it appropriate for the tool's complexity.

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

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

Given the tool's complexity (conflict resolution, team mode) and the absence of both annotations and output schema, the description is remarkably complete. It explains success criteria, failure modes, and follow-up actions, leaving little ambiguity for an agent to misuse the tool. The inclusion of concrete skill IDs for visual issues is a strong bonus.

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% (force and projectDir have descriptions; dryRun does not). The description adds no parameter-specific meaning, leaving dryRun entirely unexplained. It does not clarify when to use force or how projectDir is resolved. While the schema covers two params, the missing dryRun and lack of any parameter hints make this below the baseline.

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

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

The description clearly states the tool's function as 'Compile + push the project live', specifying both the action (compile and push) and the resource (project/live room). It also distinguishes itself from related tools by referencing spawn_latest, spawn_play_screenshot, and spawn_skill for specific follow-up actions.

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

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

Provides explicit when-to-use guidance: handles 409 conflicts by calling spawn_latest, then merging .theirs and pushing again. It also explains team-mode behavior (serialized, rebased) and advises checking spawn_play_screenshot before considering work done, plus points to spawn_skill for visual issues. This clearly differentiates from 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?

No annotations are provided, so the description carries the burden. It clearly discloses the side effect of removing SPAWN_AGENT_KEY from project .env and adds 'after success', implying transactional behavior. It does not cover all edge cases (e.g., missing .env), but it provides meaningful behavioral context beyond the tool name.

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 that front-load the primary action and then provide a specific detail about the effect on .env. No redundant or irrelevant information is included.

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 tool with one optional parameter and no output schema, the description adequately explains what the tool does and its side effect. It could mention success/failure reporting, but the core functionality and context are sufficiently 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?

The only parameter, projectDir, is fully described in the input schema with a clear description, so schema coverage is 100%. The tool description does not add any additional parameter semantics, but the baseline of 3 applies because the schema already explains the parameter.

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

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

The description uses a specific verb ('Revoke'), a clear resource ('the durable agent token'), and adds a parenthetical '(disconnect)' plus an explicit effect ('Removes SPAWN_AGENT_KEY from project .env after success'). This clearly distinguishes it from sibling tools like spawn_init or spawn_exec.

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

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

The description provides clear context by stating the tool is for revoking a durable agent token and includes the purpose '(disconnect)'. It does not explicitly name alternatives or exclusion criteria, but the use case is evident and sufficient for a focused revocation operation.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation (reporting active rooms and player counts) but does not explicitly state this, nor does it mention the return format, side effects, or permission requirements. The name 'spawn_rooms' could also suggest a creation action, creating ambiguity about whether this tool mutates 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?

The description is extremely brief (one sentence) but under-specified. It front-loads the core subject but omits essential details like the action, output, and usage context. This is more under-specification than effective conciseness.

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

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

With no annotations, no output schema, and only one parameter, the description must explain what the tool returns and how it behaves. It mentions 'active rooms + player counts' but does not describe the output structure or any edge cases. The lack of usage guidance and behavioral details makes it incomplete for an AI agent to reliably invoke.

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

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

Schema description coverage is 100%, so the input schema fully documents the sole parameter 'projectDir'. The tool description adds no additional meaning to the parameter, but baseline is 3 since the schema already covers it. The description's reference to 'current variant' is not linked to the parameter, providing no extra semantic 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 'Active rooms + player counts for the current variant' identifies the resource (rooms, player counts) and scope (current variant) but lacks a verb, making the tool's action ambiguous. It could be interpreted as a listing/status query, but it does not explicitly state 'list' or 'get', which limits clarity. It is not a tautology but is vague about the operation being performed.

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 no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions. The sibling tools list includes many potentially related commands, but no differentiation is made.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the intent (leaving context) but omits mechanics such as whether prior context is overwritten, how Savi accesses it, or any side effects. The metaphor 'leave background context' lacks operational detail needed for an agent to understand the mutation's consequences.

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

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

The description is a single sentence that front-loads the verb and target, making it efficiently sized. However, the poetic phrasing ('fight over the world') is less precise than a straightforward operational statement, slightly reducing clarity.

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 only two parameters and no output schema, the description leaves out important context such as prerequisites (e.g., an active game project), success/failure behavior, and how this tool fits into the broader gameplay workflow. An agent would not know exactly when or how to invoke it correctly.

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

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

Schema coverage is 100%, with both parameters fully described in the schema (including an example for 'message' and a default for 'projectDir'). The description adds no parameter-level detail, so the baseline of 3 applies.

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

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

The description clearly states a specific action ('leave background context') directed at a distinct entity (Savi), and frames it with a clear use case ('after meaningful pushes'). This distinguishes it from sibling tools like spawn_push, which push changes, making the tool's purpose unambiguous.

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

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

The description provides clear timing guidance ('after meaningful pushes') and explains the intended outcome ('so you don't fight over the world'). It does not explicitly name alternatives or exclusions, but the context of when to use it is evident.

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

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

No annotations are provided, so the description carries the transparency burden. It states the primary mutation (setting an env var in .env) and its purpose, but does not disclose potential side effects such as overwriting existing values, validation behavior, or impact on any running game.

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

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

The description is a single sentence that front-loads the action ('Set SPAWN_VARIANT_ID in the project .env') and appends a clarifying parenthetical. There is no redundant language; 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 simple two-parameter tool with no output schema, the description captures the essential purpose and behavior. It lacks explicit return/error information but is largely sufficient given the schema coverage and simplicity, making it almost complete.

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

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

Schema coverage is 100%, with both parameters fully described in the input schema. The description adds no new parameter details beyond reinforcing that variantId comes from spawn_list_games, so it meets the baseline for well-documented schema 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 uses a specific verb ('Set') and resource ('SPAWN_VARIANT_ID in the project .env'), then clarifies the purpose ('join an existing game from spawn_list_games'). This clearly distinguishes it from sibling tools like spawn_create_game, which create new 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?

The parenthetical explicitly frames usage as joining an existing game from spawn_list_games, providing clear context and a workflow hint. It does not enumerate alternatives or explicit 'when not to use' scenarios, but the context strongly implies the correct scenario.

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

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

No annotations are present, so the description carries the full burden. It discloses that skill documents are ~7k tokens each, that loading is cheap, that a miss returns the real menu, and that skipping skills yields default-looking output. This is rich behavioral context.

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

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

While dense, the description front-loads the core action and each sentence provides actionable guidance (what, why, combinations, error behavior). It is moderately long but earns its length for a tool with this conceptual 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 lacking an output schema, the description covers the essential context: when to call, what parameters to choose, size constraints, and failure behavior. It also points to spawn_skills for the authoritative list (in schema), making it sufficiently complete 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?

The schema already describes all three parameters in detail (100% coverage), so the bar is at 3. The description adds value by giving concrete combination examples (HUD = game-ui + drawn-art) and the token-budget rule, which are not explicit in the schema's parameter 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 loads the 'craft' (skills) needed for upcoming work, with an explicit directive to pass all relevant skills. It differentiates from the API reference, but does not explicitly name sibling tools like spawn_skills for list retrieval within the description, slightly limiting sibling differentiation.

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

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

Provides explicit when-to-use guidance: load skills before building, pass every domain touched, limit to 2-4 ids, and combine visual skills for visual work. It also notes that guessing ids is safe and cheap, with a miss returning the real menu.

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 properly carries the transparency burden. It discloses that it reads .spawn/skills.json when present, falls back to the API without network/credentials in that case, and that refresh requires credentials. It also mentions the approximate token size for 'full' detail, giving a sense of cost. A minor gap is that it doesn't explicitly describe the response structure or error handling for API failures, but the provided context is already strong.

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

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

The description is a few well-organized sentences with no filler. The core purpose and high-level usage appear first, followed by behavior and fallback guidance. Each sentence contributes new information, and the warning about skipping the tool when you already know what you need is a valuable inclusion without bloat.

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

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

This is a lookup/index tool with no output schema, so the description must explain what to expect, and it does. It explains where the data comes from (local file or API), when credentials are needed, and that a wrong ID yields the list anyway. It also gives enough context about the content (skill domains, mechanic and look) to help an agent decide when to call it. The combination of purpose, usage, fallback behavior, and token-size note makes it complete for this tool's complexity.

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

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

Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds meaningful value beyond the schema: it explains the detail parameter's token size implication, notes that search is case-insensitive over id/name/description, and clarifies that refresh rewrites the local index and needs credentials. projectDir also gets context about default resolution, though the schema already covers that. This lifts it above the baseline.

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

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

The description clearly identifies the tool as a menu of skill IDs for use with spawn_skill, each with what it covers. It distinguishes itself from the sibling tool spawn_skill by framing itself as the lookup/index companion to that tool. The phrase 'Browse it when planning a build' gives a concrete verb and 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?

The description provides explicit usage guidance: use it when planning a build to gather all relevant skill domains, and skip it if you already know what you need, passing IDs directly to spawn_skill. It also notes that a wrong ID will answer with this list anyway, giving a fallback behavior. This clearly differentiates when to use this tool versus the sibling spawn_skill.

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

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

With no annotations, the description carries the full burden. It discloses that env is masked, that remote fetch depends on credentials, and reports conflict receipts and docs presence. However, it does not explicitly state whether the tool performs any writes or the exact response structure, leaving slight ambiguity.

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

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

The description is a single, front-loaded sentence that packs meaningful detail without fluff. It efficiently lists the key output categories and the credential condition, making it easy to parse in one line.

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 status tool with no output schema, the description sufficiently enumerates the returned data points: env (masked), base version, conflict receipts, docs present, and head/published version comparison. It covers the essential information an agent needs to know what this tool returns, though it omits potential error scenarios or file paths.

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% for both parameters (remote, projectDir), and the description does not add meaning beyond what the schema already provides. Baseline of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool reports local project status plus optional remote head/published versions, and enumerates specific data items (env, base version, conflict receipts, docs present). It distinguishes from siblings like spawn_play_status by specifying 'local project' and remote version details, though it lacks an explicit verb and does not name alternative 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?

No explicit guidance on when to use this tool versus alternatives. The only hint is 'when credentials allow' for remote versions, which is a credential condition, not a usage guideline. It does not say when to prefer spawn_play_status or other sibling tools.

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

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

With no annotations, the description carries the burden of exposing behavior. It discloses a key nuance (schema-valid ≠ good), but does not mention potential side effects of compilation, whether it is read-only, or what the return value/response format is. The limitation statement adds transparency, but details are incomplete.

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

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

Two sentences, front-loaded with the core action, followed by an important caveat. No filler or redundant text. 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 tool has a simple parameter and clear purpose, but no output schema exists and the description does not explain what the tool returns (e.g., success/failure, validation report). The caveat about quality is useful, but the absence of return-value information leaves a gap for a validation tool.

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

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

The schema provides a full description of projectDir, but the description adds meaningful context about the expected project structure: 'game.json + world/*.json + scripts/**'. This goes beyond the schema's mention of 'game.json / .env' and helps the agent understand what files are relevant.

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 action: 'Compile the project ... and run authoritative server-side schema validation.' This specifies the verb (compile/validate), the resource (project files), and the scope, distinguishing it from sibling tools like spawn_init or spawn_play_* which serve different purposes.

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 useful context on when to rely on this tool: it validates schema but not quality. It explicitly warns that 'Schema-valid is not the same as good' and points to the spawn_skill as the source of quality guidance. While it doesn't explicitly name alternative validation tools, it gives clear usage context and a limitation.

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