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

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Does not change engine settings' largely restates the safety profile. The phrase 'actual capability evidence' vs 'configured engine version' hints the return contrasts declared configuration against observed runtime, which is modest added context but no detail on format or failure modes.

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 with no waste, and the core action is front-loaded ahead of the clarifying non-mutation note.

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-param read-only probe with no output schema, the description adequately covers what it reads and reassures it is non-mutating. It could say more about what the capability evidence contains, but nothing critical to calling 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The empty schema means there is nothing for the description to disambiguate.

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 (Read) and resource (configured engine version and actual capability evidence), so the agent knows this returns environment/capability data. It is reasonably distinct from the project/preview siblings, though it does not explicitly contrast itself with we_project_inspect.

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 – the 'probe the environment' framing suggests a pre-flight check, and 'Does not change engine settings' hints it is safe to call anytime, but there is no explicit when-to-use or when-to-prefer-a-sibling guidance.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=false and destructiveHint=false. The description adds real context beyond them: the operation is scoped to windows created by this server session and deliberately omits global stop/kill semantics, which tells the agent about blast radius. It does not say whether closing is idempotent or what happens on an unknown id.

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, no filler, with the scope constraint front-loaded rather than 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?

For a single-parameter teardown tool with annotations and no output schema, the description covers the essential scope restriction. Minor gaps remain: no mention of idempotency or behavior for an invalid/already-closed previewId.

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 previewId, its UUID format, or where the id comes from (presumably we_preview_open). The name plus the UUID pattern in the schema make it inferable, so this is adequate but adds nothing beyond structured data.

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 ("Close") and resource ("a window created by this server session"), which is specific enough to separate it from we_preview_open and from any global kill sibling. It does not name an alternative tool, so it falls short of the 5 bar.

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 global stop/kill commands" is an exclusion rather than a when-to-use rule; the agent can infer it is for tearing down a preview it opened, but no explicit trigger or alternative tool is named. Implied usage only.

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

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

Annotations declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, so the safety profile is already given. The description adds that events are 'bounded', frames are PNG, and that reload re-reads a fixed snapshot; it does not explain auth requirements, rate limits, or how reload differs from re-calling observe.

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 with no filler, and the core read purpose is front-loaded ahead of the reload/open-a-new-preview guidance. Dense but each clause carries 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?

With five parameters at 0% schema coverage and no output schema, the description should carry more burden than it does. It omits parameter meanings, pagination/streaming semantics (afterCursor, intervalMs), and what the returned diagnostics/frames look 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 description coverage is 0% for all five parameters. The description only loosely gestures at 'reload' and 'bounded' events, leaving previewId, count, intervalMs, and afterCursor (pagination) entirely undocumented in both schema and prose, so it fails 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 specific verbs and resources: reads CEF target diagnostics, bounded console/network events, and PNG frames. It partially differentiates from siblings by contrasting with 'open a new preview for newer source revisions' (we_preview_open), though it never mentions we_preview_close or the other preview 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?

Gives one useful routing hint: use 'reload' to refresh the fixed preview snapshot, and open a new preview for newer source revisions. However it does not state the general when-to-use context versus the other eleven siblings, nor prerequisites, so guidance is only partially 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this creates something non-destructively. The description adds real value by disclosing that results may be 'evidence or explicit unverified state' and that it 'never changes the desktop wallpaper'. It omits auth requirements and what a failed launch looks like, so it stops short of 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?

Two sentences, front-loaded with the action verb, and no filler padding. The trailing 'never changes the desktop wallpaper' clause is idiosyncratic and slightly wasteful, keeping it from a 5.

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 3-parameter creation tool with no output schema and zero schema descriptions, the definition leaves too much unsaid: parameter meaning, resolution constraints, and error behavior. The behavioral note is helpful but the definition is not complete enough for an agent to invoke 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?

Schema coverage is 0% and the description adds no information about width, height, or projectId — no format, units, defaults, or constraints. 'Immutable source snapshot' hints vaguely at the project reference but gives no actionable mapping, so the description fails to compensate for the undocumented 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 clear verb+resource: 'Launch ... engine window from an immutable source snapshot'. An agent can tell this is the counterpart to we_preview_close. However, 'official engine window' is jargon-heavy, and the description never names the sibling or scopes itself against we_preview_observe/we_preview_set_properties.

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 or when-not guidance, no mention of prerequisites (e.g. requires a valid projectId), and no routing to alternatives such as we_preview_close for teardown. The phrase 'from an immutable source snapshot' implies a condition loosely but is not framed as usage guidance.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the agent knows this is a mutating but non-destructive local operation. The description adds value beyond that: changes are scoped to an owned preview window, values are validated before being applied, and the source/default configuration is left untouched — key behavioral facts the annotations do not convey. Error behavior and any permission requirements remain unstated.

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

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

