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, the description carries the full burden and does well: it discloses that execution is local with 'no browser, no live room, no push, no credentials,' and that it sweeps the declared input domain and reports exact failing arguments. It stops short of stating the read/write profile of the project (the 'without writing a file' clause only hints at it) and says nothing about failure exit behavior or runtime limits.

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

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

Front-loaded with the core action and scope before the elaboration, and the parameter notes come last. The em-dash enumeration of failure classes (NaN, Infinity, divide-by-zero, flattened curves, out-of-bounds values) is slightly long but each item adds discriminating information.

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

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

No output schema exists, so the description must imply the return shape; it does so by promising 'the exact arguments that broke a rule' and the `json` param documents 'full machine-readable report instead of the compact summary.' Combined with the local-execution and prerequisite context, an agent has enough to call it correctly, though the precise report structure is only sketched.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema for two params: it clarifies that the default manifest is read from audit/math.json and that `checks` is an inline alternative that overrides the file without writing one. It says nothing extra about `json` or `projectDir`, which is acceptable given full schema coverage.

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

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

States a specific verb and resource: 'Run declared numeric invariants over the game's pure functions, locally.' It further scopes the tool against siblings by naming spawn_audit_scan as the discovery step and contrasting with 'playing the game,' so an agent can place it precisely among the audit tools.

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

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

Explicitly says 'Use spawn_audit_scan first to see what is auditable,' which is a concrete prerequisite and alternative. It also gives the usage context ('catches what playing the game catches slowly and unreliably'), so the when-to-use case 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, the description carries the full burden and does useful work: it discloses that the scan needs "No browser, no room, no credentials," implying a static, side-effect-free read, and explains the classification heuristic it applies. It never explicitly states that it does not modify the project or how large projects are handled, so it leaves a small gap.

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 core purpose is front-loaded in the first clause, and the remaining sentences explain the classification rule and the call-site timing without filler. It is slightly dense in the middle (objectApi/engine-only require), but 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?

With no output schema and no annotations, the description still tells the agent what comes back (exported functions plus an auditability verdict) and what the tool requires. It omits the concrete shape/format of the result and any pagination or scale caveats, which is the main remaining gap.

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

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

Schema coverage is 100%, so projectDir and auditableOnly are already documented, establishing a baseline of 3. The description's discussion of objectApi concerns the game's functions rather than this tool's parameters, and it never explains what auditableOnly=true actually filters, so it adds little parameter-level meaning beyond the schema.

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

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

States a specific verb and resource ("List a game's exported functions") plus the discriminating output ("say which can be audited locally"), which cleanly separates it from siblings like spawn_audit_math and spawn_audit_ui that consume the manifest rather than discover it. An agent can tell what this returns without opening the schema.

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

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

Gives explicit sequencing guidance: "Run this BEFORE writing an audit manifest — it tells you what there is to check." That is a clear when-to-use condition. It stops short of naming the sibling tools it precedes or stating when NOT to use it, so it is 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?

No annotations exist, so the description carries the full burden and does so richly: no browser/live room/push/credentials needed, text-scan-only semantics, found/missing limits, default expect list from audit/ui.json with a 6-surface fallback, and the failure mode for unknown surface ids.

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?

Purpose and the key caveat (text scan, cannot judge appearance) are front-loaded, and each sentence covers a distinct behavior. It is dense and somewhat long, but the complexity justifies most of the length.

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

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

With no output schema and no annotations, the description compensates by explaining return verdicts (found/missing), the reference link it attaches, and the failure mode. An agent has everything needed to call it correctly and interpret results.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: the default source and fallback for expect, the ability to try a set without writing the file, and the error behavior on unknown ids. It adds less for genre/theme beyond what the schema already states.

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

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

States a specific verb and resource: locally count which of the 21 Interface In Game UI surfaces a Spawn game project has. It explicitly distinguishes itself from siblings by naming spawn_play_screenshot as the authority on appearance and spawn_skill as the follow-up action, so an agent can route without opening a schema.

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

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

Gives concrete when-to-use and when-not-to-use guidance: missing means go build the surface, load skills with spawn_skill then re-run; for appearance use spawn_play_screenshot instead. It also spells out that a found verdict is not a completeness verdict, leaving nothing to inference.

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

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

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?

