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

With no annotations, the description carries the whole burden; it does disclose the target file and the exact row template that gets appended, which is real behavioral value. It omits what happens if the file doesn't exist, whether existing rows are touched, and whether req_id collisions are rejected or overwritten.

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?

One sentence, front-loaded with the mutation and destination, with the row format shown inline where it matters. Nothing wasted, nothing padded.

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 write tool with no annotations, no output schema, and 0% schema coverage across 5 parameters, the description is adequate but not complete: the `project` parameter and file-creation/duplicate handling are unaddressed, leaving an agent to guess at call correctness.

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 0%, so the description must compensate. The row template implicitly maps req_id, kind, target_path and description to their slots, but the `project` parameter (default 'default') is never mentioned, and no semantics are given for req_id format or target_path expectations.

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?

A specific verb ('Add') plus resource ('asset requirement row') and an explicit destination (workspace/ASSET_REQUIREMENTS.md), with the downstream motivation ('so Forge can generate it'). It distinguishes itself naturally from list_asset_requirements and fulfill_asset_requirements, but never explicitly contrasts with the closely related fulfill sibling.

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 a workflow (record a requirement so Forge can generate it later) but gives no explicit trigger for when to call this instead of fulfill_asset_requirements or write_workspace_doc. No prerequisites, no exclusions, nothing about idempotency or duplicate req_ids.

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 behavioral burden, and it only covers scope. It says nothing about whether intermediate folders are auto-created for a deep path, what happens if the folder already exists, permission requirements, or reversal (undo_action exists as a sibling). Those are the questions an agent needs answered before invoking a mutation.

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

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

Two short sentences, front-loaded with the action and followed by the scope boundary. No filler and no repetition of the tool name.

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?

Two-sentence description for a two-parameter mutation with no annotations and no output schema. The core intent is covered, but idempotency, error behavior, and the project parameter are all left unexplained, which is meaningful for a write 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 0%, so the description must compensate. It does partially: the example "characters/bosses/infernal" conveys that path is a slash-delimited nested path. But the second parameter, project (defaulting to "default"), is never mentioned, and it stays ambiguous whether path is absolute or relative to the category.

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 nested blueprint folder") and immediately bounds it against related asset operations with "Does not create or delete blueprints." That negative clause also separates it from the sibling delete_blueprint, though no other sibling is named.

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 "under a category" framing plus the explicit "does not create or delete blueprints" gives clear when-to-use and when-not-to-use context. It stops short of pointing at the correct alternative (e.g., delete_blueprint for removal), so it is not a 5.

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

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

With no annotations, the description carries the full behavioral burden and does not meet it: it never says whether registering an existing recipe_id errors, overwrites, or versions; whether validation of the recipe content happens; or what happens on malformed YAML. Only the fact that the operation is a mutation ('register a new') is inferable.

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 front-loaded sentence with no filler; the whole definition is one clause plus a modifier. Brevity here is partly under-specification rather than deliberate economy, but structurally it is clean.

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-required-parameter mutation tool with no annotations and no output schema, the description should at minimum cover ID collision behavior, recipe content expectations, and relationship to run_recipe. None of that is present, so an agent must guess at call-correctness.

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 0% and the description explains neither recipe_id (naming rules, uniqueness, scope) nor yaml_content (expected schema/shape of a recipe). It also says 'YAML or JSON' while the parameter is named yaml_content, leaving an agent unsure whether JSON is accepted in that field.

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 (register) and resource (declarative recipe), with the medium (YAML/JSON) and the key value proposition (no code changes). It does not explicitly differentiate from the sibling run_recipe, which an agent could easily confuse with registration.

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 use this versus run_recipe, no mention that a recipe must exist before running it, and no prerequisites or ordering guidance. 'Without touching code' hints at the declarative alternative but never spells out a decision rule.

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 does the heavy lifting: it declares permanence, the confirm gate, and the important side-effect boundary that generated assets survive unless delete_generated_assets is also true. That is genuine behavioral disclosure an agent could not infer from the schema. It omits permissions requirements and whether undo_action can recover the deletion.

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, no filler, with the destructive nature and the confirm requirement front-loaded before the side-effect caveat. Every sentence carries information.

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

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

For a destructive four-parameter tool with no annotations and no output schema, the description covers the risky parts well but leaves half the parameters and the recovery story unexplained. An agent could call it safely only if it already knows what item_id and project expect.

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 0% across four parameters, so the description must compensate, and it only explains two: confirm and delete_generated_assets. The required item_id and the project parameter (which defaults to 'default') are left entirely undefined, so an agent must guess their format and scoping.

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 ('Permanently delete one blueprint') with the scope qualifier 'one', which is precise enough to distinguish it from bulk or folder-level operations among siblings. An agent knows immediately what this tool does.

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

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