A single sentence with the action front-loaded and no filler; the scope qualifier and the source-unchanged caveat each earn their place. Nothing is repeated from the schema or annotations.

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 mutation tool with a nested object parameter, no output schema, and no parameter documentation in the schema, the description covers what happens and the blast radius but omits validation failure behavior, whether values are merged or replaced, and what a successful call returns. Adequate but with clear 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 0%, so the description must carry the burden for both required parameters. It partially does: 'named properties only' signals a key/value partial update that leaves unspecified properties alone, and 'owned preview window' implies previewId must reference a preview the caller owns. It adds no detail on value types, the 4096-char string cap, or UUID format.

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 concrete action (validate and set named properties) on a specific resource (an owned preview window), which separates it from the preview lifecycle siblings like we_preview_open/close/observe. It does not, however, explicitly name an alternative tool for the same conceptual task (e.g., we_project_apply), so differentiation is implied 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?

'Only to an owned preview window' and 'source defaults stay unchanged' give a usage constraint and a non-persistence caveat, which is useful context. There is no explicit when-to-use/when-not-to-use guidance or pointer to a sibling for making real, persistent changes, so the agent must infer the boundary.

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

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

The description goes meaningfully beyond the annotations by disclosing the write pipeline: candidate validation first, then a persistent checkpoint before any mutation, plus revision-based concurrency via expectedRevision. The mention of 'deletions' sits in mild tension with destructiveHint=false, but the description itself supplies the mitigating mechanism (a persistent checkpoint, supported by the we_project_restore sibling), so this reads as author intent rather than a contradiction.

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

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

Two dense sentences with the action front-loaded and zero filler; the second sentence adds behavior rather than restating the first. Nothing 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 batched, mutation-capable tool with no output schema and zero schema-level descriptions, the definition covers purpose and the write pipeline but omits operationally important details: atomicity of the change batch, what error surfaces on revision mismatch, and path-containment guarantees. Adequate as a minimum viable definition, 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% across three required, non-trivial parameters, so the description must carry the load. It clarifies that paths are project-relative, content is UTF-8, a null/omitted content means deletion, and expectedRevision drives optimistic concurrency — useful but incomplete, since the 1-100 item limit, the 64-hex revision pattern, and validation-failure behavior remain undocumented.

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 and resource ('Apply project-relative UTF-8 writes/deletions') plus the governing mechanism ('using expectedRevision'), so the operation is unambiguous. It does not, however, distinguish itself from near-neighbors like we_project_validate, we_publish_prepare, or we_project_restore, which is what separates a 4 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 when-to-use guidance, no statement of prerequisites, and no named alternative. An agent must infer from the sibling list that this is the tool that actually commits changes while we_project_validate only checks them and we_project_restore rolls back.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered externally. The description adds genuine side-effect context beyond that: copies strip workshopid, and scene copies remain unverified — meaningful post-conditions an agent would not otherwise know.

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, front-loaded sentences with no filler; the primary action leads and the copy caveats follow. It is appropriately sized for the amount of information it does convey.

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 return values need not be described, and annotations cover safety. However, for a 5-parameter mutation with 0% schema description coverage and a nested object, the description omits how to choose between templateId and sourceProjectId and what name/title/properties control — a real gap for correct invocation.

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 there are 5 parameters including a nested free-form 'properties' object, so the description must carry the load. It only obliquely touches the source (sourceProjectId) and template ('Web starfield' ~ templateId), leaving 'name' vs 'title' and the entire 'properties' bag 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?

States a specific verb (Create/Create offline) plus the resource (Web starfield project) and a second mode (copy an existing source), which distinguishes it from sibling read/apply/validate tools. The only weakness is jargon ('offline Web starfield', 'managed workspace') that isn't defined, but the core action 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?

It implicitly signals two modes (new creation vs copying an existing source) but never states when to pick one over the other or how that maps to inputs. No alternatives or siblings are named, and no prerequisites are given, so usage must be inferred from the schema rather than the text.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: the inventory is 'bounded' and source text is capped at 256 KiB, which tells the agent output size is limited and truncation is possible. It stops short of saying what happens when the cap or inventory bound is hit.

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 or restated tool name, and the verb leads the sentence. The enumerated list of returned artifacts is dense but readable; a slightly longer form clarifying the projectId input would not hurt given the schema is undocumented.

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 usefully enumerates what comes back (revision, manifest, inventory, source text), compensating somewhat for that gap. But it never explains the required projectId, says nothing about inventory scope or pagination, and gives no error or truncation behavior, leaving real gaps for a tool with an undocumented 2-parameter schema.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It partially does this for readFiles by describing 'up to 256 KiB of requested source text,' clarifying content and volume. However, the required projectId parameter receives no explanation at all, and the 256 KiB cap is described as applying to 'source text' without clarifying whether it is per-file or across the whole request.

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 (Return) and enumerates the resources returned: content revision, manifest, file inventory, and optionally source text. This is far more concrete than a tautology like 'inspect a project.' It does not, however, differentiate itself from read-ish siblings such as we_project_list or we_project_validate, so the agent must infer which project-read tool to pick.

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 when-to-use guidance, no mention of prerequisites, and no reference to any alternative tool. The phrase 'optionally ... requested source text' hints that the readFiles parameter can pull file contents, but the agent is given no condition for choosing this tool over we_project_list or we_project_validate.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety posture is covered by structured data. The description reinforces this with 'external sources are read-only' and adds the configured-roots scoping limit, which is useful context, but says nothing about result size, pagination, or ordering 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?