With no annotations, the description carries the full burden and does disclose key behaviors: `--origin` is refused and why (token exfiltration), unknown verbs surface the client's own error, and the verb set can evolve independently of this tool. It is silent on permissions and return shapes, keeping it short of a 5.

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

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

Purpose and prerequisite are front-loaded, but the middle is dense with long parentheticals enumerating verbs, and the closing note about `verb:"--help"` is convoluted. Most content earns its place, yet the prose is heavier than needed for a dispatcher.

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 passthrough dispatcher with no output schema and no annotations, the description covers prerequisites, verb semantics, session behavior (ttl via schema), and the security constraint. It does not describe return formats, but that gap is modest given the open-ended verb surface.

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 a 3 is the baseline, but the description meaningfully enriches the `verb` parameter by explaining what each accepted value does (e.g. `where` is a sim read, no pixels; `inputs` describes key semantics HERE) and clarifies the arg-array convention that the schema also states.

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

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

States a specific action (dispatcher that runs any client verb against a standing body) and names the prerequisite sibling (spawn_client_join). It does not, however, differentiate itself from other exec-style siblings such as spawn_exec or spawn_play_console, leaving the agent to infer the boundary.

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

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

Gives explicit sequencing guidance ('Join first'), a routing hint to read `inputs` before sending any, and notes the verb list belongs to the client rather than this server. It stops short of stating when NOT to use this tool versus the narrower play/screenshot siblings.

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, so the description carries the full burden and does so: it discloses that the session is a detached background process outliving the call, that it SELF-EXPIRES at ttl, that Bun is required and the error surfaces if missing, and that the body appears in the room census with player hooks firing. It even states the failure modes (409 no_live_room / 5xx) an agent will hit before joining.

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

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

Front-loaded and dense – the first sentence establishes what it is and its key advantage. Three paragraphs are long for a six-param tool, and the 'live room / no browser, no GPU' framing is restated in slightly different words, but every sentence still carries substantive information.

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

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

With no annotations and no output schema, the description supplies what an agent needs: prerequisites (Bun), process lifetime semantics, expiry defaults and how to change them, error conditions, and the follow-up verbs to use or to call on cleanup. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents all six parameters. The description adds real meaning on top: ttl is framed as the safety net bounding how long the room stays live, with advice to size it to the work (minutes for a screenshot loop), plus the note that no engineVersion is accepted because joining is the engine-agnostic play door.

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

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