The description gives a hard prerequisite ('Requires confirm=true'), which is real usage guidance, but it never says when to prefer this over alternatives or what happens versus undo_action, a sibling that could plausibly reverse it. Usage is implied rather than framed.

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. It does disclose one genuinely useful behavior beyond the schema — that API keys are never included — which is a security-relevant trait. However, it omits whether files are written to disk and where, whether existing exports are overwritten, and what permissions or setup are needed.

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?

One compact sentence with no filler, and the core purpose plus the security guarantee are front-loaded. It is efficient, though efficiency here partly reflects under-specification rather than disciplined editing.

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?

A four-parameter action tool with no annotations and no output schema needs the description to explain the return artifact and side effects, and this one does not. An agent cannot tell whether it gets file paths, a bundle, or a job handle, nor where the export lands.

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 0%, so the description must compensate, and it does not. It only mentions the engine names, which merely restates the enum already in the schema, and says nothing about 'formats', 'project', or 'asset_ids' (scope of the export).

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 (export) and resource (engine-ready folders and metadata) and enumerates the three target engines, so the agent knows exactly what it produces. It is clearly distinguishable from sibling tools like writeback_apply or run_recipe, though it never explicitly says so.

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 versus writeback_apply, writeback_preview, create_blueprint_folder, or the other write-side siblings. No preconditions (e.g., whether assets must be scanned or requirements fulfilled first) and no exclusions 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 behavioral burden. It implies a read-only listing, but says nothing about return shape, whether results are paginated, how 'placeholder' is determined, or whether an unscanned project yields empty results or an error — all relevant for a tool whose scope depends on prior scanning.

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?

One front-loaded sentence with no filler; the purpose and scope come first. It is efficient, though terse enough that the brevity costs information elsewhere.

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 read tool this description covers only intent; it omits the scan prerequisite, the meaning of 'project', and expected results. With no annotations and no output schema to lean on, more context is needed before an agent could call it confidently.

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 single 'project' parameter has 0% schema description coverage and is never mentioned in the description. It is unclear whether 'project' refers to a scanned project name, defaults sensibly, or is required in practice despite the default of 'default' — the description does nothing to compensate for the coverage gap.

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: it lists placeholder/temp assets scoped to 'the scanned game project' with the intent of replacement. This distinguishes it from generic listing, but it does not explicitly differentiate itself from the sibling list_assets, which an agent could plausibly 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?

The phrase 'found in the scanned game project' implies scan_game_project must run first, but that prerequisite is never stated as a condition. There is no guidance on when to choose this over list_assets or how it relates to asset_requirements; the agent must infer everything.

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 meaningful side effects: it writes to ASSET_REQUIREMENTS.md, marks items [x], computes SHA-256 receipts, and appends to HANDOFFS.md. However, it omits key behavioral details such as whether existing entries are overwritten, idempotency, required permissions, and what happens on failure, leaving important mutation semantics unclear.

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

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

The description is a single front-loaded sentence that packs the full workflow without filler. It is dense but efficient, and every clause corresponds to a concrete action or output artifact.

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 multi-file mutation tool with no annotations, no output schema, and three undocumented parameters, the description is too thin. It never states what the tool returns (e.g., receipts, counts, paths) or how the batch is limited, which an agent needs in order to call and interpret it correctly.

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

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

Schema description coverage is 0% across three parameters, and the description does not explain project, req_ids, or max_items. An agent must guess that req_ids selects which open requirements to fulfill and that max_items caps the batch size, which is insufficient for correct invocation.

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 specific verbs (generate, compute, mark, append) tied to concrete artifacts (ASSET_REQUIREMENTS.md, HANDOFFS.md), so an agent can tell this is a batch fulfillment workflow rather than a simple read or single-item add. It does not explicitly differentiate itself from siblings like add_asset_requirement, post_agent_handoff, or write_workspace_doc, which keeps it from 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 explicit guidance on when to use this tool versus alternatives such as add_asset_requirement or post_agent_handoff, nor any when-not-to-use conditions or prerequisites. The workflow is implied by the description but not framed as actionable selection guidance.

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

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

With no annotations, the description carries the full load; it does convey that this is a retrieval of many derived artifacts (lineage, QC, Critic, graph relations), which is genuinely useful behavioral context. It stops short of stating read-only guarantees, behavior for a missing/invalid asset, or response shape, so 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?