A single compact sentence with no filler, and the scoping constraint is front-loaded. It is arguably under-specified rather than wasteful, so it does not reach 5, but there is no sentence that fails to earn 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 list tool with three undocumented parameters and no output schema, the description should at minimum say what is returned and how filtering/paging works. It covers only scope and read-only status, leaving an agent unable to infer the shape of results or the effect of the type/limit/offset options.

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 all three parameters, so the description carries the full burden for 'type', 'limit' and 'offset'. It mentions none of them, leaving the enum values (web/scene/video), the 1-100 limit cap, and pagination semantics completely undocumented outside the raw 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 verb 'discover' plus the resource 'projects' makes the operation identifiable, and 'only beneath configured roots' adds a scope qualifier that an agent can act on. It does not explicitly distinguish itself from siblings like we_project_inspect (single-project detail) or we_project_create, so it stops short of the 5 benchmark.

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 'only beneath configured roots' is a real usage boundary — it implies the tool will not enumerate projects outside those roots — but no alternative tool is named or contrasted, and no condition for preferring this over we_project_inspect is given. Usage is therefore implied rather than 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false. The description adds meaningful context beyond that: the restore refuses concurrent changes (optimistic concurrency) and creates another checkpoint for undo, clarifying reversibility and failure 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 short sentences with zero waste. The core action is front-loaded, followed immediately by the most important behavioral traits (concurrency refusal and undo checkpoint).

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 3-parameter mutation tool with no output schema, the annotations cover the safety profile and the description covers concurrency and reversibility. It omits explicit parameter explanations, but no essential calling information appears missing given the structured data available.

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 all three required parameters. The description hints that 'checkpoint' maps to checkpointId and that concurrency refusal relates to expectedRevision, but it does not explicitly document any parameter's role, format, or constraints, leaving most semantics to be inferred.

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 ('Restore') and resource ('checkpoint belonging to this managed project'), making the core operation immediately clear. It does not explicitly differentiate itself from siblings like we_project_apply or we_project_validate, but no sibling shares its restore-checkpoint purpose.

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 purpose: restore a checkpoint for this project. The phrase 'refusing concurrent changes' signals a precondition (no concurrent edits), but the description never names alternatives or states when not to use this tool, leaving routing 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?

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuine value on top by setting expectations about result limits: it reports remaining runtime/editor checks "without claiming engine validation." That caveat prevents an agent from over-trusting a pass result. It does not describe output shape, but annotations carry the safety burden here.

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 with zero filler, and the positive scope (what is checked) is front-loaded before the negative scope (what is not claimed). Efficient, though the second sentence is slightly compressed in phrasing.

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 should arguably say what the agent receives (pass/fail, list of issues, severity), and it only gestures at this with "Reports remaining runtime/editor checks." It is adequate for a single-param read tool but leaves the result contract underspecified.

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

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

There is one parameter, projectId, with 0% schema description coverage, so the description would need to compensate and it does not — it never mentions projectId or its format. However, the parameter is self-evident for a project-scoped tool, so the gap is minor rather than damaging.

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 concrete verb ("Check") and scoped resources (metadata, static HTML/CSS references), then bounds the scope by disclaiming engine validation. This lets an agent distinguish it from we_project_inspect or we_environment_probe, though it never names a 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 only implied: the mention of "remaining runtime/editor checks" hints that other tools cover those, but there is no explicit when-to-use, prerequisite, or ordering guidance (e.g., after we_project_apply). An agent must infer the workflow.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds a genuinely useful scope boundary (it writes staging artifacts but performs no asset packing and no network upload), yet it says nothing about where staging output lands, whether repeated calls overwrite prior staging, or what the 'preparation report' contains.

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 the action first and the scope exclusion second; there is no filler. The terse semicolon clause is slightly cryptic, which keeps it short of a 5.

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 tool with no output schema, the description is minimally adequate: it frames the operation and its boundary, and the mention of a 'preparation report' gestures at the return value. It is incomplete on intent semantics, prerequisites (e.g. must a project exist first) and where staged sources are written.

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 contributes no parameter meaning at all: neither projectId nor the new/update intent enum is explained, nor does it state what 'update' changes versus 'new'. The low coverage means the description should compensate and it does not.

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 verb 'stage' plus the resources ('offline runtime sources and a preparation report') make the purpose concrete, and the clause about never packing native assets or uploading to Workshop draws a sharp boundary that separates it from a real publish/upload step. It stops short of naming a sibling tool, so it is clear but not fully differentiated.

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

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

There is no explicit when-to-use guidance, no stated prerequisites, and no named alternative. The negative scope ('never packs... or uploads') hints that this is a preparatory step before publishing, but the agent must infer that this is the right starting point rather than, say, we_project_apply or we_project_validate.

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