States a specific verb+resource ('Put YOUR OWN BODY in the world as a real player') and immediately positions it against the obvious alternative (spawn_play_open's headed Chromium). It also names the downstream verbs it unblocks (spawn_exec, spawn_logs) and the exit verb (spawn_client_leave), so the agent can differentiate it from every sibling without opening a schema.

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

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

Explicit when-to-use: you need it because spawn_exec/spawn_logs answer 409 no_live_room until a body stands. Explicit when-to-prefer-it: no GPU and cheaper than spawn_play_open. Explicit lifecycle guidance: raise ttl for a long session, call spawn_client_leave when done.

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

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

With no annotations, the description carries the full burden and delivers: the despawn is journaled before the socket closes, the room folds when the last body leaves, spawn_exec and spawn_logs stop working after this, and sessions self-expire at ttl. It does not cover failure modes such as calling with no active session, but the key side effects and state transitions are disclosed.

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 action is front-loaded in the first clause, and each subsequent sentence adds a distinct consequence (journaling, room folding, dependent-tool breakage, self-expiry) rather than padding. Slightly dense with em-dash clauses, but no sentence is wasted.

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

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

For a two-parameter, zero-required teardown tool with no annotations or output schema, the description covers purpose, side effects, and timing sufficiently. It omits return value and error behavior, but no output schema exists to require the former, so the gap is minor.

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 both parameters (session, projectDir) are already fully documented in the schema. The description echoes the ttl self-expiry behavior but adds no syntax or format detail beyond what the schema provides, making the baseline 3 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 states a specific verb+resource and scope: 'End the session and despawn the body.' It clearly distinguishes itself from siblings like spawn_client_join and spawn_client_status by describing a teardown operation.

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

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

'Call it when you are done' gives clear invocation context, and 'a session left alone self-expires at its ttl anyway' tells the agent this is optional and offers an implicit alternative (do nothing). It stops short of naming a sibling alternative or explicit when-not conditions, but the context is well established.

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

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

With no annotations, the description carries the burden and does disclose real behavior: sessions self-expire at their ttl, remaining TTL is reported, and an expired session is the common cause of no_live_room. It stops short of stating that the call is strictly read-only/polling and whether it has side effects, but the reporting framing makes the safe-read nature reasonably clear.

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

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

Two tight sentences, front-loaded with the decision question and then the actionable routing advice. The rhetorical opening costs a few words, but nothing is filler and the trailing guidance is the highest-value content.

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

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

There is no output schema, so the description correctly enumerates the returned fields (pid, world, connection phase, entity id, remaining TTL), which is exactly what an agent needs to consume a status report. Combined with the failure-mode routing, nothing essential is missing for a simple two-parameter read 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 both parameters (session, projectDir) are already documented with defaults, and the schema itself explains that a session self-expires at its ttl. The description reinforces the TTL concept but adds no syntax, format, or constraint detail 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?

States a specific verb and resource ('reports each session's pid, world, connection phase, entity id and REMAINING TTL') and answers the question the tool exists for (is a body standing and for how long). This is unmistakably distinct from spawn_client_join, spawn_client_leave, and the generic 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 tells the agent when to call it ('Check it before spawn_exec / spawn_logs when they answer no_live_room'), diagnoses the usual cause (expired session), and prescribes the remedy (join again rather than debug the endpoint). Both the trigger condition and the follow-up action are given.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: the .env write side effect, the platform-chosen engine lane, and that the result reports the lane. It omits auth/permission requirements, idempotency of game creation, and any error or revert behavior, leaving notable gaps for a mutating 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 main action is front-loaded in the first sentence, and subsequent sentences each carry non-redundant information (side effect, play URL, lane behavior, follow-up tool). The final sentence is dense and slightly winding but earns its place by explaining pinning behavior.

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

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

For a no-annotation, no-output-schema creation tool the description covers purpose, a side effect, the follow-up tool, and partial return behavior ('reports which lane'). It still leaves out what the result actually returns (play URL format, game id), auth needs, and failure modes, so it is only minimally 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 description coverage is 100% for both projectDir and setVariant, so the schema already documents them; baseline is 3. The description only adds the loose mapping of the .env write to setVariant and clarifies that engine is not a parameter, without new syntax or format 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?

States a specific verb and resource ('Create a new game in the creator's account') that an agent can act on directly. It also clarifies a non-obvious scoping detail: the engine/world pinning is not a caller argument. However, it never explicitly distinguishes itself from nearby siblings like spawn_bootstrap or spawn_init, so sibling differentiation is left implicit.

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

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

Usage context is implied through the workflow note that 'spawn_init then provisions for that lane' and the instruction to keep the play URL open, which tells the agent what comes next. It stops short of explicit when-to-use/when-not guidance or naming an alternative creation path, so it is adequate but not directive.

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

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

With no annotations, the description carries the full burden and does well: it discloses side effects (writes guide.md/tome-api.md/skills.json under .spawn/), that a passed engineVersion is an assertion that FAILS without writing on mismatch, and that engine detection is cached. It stops short of describing return shape or what the failure looks like, but the mutation and idempotency profile is unusually well covered.

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

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

Front-loaded with the purpose, then alternatives, in three tight sentences. Vocabulary is dense ('Tome API reference', 'document lane's one paragraph', capitalized 'IS') and assumes domain familiarity, which costs a point but no sentence is 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?

No output schema exists, so the description correctly compensates by naming what comes back (era + semver) and how guide content differs by engine era. Combined with the schema's full coverage of projectDir/engineVersion, an agent has enough to call it correctly; only the precise failure/output format is left implicit.

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 three parameters are already fully documented in the schema (including the assertion semantics of engineVersion). The description adds only marginal value here — the 'Optionally save under .spawn/' note mirrors the save parameter and the engine-detection note duplicates the schema. Baseline 3 is appropriate.

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

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

States a specific verb (fetch) and three concrete resources (this world's guide, the Tome API reference, the skills index), scoped to the pinned engine version. It explicitly distinguishes itself from the sibling spawn_skills ('For just the skill menu with descriptions, spawn_skills is cheaper'), so an agent can route without opening either schema.

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

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

Gives explicit when-to-use ('cheapest authoritative answer to WHICH engine that is') and an explicit alternative for the narrower need (spawn_skills for the skill menu). It also describes the version-dependent content an agent will get, which is decision-relevant context for choosing it.

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

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

With no annotations, the description carries the full burden and does so well: it declares the operation read-only, notes pushing is the only write path, discloses error codes for missing preconditions, and explicitly rules out api.sql (even SELECT). This is rich disclosure of constraints and failure behavior beyond structured fields.

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

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

Front-loaded with the core action and constraint, and each sentence adds a real constraint (write-path rule, room prerequisite, error codes, SQL exclusion). The parenthetical aside about spawn_play_open is slightly dense but earns its place by routing the agent.

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

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

For a 2-param read-only tool with no output schema, the description covers prerequisites, alternatives, failure modes, and a key limitation (no SQL). It does not describe the return value or pagination behavior, a minor gap given the schema's example mapping mitigates it somewhat.

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 both parameters (script, projectDir) are already documented in the schema, including an example return shape. The description adds context about what the script can do but no syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource: 'Run a read-only JavaScript snippet against the live room,' with clarifying examples (query objects, read an object's state). It differentiates itself from spawn_play_open ('the right call when you need to SEE rather than query') and spawn_client_join. It does not, however, explicitly contrast with the close sibling spawn_play_eval, which an agent might confuse it with.

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

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

Explicitly states the prerequisite (a LIVE ROOM), the cheapest alternative to establish one (spawn_client_join), and the alternative for visual needs (spawn_play_open). It also names the failure modes (409 no_live_room or 5xx) when neither is used. This is clear when-to-use and when-not guidance with named alternatives.

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

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

With no annotations the description carries the full burden, and it does disclose one genuinely useful trait: 'Needs no credentials.' It implies a read/orientation call that inspects the project, but never explicitly states it performs no writes, so the safety profile is inferred rather than declared.

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

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

Front-loaded with the imperative 'START HERE,' then a compact enumeration of what the call covers and what it reports. Dense but each clause carries real information; only mild redundancy between 'the whole workflow in one call' and the list that follows.

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 stand alone, and it does describe both the returned workflow content and the project-state summary, which is what an agent needs to orient. It could be slightly more explicit about the return shape, but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly, including engineVersion's assertion-not-override behavior. The description's mention of what it reports (token, variant, game.json, docs) loosely maps to projectDir but adds no semantics the schema lacks; 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?

It names a specific resource (the whole Spawn workflow) and states exactly what the call returns: setup order, skills to load, the push→screenshot→fix loop, multi-agent rules, plus the project's current state. The opening 'START HERE before any other spawn tool' explicitly separates it from siblings like spawn_docs, spawn_status and spawn_me.

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 when-to-use is unambiguous: call this first, before any other spawn tool, and it tells you which step you're on from the reported project state. It stops short of naming when a sibling is the better choice once onboarding is done (e.g. spawn_docs for reference), but the routing intent is clear.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the agent token being used per-command and never persisted to .git/config, .env/.spawn exclusion, shallow vs full history behavior, and the safety refusal of a non-empty non-matching directory. It also states the side effects concretely (what files land in .spawn/).

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?

Purpose and engine-branching are front-loaded, and the dense single block is mostly informative rather than padding. A few clauses, such as 'scaffolds as before', are vague filler, but nothing is repetitive enough to obscure the main point.

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

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

For a no-annotation, no-output-schema tool this covers the important ground: both execution paths, side effects, exclusion rules, auth handling and the failure mode on a version mismatch. It never states what the call returns on success beyond the docs it writes, which leaves a small gap for an agent deciding what to do next.

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

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

Schema description coverage is 100% and the schema already explains depth, projectDir and the engineVersion assertion in detail, so the description adds little parameter-level meaning beyond the alias 'projectDir (the clone target)'. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

Names a specific verb and resource ('Provision the project directory') and goes further than most by describing the two engine-dependent modes (git-lane clone vs document-lane scaffold). It does not explicitly differentiate itself from plausible siblings such as spawn_create_game or spawn_bootstrap, so an agent still has to infer the boundary.

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

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

Usage is implied rather than stated: the reader infers this is a first-step setup call, and the engine-version branch tells them which path will run. There is no explicit when-to-use or when-not-to-use guidance and no alternative tool is named, even though several siblings (spawn_create_game, spawn_bootstrap) could be confused with it.

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

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

With no annotations present, the description carries the full burden and does so richly: dirty trees are refused (not stashed), colliding rebases are aborted with commits intact and paths named, behavior is asserted by engineVersion rather than overridden, and lane-specific parameters are refused. This is unusually detailed behavioral disclosure.

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

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

Front-loads the core action, then splits behavior into ON ENGINE 6.0+ and ON PRE-6.0 blocks, which is sensible structure. It is dense and jargon-heavy (Savi, exec, clones, rail) but nearly every sentence conveys a behavioral fact rather than filler.

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

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

For a 7-parameter, no-annotation mutation/sync tool with no output schema, the description covers the behavioral surface an agent needs: lane differences, refusals, mutual exclusivity, and read-only vs write semantics. Return-value shape is left implicit, though 'colliding paths named' hints at 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 coverage is 100% and the schema already documents each parameter, but the description adds cross-parameter semantics beyond it: version and updateSlug mutual exclusivity in effect, mode/version/updateSlug/applyLocal being 'document-lane concepts' refused on git lanes, and applyLocal defaults differing per pull type.

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

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

The opening 'Take upstream's work into your project' states a specific action (pulling/syncing upstream) and the description distinguishes two engine lanes clearly. It is distinguishable from spawn_push through the mention of 'a refused push,' though it never names the sibling tool directly.

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

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

Gives concrete when-to-use cues: 'pull before you build and again after a refused push,' and 'use after version_conflict'; non-head pulls are read-only unless applyLocal. It stops short of explicit when-not-to-use framing or naming sibling alternatives.

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

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

With no annotations, the description 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, the description must carry the full behavioral burden. It usefully discloses a hard prerequisite (a live room must exist, and spawn_client_join can boot one headless), but says nothing about output format, freshness/live-tailing behavior, or log volume limits.

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

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

Three short sentences, front-loaded with what it returns, then when to use it, then the prerequisite. No filler, though the em-dash aside is slightly loose.

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?

Purpose, trigger, and prerequisite are covered, but there is no output schema and the description never characterizes the return payload (format, scoping, whether logs stream or snapshot). For a diagnostics tool an agent must parse, that is a meaningful gap.

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

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

Only one optional parameter exists and schema coverage is 100%, with the schema already documenting the absolute path, default resolution order (SPAWN_PROJECT_DIR / process cwd). The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description names the specific resource (variant logs plus live room script logs) and the kind of content retrieved, which is enough to distinguish it from the sparse sibling set. It is a noun phrase rather than a clean verb+resource, so it falls just short of the top band.

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 an explicit trigger ('use when behavior doesn't match what you pushed') and contrasts the source of truth with the push receipt. It also names spawn_client_join as the prerequisite path to obtain a live room, though it does not survey true alternative log sources.

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?

With no annotations and no output schema, the description carries the full burden and does disclose what the return covers (open state, URL, headed mode, error count, fleet read), which tells the agent this is a read-only status probe. It says nothing about auth requirements, side effects, or freshness of the data, so it is adequate but not rich.

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

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

A single compact sentence with no filler and the scoping/routing note parenthesized at the end. It is slightly hard to parse because it opens mid-thought ('Whether a...') instead of front-loading a verb, but nothing is wasted.

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

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

For a zero-argument status read with no output schema and no annotations, the description does the heavy lifting by enumerating the returned fields. An agent knows what it will get and where to go for more detail; only behavioral caveats like auth or data freshness are absent.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; baseline 4 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 names a specific resource (play browser session status) and enumerates what state it reports, plus it points to spawn_savi_status for detail, which distinguishes it from that sibling. It is phrased as a fragment of outputs rather than an explicit verb+resource, but the purpose — reporting play session status — is clear.

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

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

It routes the agent away for detail: '(spawn_savi_status has the detail)', implying this tool gives the summary and the sibling gives depth. However there is no explicit statement of when to call this versus spawn_status, spawn_client_status, or spawn_play_open, so usage is only implied.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses lane detection from the world's engine, that `message` is REQUIRED on 6.0+ and lands in the creator's chat, that `body` is the only door into Savi's chat, that pushes are serialised/rebased in team mode, and that 'a successful push proves it parsed, nothing more'. It also warns that a refused non-fast-forward means origin moved.

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

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

The purpose is front-loaded and nearly every clause carries operational weight (latency, error paths, chat-line rules). It is very dense and mixes usage, semantics and follow-ups into one block, which hurts scanability, but there is little padding.

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

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

For a complex, annotation-free, no-output-schema tool spanning two engine lanes and six parameters, the description covers both code paths, the required-field asymmetry, the result's `remote:` verdict lines, and the correct follow-up checks. Nothing an agent needs to call it correctly appears to be 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, but the description adds genuine meaning beyond the schema: `message` is explicitly framed as the creator's chat line rather than a log line, with content rules ('never how you did it, never a file or a function'), and `body` is explained as the channel for the how and for Savi. `force`/`dryRun` semantics are left to the schema.

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

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

The opening sentence states a concrete verb and resource ('Push your work live') plus scope ('~1s in every open room'), and the body distinguishes this tool from spawn_latest, spawn_play_screenshot, spawn_skill and spawn_audit_ui by name. An agent can tell what it does and how it differs from siblings without opening any schema.

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

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

It gives explicit when-to-use guidance for both engine eras, names the recovery path for two failure modes (non-fast-forward -> spawn_latest then re-push; 409 version_conflict -> spawn_latest, merge .theirs receipts, push again), and routes the agent to sibling tools for the questions this tool does not answer (spawn_play_screenshot, spawn_audit_ui, spawn_skill). Little is left to inference.

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

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

No annotations are provided, so the description 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?

Without annotations, the description carries the full burden. It discloses return content (active rooms and player counts), the target room for exec/logs, and what an empty list implies, plus that spawn_client_join makes a body appear. It does not cover permissions, side effects beyond the empty-list case, or error behavior.

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

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

Two sentences, no filler. The first sentence front-loads the returned data; the second handles the empty-list case and routing to spawn_client_join. Slightly compressed grammar ('the room exec/logs will target') costs it a point.

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 tool with no annotations and no output schema, the description explains the return concept and a key empty-state behavior. It leaves the room object structure implicit, but an agent can still 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?

The schema fully documents projectDir, so the baseline is 3. The description adds no parameter semantics beyond the schema, but none is needed for this simple optional path 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 names the resource (rooms), key attributes (player counts), variant scope, and relation to exec/logs targeting, so the agent can infer this is a listing tool. It stops short of an explicit verb like 'List' and does not fully contrast with all siblings, but it is clear.

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

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

It gives a specific edge case: if the list is empty, use spawn_client_join to boot a room. It does not state when to call spawn_rooms versus other status/play tools, nor does it list exclusions, leaving broad usage implied.

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

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

With no annotations provided, the description carries the full behavioral burden and does so richly: 'NOTHING COMES BACK: no reply, no acknowledgement, no completion event,' plus 'no endpoint on this API reports who pushed' and no author attribution. It explains how to detect uptake (wisp lighting up in spawn_savi_status) and how to infer completion (remote.headVersion advancing, spawn_team_status recentPushes). This is exactly the non-obvious mutation/side-effect context an agent needs.

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

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

The purpose is front-loaded, which is good, but the body is a dense wall of prose with repetition and asides (the status-detection recipe, the art-path tangent, the re-statement of 'nothing comes back'). Most sentences earn their place, but the block could be tightened considerably without losing meaning.

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

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

For a non-standard, annotation-free tool with no output schema, the description covers everything an agent needs: what happens side-effect-wise (no reply/ack), how to verify the work landed, where to look for status, and the constraint against blocking your own critical path. Nothing material is missing.

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

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

Schema coverage is 100%, so the schema already documents all five parameters and a baseline of 3 applies. The description adds genuine meaning beyond it: `task` must be 'BROAD and GENERAL... never as a step list' because the fan-out does the splitting, and `keepOff` declares your own boundary under the advisory 'spawn_team_claim' trust model. It also implicitly frames `subAgents` by describing the fan-out default. Slightly more value than the schema 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 opening sentence states a concrete verb and resource: 'Write into the creator's studio chat, where Savi (their in-game AI companion) reads it.' It distinguishes itself from the related 'spawn_savi_status' by telling the agent to check that first. The purpose is clear, though the 'write' framing is metaphorical enough that the real action (posting a message/task for an AI agent to pick up) only becomes fully explicit several sentences in.

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 cases ('(1) Context after a meaningful push'; '(2) HAND OFF WORK'), a precondition ('Check spawn_savi_status first'), a boundary instruction ('never put a delegated task on your own critical path'), and guidance on target selection ('the ones where your own lane is weakest'). It also names the sibling tools to consult (spawn_savi_status, spawn_status, spawn_team_status, spawn_latest).

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

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

With no annotations, the description carries the full burden and does well: it discloses the data source (the open play session from spawn_play_open), that no API endpoint exposes this, and that attribution does not exist. It does not state what happens if no play session is open or otherwise confirm read-only safety explicitly.

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

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

Front-loaded with the answer to 'what does this return' before the routing advice, and the wisps/flames mapping is a useful concrete detail. It is somewhat long for a status tool, with the idle-lane rationale running several sentences, but little is pure 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?

No output schema and no annotations, so the description must cover behavior — and it does, explaining the lane model, the source session, and the attribution limitation. The exact return shape (count plus per-agent task text) is only implied rather than spelled out.

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?

Zero parameters, so there is no per-parameter meaning to add and the baseline is 4. The description correctly implies the tool is callable with no arguments.

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

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

States a specific resource and scope — how many sub-agents Savi is running and what they are doing — with a concrete mechanism (the eight fan-out lanes). It is clearly distinguished from the adjacent siblings spawn_savi (which spawns), spawn_status, and spawn_play_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 names the call sites: before spawn_savi to size a handoff, and after one to confirm pickup. It also tells the agent what to do with the result (free lanes mean delegate a broader slice), which is actionable routing rather than vague advice.

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 behavioral burden. It does disclose meaningful traits: env is masked, the remote block is credential-gated, engine is detected/cached, and the engine era changes what the remote block contains. However it omits read-only/permission expectations and any rate or cost considerations, leaving gaps for a no-annotation tool.

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

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

Front-loaded with a one-line purpose, then organized by engine era (6.0+ git block vs pre-6.0 version rail). Slightly wordy with figurative phrasing ('the world's ENGINE ... which decides everything else', 'version rail'), but most sentences carry useful information.

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

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

With no output schema, the description must convey return values, and it does so thoroughly for both engine eras. It is essentially complete for a status tool, though it could note that output shape depends on credential availability and detection caching more explicitly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (remote, projectDir, engineVersion) including the assertion-vs-override semantics. The description adds the concept of a 'remote block' but no parameter syntax or format beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description identifies this as a project-level status/diagnostic readout and enumerates specific content (masked env, credential source, docs, engine era+semver, git or version rail). This makes the resource and scope concrete. It does not explicitly differentiate from sibling status tools like spawn_savi_status or spawn_play_status, so it stops short of a 5.

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

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

There is no statement of when to call this versus alternatives such as spawn_getting_started, spawn_latest, spawn_me, or the other *_status siblings. Usage is only implied by the description of what it reports, which is not enough guidance for an agent choosing among many 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 full burden and delivers: it enumerates what is actually checked (ESM parse of scripts/templates, .scene header vs filename cell key, image bytes vs extension, binaries under assets/), discloses that clean does not guarantee the push lands, and that valid is not the same as good. This is exactly the behavioral context an agent needs for a validator.

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

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

Front-loaded with the core action and the engine-era branching, and every clause is information-dense. It is long and slightly repetitive (the local-vs-server contrast is restated), but no sentence is pure filler.

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

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

For a tool with no output schema and no annotations, the description is nearly complete: it explains both engine-era behaviors, the assertion semantics, and the limits of the result. A brief note on the failure/return shape would close the last gap, though the absence of an output schema lessens the obligation.

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 schema already documents projectDir and the engineVersion 'assertion, not override' semantics. The description repeats the assertion idea but adds no parameter detail 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?

States a specific verb and resource ('Check the project before pushing') and immediately distinguishes itself from spawn_push by explaining that on engine 6.0+ the push is the authority and this is a LOCAL pre-flight, while pre-6.0 it runs server-side schema validation. An agent can tell exactly what this tool does and how it differs from the sibling that ships code.

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?

Clearly says when to use it ('before pushing') and names the related tools (spawn_push as the authority, spawn_skill as the source of visual/feel quality). It does not state an explicit when-not-to-use condition, but the pre-push context is unambiguous.

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