A single front-loaded sentence with no filler; every listed item describes a distinct part of the returned payload.

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 enumerated payload list effectively substitutes for the missing output schema. However, with no annotations and 0% schema coverage, the absence of any statement about the project scoping parameter or error behavior leaves the definition only minimally complete for a lookup 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 0%, so the description must compensate — but it says nothing about either parameter. The 'project' parameter (defaulting to 'default') is entirely unaddressed, leaving scope ambiguity about which project an asset_id is resolved in.

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?

Specific verb ('Get') plus resource ('a single asset'), with an enumeration of what is retrieved: metadata, prompt lineage, QC report, Critic report, parents, children. The 'single asset' scoping implicitly separates it from list_assets, though no sibling is named.

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 only implied: reach for this when you need the detailed view of one asset rather than a listing. It never states when to prefer list_assets or related tools (rate_asset, find_placeholders), nor any prerequisite such as needing a valid asset_id first.

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

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

No annotations are provided, so the description carries the full burden. It does useful work by disclosing the exact returned fields and the currency (USD), which confirms this is a read of financial state. However, it says nothing about behavior for an unknown/missing project, whether caps are configured or null, or any auth requirement.

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?

One sentence, front-loaded with the verb and immediately followed by the concrete payload. No filler and nothing buried.

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 correctly compensates by naming the return fields, which is the most important missing piece. It still leaves the only parameter undocumented and gives no failure-mode context, so the definition is adequate but not 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 0% and the single `project` parameter has no type-level description, yet the description never mentions it. The agent cannot tell whether `project` is a name, ID, or path, nor what the "default" value resolves to.

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?

Specific verb+resource ("Get ... budget") with an explicit enumeration of the four values returned: spend, per-run cap, project cap, remaining USD. It is unambiguous and no sibling tool overlaps with budget retrieval, so differentiation is implicit rather than stated.

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

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

No explicit when-to-use guidance, no prerequisites, and no mention of alternatives. The listed return values (per-run cap, remaining budget) strongly imply the gating use case — checking affordability before run_verb or run_recipe — but the agent must infer that.

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

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

With no annotations, the description carries full behavioral burden. It does disclose the shape of the payload (evidence, confidence levels, catalog, wishlist), which implies a read-only operation, but it says nothing about failure when no profile has been scanned, staleness, or size/pagination of the returned profile.

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?

One front-loaded sentence with no filler; the parenthetical list of returned contents earns its place. Slightly dense but efficient.

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

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

The description partially compensates for the missing output schema by enumerating what comes back, and the only parameter is optional. Given an unannotated, no-output-schema read tool, an agent could call this correctly, though failure modes and project scoping remain unexplained.

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 0% and the single 'project' parameter (default 'default') is never mentioned in the description. The description therefore does not compensate for the gap — it doesn't say what a project scopes or what happens when omitted.

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?

Specific verb 'Retrieve' plus resource 'Game Profile', with an enumeration of contents (evidence, confidence levels, catalog, wishlist) that makes the return value concrete. It reads clearly as the read counterpart to update_game_profile, though it never names that sibling explicitly.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as update_game_profile, scan_game_project, or get_project_bible. The agent must infer from the name that this is the read path and that a prior scan must exist.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read, and the parenthetical lists the returned fields, which partially substitutes for the missing output schema. It says nothing about behavior when a project has no bible, whether the default project is created, or permission requirements.

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?

One sentence, front-loaded with verb and resource, with the field list doing double duty as return-value documentation. No filler.

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

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

For a simple single-parameter read tool this is close to adequate, and the field enumeration covers return content in the absence of an output schema. The undocumented 'project' parameter and the silence on missing-bible behavior leave a real 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?

The single 'project' parameter has 0% schema description coverage and a bare default of 'default', and the description never mentions it. The agent gets no guidance on what identifier form is expected or what the default resolves to. Only the fact that it is optional keeps this above a 1.

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?

Specific verb (Get) plus a named resource (Project Bible) and an enumerated list of what it contains: art style, palette, polycount budget, target engine, autonomy mode, spend caps. That makes it clearly distinct from update_project_bible and get_budget siblings. It stops short of explicitly naming the sibling it complements.

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 update_project_bible, get_budget, or get_game_profile, all of which overlap on project config. The agent must infer that this is the read-side of a read/write pair.

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 alone. It usefully discloses the source file, the parsing behavior, the three status markers, and that SHA-256 receipts are attached, which implies a read-only operation. It does not say what happens if the file is missing, whether it is safe/idempotent, or how large the result can be.

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 front-loaded sentence that packs the source, the operation, the return categories, and the receipt detail with no filler.

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

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

Return shape is reasonably covered despite no output schema, and the read-only nature is implied. However, for a tool whose only parameter is undocumented and whose failure modes are unstated, an agent still lacks what it needs to call it confidently across projects.

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 0% for the single 'project' parameter, and the description never mentions it. The hardcoded 'workspace/' path hints at project scoping but leaves the agent to guess what the parameter controls or what 'default' means.

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 verb pair ('Parse ... and return'), a specific resource (workspace/ASSET_REQUIREMENTS.md), and the exact status buckets it returns. This clearly separates it from write-side siblings like add_asset_requirement and fulfill_asset_requirements, though it never names an alternative explicitly.

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 use this versus list_assets, read_workspace_doc, or the requirement mutation tools. The reading context is only inferable from the fact that it returns open/in-progress/completed items; no prerequisites or exclusions 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 behavioral burden; it does reveal that results include both assets and the lineage DAG and that every filter is optional. It omits pagination/result-size limits and any permission or read-safety statement, which matter for a 'list all' 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?

A single sentence, front-loaded with the operation and scope, with the filtering note trailing. No filler.

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

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

For a read-only list tool with five optional params and no output schema, the description covers scope and filters adequately. The remaining gap is return-shape/volume expectations for the lineage DAG payload.

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 0%, so the description must compensate; it names four of the five filters (type, status, approval_state, tag) but uses 'type' while the schema key is 'asset_type'. The fifth parameter, 'project' (default 'default'), is only implied by the phrase 'in a Forge project'.

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?

Specific verb 'List' plus resource 'all assets and the lineage DAG' scoped to 'a Forge project'. It is naturally distinguishable from the singular sibling get_asset, though it never names that sibling explicitly to reinforce the split.

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 word 'optionally filtered' implies when to pass filters, but nothing states when to use list_assets versus get_asset, list_asset_wishlist, or find_placeholders. Usage is inferable but not guided.

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

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

No annotations are provided, so the description carries the full burden. It notes that items are 'discovered by Game Scan,' which hints at data provenance, but it does not state that the operation is read-only, whether it triggers a scan, how results are ordered, or any pagination or side-effect behavior.

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

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

The description is a single front-loaded sentence with no wasted words, making the tool's purpose immediately clear. It is appropriately concise, though the brevity leaves important gaps unaddressed.

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

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

For a simple list tool with one optional parameter and no output schema, the description adequately states what is returned. However, it leaves the project parameter unexplained and offers no usage or behavioral context, 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 0% and the description never mentions the single 'project' parameter, its default value, or what it represents. The description therefore adds no meaning beyond the bare schema, which only shows a string property with a default.

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 (List) and resource (prioritized missing assets, placeholders, and TODO art items) with a clear scope (discovered by Game Scan). It is clear on its own but does not explicitly differentiate itself from siblings like list_assets or find_placeholders, 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?

The description states what the tool returns but gives no explicit guidance on when to use it, when not to use it, or which sibling tools to prefer. An agent could infer it is relevant after a Game Scan, but no such instruction is 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 carries the full behavioral burden. It mentions that packs may be 'auto-scanned' but does not clarify whether scanning is triggered, what the return format looks like, or any permissions or side effects.

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

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

The definition is a single front-loaded sentence with no wasted words. It is appropriately sized for a simple zero-parameter list operation.

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

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

For a simple list tool, the core purpose is covered, but the absence of an output schema means the description could helpfully say what a returned Style Pack contains or how it should be used. It also does not clarify what 'auto-scanned' means in practice.

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, and the description does not need to explain parameter semantics. The baseline for zero-parameter tools is 4.

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 ('List') and resource ('Style Packs') and scopes the result to 'all available built-in and auto-scanned' packs. It is clear what the tool does, though it does not explicitly distinguish itself from sibling listing tools such as list_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?

The description states only what the tool does, not when to use it, when not to use it, or which sibling tool to choose instead. No alternatives or preconditions are mentioned.

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, but it does disclose the key behavioral trait: the operation appends rather than overwrites, and targets a fixed path (workspace/HANDOFFS.md), so existing entries survive. It says nothing about whether the file is created if absent, ordering, permissions, or what the call returns.

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 sentence with no filler, front-loading the action and target file before the rationale. It is efficiently structured, though its brevity reflects under-specification rather than tight editing.

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?

A four-parameter write tool with no annotations, no output schema, and zero schema description coverage needs more than one sentence. An agent still cannot tell what 'project' scopes, what author defaults mean, or how the handoff is formatted for the counterpart agent to parse.

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 0% and the description explains none of the four parameters — author, project, and their defaults are invisible, and 'title' vs 'message' semantics are left entirely to the schema's bare types. Only 'structured handoff message' loosely gestures at the message field.

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 (append) and resource (a structured handoff message in workspace/HANDOFFS.md), and explains the intent: inter-agent communication between the external coding agent and Forge. It doesn't explicitly differentiate itself from the sibling write_workspace_doc, which is the nearest alternative, 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?

The purpose implies when to use it (leaving a note for the other agent), but there is no explicit when/when-not guidance and no mention of write_workspace_doc as the general-purpose alternative. The agent must infer the split between this and the generic workspace writer.

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 the full burden. It does not disclose whether this mutates state, whether it invokes a model (cost/latency), whether prompts are persisted or returned only, or any rate limits — all critical for a 'synthesize' operation.

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 sentence with no filler, and the resource and scope are front-loaded. It is terse to the point of under-specification, 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?

With no annotations, no output schema, and one of two parameters undocumented, the definition leaves too much unknown: what is returned (one prompt? several variant prompts?), whether results are stored, and how errors are surfaced. For a generation tool this is inadequate.

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 0%, so the description must compensate. It references item_id only obliquely ('a specific catalog item ID') and never mentions the 'project' parameter or its 'default' default, leaving half the inputs undocumented anywhere.

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 ('Synthesize') and a specific artifact ('context-aware prompts (icon, 3D prop, variants)') scoped to a catalog item ID, which is more informative than the tool name alone. The name 'propose_assets_for' suggests asset creation while the description says prompt synthesis, leaving a small ambiguity, and no sibling is named to differentiate it from the many asset/recipe 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?

There is no statement of when to call this versus alternatives such as run_recipe, run_verb, or get_asset, nor any prerequisites. The agent must infer the workflow entirely.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool reports live status, progress, and budget spend, but does not clarify whether the operation is read-only, whether it has side effects, what permissions are required, or how frequently it can be polled.

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 efficiently conveys the tool's scope without unnecessary elaboration.

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 status-checking tool, it explains what information is returned at a high level (status, progress, budget spend). However, with no output schema and no annotations, it should also mention the optional 'project' parameter and clarify the safe, read-only nature of the operation to be fully complete.

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

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

The only parameter, 'project', has 0% schema description coverage and is not mentioned in the description at all. The agent must infer its meaning and default behavior from the parameter name alone, so the description adds no semantic value beyond the schema.

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

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

The description uses a specific verb ('Inspect') and names the resource and sub-resources clearly: live job queue status, progress, and budget spend. It does not explicitly differentiate itself from sibling tools such as get_budget, but the purpose is otherwise unmistakable.

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

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

It provides no explicit guidance on when to use this tool versus alternatives, such as get_budget or run_verb. The phrase 'Inspect live job queue status' only implies monitoring usage, leaving the agent to infer the circumstances for invoking 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?

No annotations are provided, so the description must carry the full behavioral burden. It implies a mutation and mentions "taste signals," but does not disclose persistence, reversibility, authorization needs, side effects, or what happens with rating "none".

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 definition is a single concise sentence with the core action front-loaded. It is efficient, though its brevity contributes to missing behavioral and parameter 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?

For a mutation tool with no annotations, no output schema, and 0% parameter description coverage, the description is too sparse. It establishes the basic action but leaves important operational context unaddressed.

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 0% across four parameters. The description names several rating values but omits "none" and adds no meaning for asset_id, note, or project, so it only partially compensates for the missing schema documentation.

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 gives a specific verb and resource: "Rate or swipe an asset," and names the main rating modes. It does not explicitly distinguish this from sibling tools, but the action is clear enough for an agent to identify it.

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 such as get_asset or update_game_profile. The description implies usage through the rating modes but does not state prerequisites, exclusions, or related workflows.

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 whole burden and says almost nothing behavioral: no error behavior when a doc is missing, no indication of whether the content is returned raw or parsed (notably DELIVERY_MANIFEST.json is a JSON file, contradicting the 'Markdown file' framing), no size or truncation notes. Only the read-only nature is implied by the verb.

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 front-loaded sentence with no filler; the parenthetical examples are load-bearing because they effectively document the doc_name values. Nothing here could be cut without losing information.

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

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

For a simple two-parameter read with no annotations and no output schema, the description should at least explain the project scoping, the return shape (raw text vs. parsed), and what happens on a missing file. None of that is present, so the agent is under-informed relative to the tool's 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 description coverage is 0%, so the description must compensate; it partially does for doc_name via the file-name examples, but the 'project' parameter is never mentioned at all, including its default of 'default'. An agent cannot tell how to scope the read to a non-default project from the description.

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

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

The description gives a specific verb ('Read') and a concrete resource ('shared Markdown file in the project workspace') and enumerates real file names, so an agent knows exactly what this returns. It doesn't explicitly point at the sibling it complements, write_workspace_doc, leaving the read/write contrast to be inferred from the verb.

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 reach for this versus alternatives — no mention of write_workspace_doc, get_project_bible, list_asset_requirements, or when a workspace doc is the right source versus those. The examples hint at the doc set but give no selection criteria or preconditions.

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

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

No annotations are provided, so the description carries the full disclosure burden. It hints at budget consumption ('within budget') but never states that this tool creates assets, spends credits, runs long, is irreversible, or that dry_run exists as a safe preview — all critical for an orchestration tool with side effects.

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

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

A single front-loaded sentence with a parenthetical example that earns its place by making an abstract concept concrete. No filler or redundancy.

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

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

For a no-annotation, no-output-schema, four-parameter orchestration tool with 0% schema coverage, this is far too thin. An agent cannot tell what side effects to expect, how budget is sourced or enforced, what dry_run does, or what the tool returns.

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 0%, so the description must compensate and does not. Only 'brief' gains meaning (via the example) and 'budget' is mentioned without a corresponding parameter; dry_run, project, and parent_asset_id are entirely unexplained anywhere.

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?

Specific verb ('Execute') plus resource ('high-level natural language agent brief') with an explicit end-to-end scope, and the embedded example ('Make 20 fantasy potions... then 3D the 5 best') concretely demonstrates what a brief is. The phrase 'high-level ... end to end' implicitly separates it from single-step siblings like run_verb and run_recipe.

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 example implies the intended usage context (multi-step creative pipelines), but the description never states when to choose this over run_verb, run_recipe, or a hand-composed sequence of calls, nor any exclusion or prerequisite. Usage must be inferred from the example alone.

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

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

No annotations are provided, so the description carries the full burden. 'Loops, critic checks, and budget guards' hints at long-running, potentially costly or multi-step execution, but it says nothing about side effects on assets, whether the run is reversible, how budget is consumed or enforced, or whether approval is required — critical for a tool with a dry_run flag and asset-parenting inputs.

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?

One tight sentence, front-loaded with the action and keyed identifier, with no filler. It is under-specified rather than verbose, but the structure itself is efficient.

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

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

For a 6-parameter tool with a nested inputs object, a dry-run mode, no annotations, and no output schema, the single sentence is far too thin. It neither explains parameter usage nor describes what a run returns or how failures, critic rejections, and budget exhaustion 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 description coverage is 0% across 6 parameters, and the description clarifies only that execution is keyed 'by ID' (recipe_id). The nested 'inputs' object, 'reason', 'dry_run', 'project', and 'parent_asset_ids' are completely undocumented in both schema and description, leaving an agent unable to populate them correctly.

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?

A specific verb ('Run') plus a specific resource ('declarative YAML/JSON recipe by ID') tells an agent exactly what the tool does. It hints at differentiating features (loops, critic checks, budget guards) but never names its closest siblings run_verb, create_recipe, or run_agent_brief, so sibling disambiguation is left to inference.

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 versus run_verb, run_agent_brief, or create_recipe, and no prerequisites or exclusions are stated. An agent must guess whether a recipe must exist first and when a declarative recipe is preferred over a direct verb or agent brief.

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 must carry behavioral disclosure; it only states the operation and parent-asset relationship. It omits side effects, mutation/read-only nature, cost, prerequisites, dry-run semantics, and output behavior for a multi-verb execution 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?

A single front-loaded sentence with no padding; the verb list is useful though partly redundant with the enum. It is concise rather than bloated, but the brevity leaves content gaps handled under other dimensions.

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 6-parameter dispatcher with a nested inputs object, no annotations, and no output schema, the description is materially incomplete. It identifies the core action but not the parameter semantics, side effects, or return behavior an agent needs to invoke it correctly.

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

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

Schema description coverage is only 17%, so the description needs to compensate, but it only repeats the verb enum and hints at parent_asset_ids via 'parent asset(s)'. It does not explain the inputs object, dry_run, project, reason, or required formats.

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 gives a clear verb ('Run') and resource ('Forge verb ... on parent asset(s)') and enumerates concrete verb values. It does not distinguish this dispatcher from siblings such as run_recipe or run_agent_brief, 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?

No when-to-use guidance, exclusions, or alternatives are given. An agent can infer it is for the listed Forge verbs, but nothing says when to choose this over run_recipe or other 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 exist, so the description carries the full burden; it does declare 'read-only' and 'Godot 4 primary', which is useful. However, the schema exposes consent_granted and lock_into_bible parameters that strongly suggest consent gating and a persistent write into the project bible — side effects the description never acknowledges and which sit awkwardly against the blanket 'read-only' claim. Nothing is said about scan cost, depth, or failure modes on non-Godot projects.

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 front-loaded sentence with no filler; the read-only constraint and the Godot 4 focus come first. It is dense rather than padded, though it packs several unexpanded concepts (Game Profile, evidence, confidence) into one line.

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

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

For a four-parameter tool with zero schema coverage, no annotations, and no output schema, the description is too thin: it does not explain the consent gate, the lock_into_bible write path, what a Game Profile contains, or what 'evidence & confidence' means in the result. An agent could call it, but not confidently.

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 0% across four parameters, so the description must compensate and does not. Only game_path is loosely implied by 'existing game project folder'; project, consent_granted (default true), and especially lock_into_bible (default false) are left entirely undefined in both schema and description.

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

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

States a specific verb and resource: a read-only scan of an existing game project folder that produces a Game Profile with evidence and confidence. That is clearly distinguishable from sibling reads like get_game_profile (retrieval) or update_game_profile (mutation), though the description never names those siblings to make the boundary explicit.

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 phrase 'to build a Game Profile' implies this is the entry point before get_game_profile/update_game_profile, and 'existing game project folder' implies a prerequisite. But there is no explicit when-to-use, no when-not-to-use, and no named alternative among the many profile-related 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?

With no annotations, the description carries the full burden, yet it discloses nothing about whether the undo is itself reversible, how far back history extends, what happens if no prior action exists, or whether permissions are required. Only the implicit ordering rule ('last action') is conveyed; the rest of the mutation profile is opaque.

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 front-loaded sentence with no filler. It is efficient, though the brevity edges toward under-specification rather than tight economy.

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

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

For a mutation tool with zero annotations, no output schema, and 0% parameter coverage, the description is too thin: an agent cannot tell what is restored, what happens on failure, or what the second parameter does. It leaves key decision inputs unaddressed.

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 0%, so the description must compensate. It explains activity_id only by restating it, and the 'project' parameter (defaulting to 'default') is never mentioned, leaving half the parameters undocumented in both schema and prose.

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 verb (undo) and resource (the last user or agent action), and clarifies the alternative targeting mode via activity_id. It is unambiguous on its own, but it never differentiates itself from siblings such as delete_blueprint or writeback_apply, which is the requirement for 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 guidance on when to prefer undo_action over compensating tools like delete_blueprint, nor any prerequisites, scope limits, or failure conditions. The parenthetical hint about activity_id implies an alternative invocation path but doesn't state mutual exclusivity or when to use which.

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 hints at mutation and a 'lock' into the Project Bible but never explains what locking means, whether it is reversible, whether approval is required or granted implicitly, or that approve_and_lock defaults to true — a significant behavioral gap for a write tool.

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

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

One compact sentence with the mutation and its consequence front-loaded and no filler. It is efficient, though brevity here comes partly at the cost of the missing detail noted elsewhere.

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?

A mutation tool with no annotations, no output schema, and an untyped nested object parameter needs substantially more disclosure than a single sentence. Nothing describes the return value, error behavior, or the semantics of the default-on locking.

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 0% and 'updates' is an undocumented nested object, so the description needed to compensate and does not. It vaguely says 'fields' and 'approve'/'lock' but never states the shape of the updates payload, which fields are accepted, or what the project and approve_and_lock parameters control.

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

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

States a specific verb+resource ('update and approve fields in the Game Profile') plus the downstream effect ('lock them into the Project Bible'), which clearly distinguishes it from get_game_profile and update_project_bible. The 'approve and lock' side effect is surfaced, though which fields are updatable is left open.

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

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

No explicit when-to-use guidance, no prerequisites, and no named alternatives. An agent must infer from the sibling list that get_game_profile is the read counterpart, and nothing says when to call this versus update_project_bible.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. 'Update fields' weakly implies a partial/merge update, but it does not say whether the nested 'updates' object replaces whole sub-objects, whether unmentioned fields are preserved, whether this is destructive, or what permissions are required — all critical for a mutation tool.

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

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

A single front-loaded sentence with zero padding, so it is structurally clean. The terseness, however, is under-specification rather than disciplined conciseness given 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?

A mutation tool with nested-object input, no annotations, no output schema, and no schema descriptions is left almost entirely unexplained. An agent cannot determine valid payload shape or side effects from this definition and would likely need trial and error or a preceding get_project_bible call to proceed.

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 0% and the description compensates for none of it. The 'updates' parameter is a free-form object with no declared properties, so the agent has no way to know which Project Bible fields are updatable or their expected shapes, and the 'project' parameter (which defaults to 'default') is never mentioned.

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 ('Update') and resource ('Project Bible') with the notion of field-level modification. The name pairing with the sibling get_project_bible makes the read/write split inferable, though the description itself never names the alternative.

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

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

No indication of when to use this versus get_project_bible, what prerequisites exist, or whether it should be preceded by a read. The only signal is the verb 'Update', leaving the agent to infer that this is the write counterpart.

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 of behavioral disclosure. It usefully states that existing files are never overwritten, but it does not explain whether writes are reversible, how undo_action relates, whether the operation is idempotent, or what happens to files already partially present.

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 filler. The safety-relevant parenthetical is attached directly to the action it modifies, making it easy to scan.

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 mutation tool with no annotations, no output schema, and zero schema description coverage. The description omits the preview/undo workflow, project defaulting behavior, asset ID semantics, and any notion of what the write produces, leaving too much for an agent to infer.

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 0%, so the description must compensate for both parameters, but it barely does so. 'Staged assets' hints at asset_ids and 'game project' hints at project, yet it gives no format, default behavior, or selection semantics for either 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 states a specific action and target: writing staged assets and engine glue stubs into the game project. It is clear what the tool does, but it does not differentiate itself from the sibling writeback_preview tool, which an agent might reasonably confuse with an apply step.

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 explicit guidance on when to use this tool versus writeback_preview, undo_action, or other write-oriented siblings. The only contextual hint is the parenthetical about not overwriting existing files, which describes behavior rather than usage conditions or prerequisites.

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 zero annotations, the description carries the full burden. 'Non-destructive' and 'diff preview' are genuinely useful behavioral disclosures, but it's unclear whether 'stage' persists state, whether staging is reversible, what the diff contains, or what permissions are required — all significant gaps for a tool that mutates project state.

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

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

A single front-loaded sentence with no filler. The scale-then-preview behavior is stated cleanly, though the sentence is arguably too terse given 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?

No annotations, no output schema, and 0% parameter coverage mean the description must explain a lot, and it doesn't. It omits how preview relates to writeback_apply, what happens to staged state, and what the diff return looks like.

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 0% and neither parameter is documented. The description gestures at 'assets' and 'game project', which loosely maps to asset_ids and project, but it adds no format, default, or array-semantics detail. This does not compensate for the total lack of schema descriptions.

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

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

States a specific verb+resource ('Stage assets for export') plus the distinct behavior of returning a diff preview, which implicitly separates it from writeback_apply. However, it never names the sibling it pairs with, so the differentiation requires the agent to infer the relationship from the names.

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 word 'preview' plus the sibling name writeback_apply implies a preview-then-apply workflow, but this is never stated. There is no explicit when-to-use guidance, no prerequisites, and no mention of when to skip straight to writeback_apply.

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 important side effect: editing GAME.md syncs the Project Bible. However, it omits whether this is a full overwrite versus an append/patch, whether a missing file is created, and what permissions or confirmations are required for a mutation.

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

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

Two short sentences, front-loaded with the action and scope, and the second sentence carries non-obvious side-effect information rather than filler. Slight tightening is possible but there is essentially no waste.

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

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

For a mutation tool with zero annotations, no output schema, and 0% parameter documentation, the description does not do enough: it leaves the overwrite semantics, the `project` scoping, and the mutation's safety profile entirely undefined for an agent that must write files.

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 0%, so the description must compensate for all three parameters. It gives useful examples for doc_name but says nothing about the `project` parameter (which has a 'default' value that is unexplained) or about whether `content` replaces or merges with existing file content.

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 pair (write/update) and resource (shared Markdown file in the project workspace), reinforced by concrete examples (GAME.md, ASSET_REQUIREMENTS.md). It is clearly distinct from read_workspace_doc, though the description never names the sibling explicitly.

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 by the examples of which documents live in the workspace, but there is no explicit when-to-use/when-not guidance and no mention of when to prefer update_project_bible, add_asset_requirement, or other siblings for structured content. The agent must infer routing from the file-extension framing.

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