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

With openWorldHint=true and readOnlyHint=false already declared, the description adds genuinely non-derivable context: live=true triggers configured paid calls drawn against a shared budget, and the tool 'never accepts' (i.e., it does not approve/merge the candidate). Cost and non-approval behavior are exactly the things an agent cannot infer from annotations or schema. It stops short of saying whether artifacts are written to disk.

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 the core action front-loaded and the cost/consent constraint second; nothing is wasted. It is telegraphic to the point of near under-specification, but every clause earns its place.

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

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

For a 4-parameter, open-world, cost-incurring tool with no output schema, the definition leaves real gaps: no indication of what evidence the review returns, no explanation of 'force', and no stated prerequisite for obtaining a valid change_id. The 'never accepts' note is helpful but the picture is only partially complete.

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

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

Schema coverage is only 25% (only 'workspace' documented), so the description must carry weight. It meaningfully explains 'live=true' as consent for paid calls within a shared budget — real semantics beyond a bare boolean. But 'force' and 'change_id' are left entirely undefined in both schema and description, and 'force' in particular (overwrite? bypass cache?) is a risky unknown.

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 ('Review') and resource ('an exact candidate') and enumerates what the review comprises: checks, semantic judge, and all-document language evidence. That is enough to distinguish it from architect_sdd_check or architect_language_review, though the siblings are never named and 'exact candidate' is jargon that requires the change_id parameter to decode.

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 tool evaluates a single candidate across check/judge/language dimensions. There is no explicit statement of when to prefer this over architect_language_review or architect_sdd_check, and no stated preconditions (e.g., an existing change_id from architect_sdd_propose).

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds only the notion that results include authority boundaries and coverage, which is modest extra context; it says nothing about output shape or size, which annotations cannot convey.

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 waste. It is perhaps too compressed — 'coverage' of what is never unpacked — but it is not padded or back-loaded.

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

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

With no output schema, the description carries the burden of explaining what comes back, and it offers only a rough list of categories ('host actions, coverage, authority boundaries'). That is directionally adequate for a parameterless read tool, but an agent still cannot anticipate the return structure or how to interpret 'coverage'.

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

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

The tool takes zero parameters, so the baseline of 4 applies and there is nothing for the description to compensate for. The empty schema is consistent with a parameterless introspection call.

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 'Read' and the objects 'supported host actions, coverage and authority boundaries' are present, so the general intent is a capability/introspection dump. But 'coverage' and 'authority boundaries' are abstract, and nothing distinguishes this from sibling introspection tools like architect_doctor or architect_console_url, leaving the agent to infer the exact scope.

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 the many architect_* siblings, no prerequisites, and no exclusions. An agent can guess it is a discovery call, but the description never says so explicitly or points at alternatives.

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

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context that the link is for user-side signing with a passkey and that no tool makes decisions, which goes beyond the structured safety hints.

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

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

The description is three short sentences with the core purpose front-loaded, followed by the user action and the read-only clarification. Every sentence adds relevant information without 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 simple URL-retrieval tool with rich annotations and no output schema, the description provides enough context about what the link is and what the user does with it. It is slightly incomplete on how optional parameters affect the returned link, but the core behavior is well covered.

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

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

The schema description coverage is moderate at 67%, documenting workspace and wait but leaving port undocumented. The description itself adds no parameter-level meaning, so it relies on the schema to carry the semantics.

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

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

The description clearly identifies the resource as the current workbench link used for task gates and document acceptance. It does not use an explicit verb like 'get' or 'return', but the purpose is still readily inferable and distinct from most sibling 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?

It explicitly says to hand the link to the user, who reads and signs there with a passkey. This gives clear usage context, though it does not name alternative tools or describe when not to use this one beyond the read-only note.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context that output is bounded and redacted, but does not describe permissions, limits, or return behavior beyond that.

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 single sentence is front-loaded and contains no filler; it is appropriately terse for a simple one-parameter read tool.

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

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

The tool is simple and annotations plus schema cover much of the contract, but the description does not clarify what diagnostics are returned or what "bounded" means in practice. Given no output schema, that leaves a modest completeness gap.

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

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

Schema coverage is 100%, and the single workspace parameter is fully documented in the schema. The description adds no parameter-specific meaning, so the baseline 3 is appropriate.

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

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

The description states a clear verb and resource ("Read ... diagnostics") and adds qualifiers ("bounded redacted"), but "diagnostics" remains vague about what is being diagnosed, and it does not differentiate from siblings like architect_capabilities or architect_runtime_status.

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

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

It says the tool does not modify run state, but gives no guidance on when to use this versus the many other architect_* diagnostic or status tools. No alternatives or exclusions are named.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false and non-idempotent, so the agent knows it mutates. The description adds only that no workspace file is needed; it says nothing about what gets written, where output lands, whether skills must be pre-registered, or what happens on failure — significant gaps for an 8-parameter execution tool with no output schema.

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

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

It is a single front-loaded sentence with no padding, so it is concise. But the brevity reflects under-specification rather than efficiency, and the 'UC-05' ticket reference consumes space without adding actionable meaning for the agent.

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

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

For a mutation tool with 8 undocumented parameters, no output schema, and no annotations beyond generic hints, one sentence is far from sufficient. The agent cannot determine what the required 'query' means, how a domain/task pair is supplied, or what the tool produces.

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 8 parameters and the description explains none of them. Names like 'out' vs 'out_path', 'task' vs 'task_skill', and 'domain' vs 'domain_skill' are ambiguous and completely unaddressed, so the agent gets no help distinguishing near-duplicate parameters.

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

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

The verb 'Execute' and the object 'a single Domain x Task skill pair' are stated, and 'standalone mode (UC-05)' scopes it. However, 'Domain x Task skill pair' is internal jargon the agent cannot resolve from the description, and nothing distinguishes it from the many architect_runtime_* tools that also appear to run skills.

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?

'without requiring sdd-workspace.yml' implies the selecting condition: use this when no workspace config exists. But there is no explicit contrast with architect_runtime_plan/start/next or architect_sdd_materialize, so the agent must infer the boundary from a single clause.

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 only give generic hints (readOnly=false, destructive=false, idempotent=false); the description adds real semantics: facts and live files are preserved, there is a hard two-attempt cap per document lineage, and the output is a candidate requiring review. These are behavioral facts not derivable from annotations. It stops short of saying what is written or where the candidate lands.

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

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

Three short sentences, front-loaded with the action, then invariants, then the follow-up step. No filler. Slight density from unexplained jargon but nothing extraneous.

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-style tool in a multi-step grant/workflow pipeline with no output schema and 6 of 7 parameters undocumented. The description covers intent and guardrails but leaves an agent unable to know what expected_snapshot must match, what skill to pass, or what a successful proposal 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 14% (only `workspace` documented) across 7 parameters, so the description must compensate and it does not. Six required parameters — text, skill, change_id, artifact_id, expected_snapshot — are completely unexplained; 'accepted grant' weakly implies change_id/artifact_id but expected_snapshot and operation_id remain opaque.

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: 'Propose a targeted host-authored repair under an accepted grant.' The closing 'Candidate still needs review' implicitly separates it from architect_candidate_review / architect_language_review, but the distinction is only suggested, not stated, and 'host-authored repair' is jargon an agent must already understand from the domain.

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?

Preconditions are implied ('under an accepted grant', 'at most two repair attempts per document lineage'), which tells the agent when the tool is legal, but it never names the sibling that creates the grant or the review tool to call afterwards. No explicit when-not or alternative routing.

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 annotations already declare non-read-only, open-world, non-idempotent, non-destructive behavior. The description adds meaningful context beyond that: it records findings, can send complete context externally via Jev in live mode, and explicitly has no approval authority. It still leaves the effect of force and the persistence/return behavior unstated.

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

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

The description is three compact sentences with no wasted text, and the core purpose is front-loaded before the mode details and authority boundary.

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 purpose, mode behavior, and authority limits are covered adequately for a recording tool with annotations. Yet the missing force semantics and lack of explicit sibling routing leave an agent with gaps before invoking 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 25%, so the description must compensate for undocumented parameters. It explains live mode well and hints that change_id is revision-bound, but force and change_id are not defined, and workspace meaning comes only from 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 gives a specific verb and resource: it records revision-bound, per-rule language findings. The added note that it has no qualification or approval authority helps distinguish it from review/approval-like siblings, but it does not explicitly name alternatives such as language_repair or style_check.

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 explains the live=true versus live=false modes, which is useful usage context. However, it does not say when to prefer this tool over sibling checks or repairs, so an agent must infer the routing.

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 disclose readOnly=false, destructive=false, idempotent=false, and openWorld=false. The description adds only the 'no approval authority' constraint and says nothing about the effects of cancel versus retry, whether cancellation is reversible, or what permissions are required for these mutations.

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 lists the actions first and appends the authority constraint, with no wasted preamble. It is concise, though extremely terse for a multi-action mutation tool.

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 mutation tool with no output schema and only 25% parameter description coverage, the description is too sparse. It should clarify action-specific effects, required run state, and the roles of run_id versus task_id.

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 25%, with just the workspace parameter documented in the schema. The description repeats the action verbs already represented by the enum but does not explain run_id or the optional task_id, so it fails to compensate for the low coverage.

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

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

The description names the specific control actions (pause, resume, cancel, retry) and the resource domain (scheduling), so the agent can tell this is a run-control tool rather than a starter or observer. It does not explicitly distinguish itself from siblings such as architect_runs_start or architect_runs_observe, which keeps it below 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 phrase 'no approval authority' gives one useful exclusion, but the description does not state when to use this tool versus architect_runs_start, architect_runs_observe, or the task tools. Usage is implied by the action list rather than explicitly 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?

Annotations already declare readOnly, idempotent and non-destructive, so the bar is lower; the description still adds value by stating the tool is purely passive ('starts no work') and naming the data it observes, which matters in a family containing runtime_tick and runs_start. It does not cover pagination/cursor behavior or any limits on the event stream.

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 the two data sources front-loaded and the non-effect clause trailing. Nothing 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?

There is no output schema, so the description should carry more of the return-shape and cursor burden, and it only hints at 'events and task snapshots'. For a 3-parameter observation tool with undocumented cursor semantics, it is adequate but leaves real 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 coverage is only 33% — 'workspace' is documented, but 'after' and 'database_id' are bare. The description never explains that 'after' is likely a cursor for incremental event reads, nor what 'database_id' selects, 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 a specific verb ('Read') and two concrete resources ('durable core events and task snapshots'), which is far more informative than the tool name alone. The clause 'starts no work' implicitly separates it from architect_runs_start and architect_runs_control, though it never names those siblings directly.

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

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

'Starts no work' signals that this is the passive counterpart to the runs_start/control tools, so usage is implied rather than stated. It gives no explicit condition for choosing this over architect_runtime_status or architect_sdd_read, both of which plausibly overlap as read paths.

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 this is a non-idempotent mutation (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the safety profile is covered. The description adds that the plan is 'bounded' and 'revision-bound' and that human decisions are separate, but it never explains what freezing a candidate or starting a run actually does to state. With annotations present, this partial context is adequate for a 3.

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?

It is a single front-loaded sentence with no wasted clauses, and the verb leads. However, the terseness leaves key concepts unexplained, so it is efficient but arguably under-specified rather than optimally structured.

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

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

For a non-idempotent mutation with four parameters, a required arbitrary-object tasks array, and no output schema, the description says almost nothing about side effects, return behavior, or what constitutes a valid task plan. It is materially incomplete for an agent to invoke this correctly.

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

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

Schema coverage is only 50%: workspace and base_change are documented in the schema, but run_id has no description and tasks is an array of unconstrained objects whose shape is critical and entirely undefined. The description does not compensate for these gaps or explain what a task object must contain.

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 'Start' and object 'core task plan' are present, but 'bounded, revision-bound' is unexplained jargon and the description does not distinguish this from sibling architect_runtime_start, which likely also starts planning. An agent sees an intent but cannot confidently pick this over the runtime sibling from the text alone.

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 architect_runtime_start or architect_runs_control, nor any prerequisites beyond the vague 'human decisions remain separate'. The agent is left to infer selection criteria from the name and 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?

Annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, but the description reads like a pure query ('what to do now ... what waits for a human') and never discloses what the tool actually changes, whether it mutates run state, or whether repeated calls advance anything. With a non-read-only, non-idempotent tool, that side effect is exactly what the description needed to surface.

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?

It is short, but it is a single colon-fragment with no main clause and no front-loaded statement of what the tool is. Brevity here comes from under-specification rather than from efficient 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?

No output schema exists, so the description must carry the return contract, yet it only gestures at two vague shapes ('jobs with brief and allowed paths', 'what waits for a human') without structure, and it omits the mutation semantics that a non-read-only tool requires. For a runtime-orchestration entry point among many sibling tools, this is not enough to call it safely.

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

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

Schema description coverage is 100% (both 'run' and 'workspace' have descriptions), so the schema carries the parameter burden and 3 is the baseline. The description adds nothing about how workspace or run selection affects the returned jobs, so no credit above baseline.

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

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

The description is a sentence fragment ('What to do now: jobs to execute ... and what waits for a human') that never states a verb+resource, never mentions the workspace or run concepts the tool operates on, and gives no hint of how it differs from siblings like architect_runtime_status, architect_runtime_plan, or architect_task_claim. An agent cannot tell from the text whether this computes the next runtime step, returns a status snapshot, or advances state.

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 / when-not-to-use guidance and no named alternative among the 28 siblings. 'What to do now' implies a planning or advisory moment, but the agent is left to infer that versus architect_runtime_plan or architect_runtime_tick.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds two non-obvious traits: the plan is 'revision-bound' and no run is created as a side effect. However, 'revision-bound' is never explained, and what the preview produces (plan shape, gate outcomes) is left vague.

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 filler and the key negative constraint placed last for emphasis. Efficient, though its brevity contributes to the gaps 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 4-parameter tool with 25% schema coverage and no output schema, the description should clarify the array parameters and what a preview returns. It names the artifacts ('plan and gates') but leaves output shape and the meaning of `only`/`tasks` to inference.

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 only 25% — just `workspace` is documented — yet the description gives no meaning for `only`, `tasks`, or `base_change`. 'Revision-bound' faintly gestures at `base_change` but never explains it, so the three undocumented parameters remain opaque.

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 ('Preview') plus specific resources ('task plan and gates'), and it explicitly distinguishes itself from the run-creating sibling by stating 'without creating a run'. It stops short of naming architect_runtime_start directly, but an agent can infer the boundary.

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

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

The phrase 'without creating a run' implies the dry-run/validation use case versus architect_runtime_start, but no alternative is named and no condition for choosing preview over actually starting a run is spelled out. Usage is implied rather than 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?

Annotations already disclose that this is not read-only, not idempotent, and non-destructive; the description adds that it 'carries no authority' and that an unapproved wait simply waits again. That is meaningful behavioral context. It still does not explain what changes on a successful approved recheck, why repeated calls are non-idempotent, or what side effects occur.

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 only two sentences and is front-loaded with the action. Both sentences carry information, though the second sentence is terse to the point of being cryptic rather than fully explanatory.

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

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

For a non-idempotent runtime-state operation with no output schema and many closely named runtime siblings, the description is too thin. It does not explain what a 'ledger' is, what rechecking actually changes, or how this differs from status/next/tick calls.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no additional meaning about 'run' or 'workspace' beyond that, which fits the baseline of 3 when the schema carries parameter semantics.

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

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

The description gives a rough verb and object ('Re-read the ledgers') plus a timing condition ('after a human decided'), so the agent can infer a refresh/recheck action. But 'ledgers' is unexplained jargon, and the description does not distinguish this from runtime_status, runtime_next, or runtime_tick. The purpose is only partially clear.

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

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

It says to use this after a human decided, which is a useful temporal cue. However, it gives no explicit alternative or exclusion: an agent cannot tell from the description whether to call runtime_status, runtime_next, or runtime_tick instead in related situations.

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 establish read-only, idempotent, non-destructive behavior. The description adds a useful scoping detail by saying it reads the current core task summary and that document acceptance is separate, but it does not describe output or limits.

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

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

The description is a short, front-loaded sentence with no wasted words. Its concision is appropriate, though it could invest slightly more text in clarifying the scorecard concept.

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 tool with no output schema, the description is minimally adequate. It does not clarify what the scorecard returns or how it relates to sibling runtime status tools.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description adds no additional meaning about the workspace or run parameters 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 has a specific verb, 'Read', and a resource, 'current core task summary', but it never explains what a 'scorecard' is despite the tool name. It also does not distinguish the tool from runtime status or next siblings.

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

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

The only usage guidance is the caveat that document acceptance is separate. There is no indication of when to use this scorecard versus runtime_status, runtime_next, or other runtime tools.

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

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

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description does not need to restate the safety profile. It adds useful context by describing the returned information and equating it to `skills status --json`, though it does not explain error behavior or exact return structure.

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 compact and front-loads the core purpose. The parenthetical '(pack, price, store)' is slightly cryptic, and the second sentence relies on an external CLI reference, but there is little wasted wording.

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 tool with one parameter, rich annotations, and no output schema, the description provides an adequate overview of the returned skill-slot information. It relies on the external `skills status --json` shape for exact return values, which is helpful but not fully self-contained.

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 required parameter, and schema description coverage is 100%, so the schema already fully documents the workspace parameter. The description does not add any meaning beyond what the schema provides, which warrants the baseline score.

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

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

The description identifies a specific resource, the workspace's skill slots, and states what information is returned: filled slots, empty slots, what fills empty ones, and install guidance. It is clear enough to distinguish this from general runtime status siblings, though it lacks an explicit verb and does not directly contrast itself with alternatives.

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 does not state when to use this tool versus sibling runtime tools such as architect_runtime_status or architect_runtime_plan. The reference to `skills status --json` implies a status-style query, but there is no explicit usage guidance or exclusion criteria.

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 annotations already disclose that this is a non-destructive, non-idempotent mutation, so the safety profile is partly covered. The description adds the executor role and a vague return note ("Returns what waits"), but it does not clarify side effects, blocking behavior, or what the returned "waits" actually represent.

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 very short and front-loads the core action. The second sentence, "Returns what waits," is ambiguous and earns less of its place, but the overall structure avoids 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?

There is no output schema, so the description should explain the return value, but "Returns what waits" is too vague for an agent to understand what starts, what is returned, or how to interpret the result. For a runtime-start tool with complex sibling orchestration tools, this leaves a significant gap.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (workspace and only). The description adds no parameter-specific meaning beyond what the schema provides, which matches the baseline of 3 when structured fields carry the parameter 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 ("Start a run") and adds the execution mode ("harness mode: the host agent is the executor"). It is clear what the tool does, but it does not differentiate itself from nearby siblings such as architect_runs_start.

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 "harness mode: the host agent is the executor" implies the tool should be used when the host agent itself will execute the run, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. Usage is only indirectly 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 read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered by structured data. The description's only added value is enumerating the three report sections (run state, agent lifecycle, pending waits), which is useful because no output schema exists. It says nothing about scope of scanning, cost, or freshness of the data.

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 clause with zero filler, and the highest-value item (run state) is front-loaded. The extreme terseness edges into 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?

For a read-only status reporter with no output schema, the description does list the three result sections, which is the minimum an agent needs to know what comes back. However, terms like 'pending wait' and 'lifecycle state' are never defined, and the omission of a verb leaves the operation model implicit.

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

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

Schema description coverage is 100%: both 'run' (defaults to latest) and 'workspace' (root holding sdd-workspace.yml) are documented in the schema. The description adds no parameter meaning beyond that, so baseline 3 applies.

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

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

The description names the resource set (run state, per-agent lifecycle state, pending waits) but is a noun fragment with no verb, so it reads as a content list rather than an action. It doesn't distinguish itself from close siblings such as architect_runs_observe or architect_runtime_plan, which an agent would likely 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?

There is no guidance on when to call this versus the many runtime siblings (architect_runtime_plan, architect_runtime_next, architect_runtime_tick, architect_runs_observe). No prerequisites, no exclusions, no alternative routing.

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, idempotentHint=false, and openWorldHint=false, so the safety profile is partly covered. The description adds only that it continues expired notify waits; it does not disclose what state changes, whether notifications are emitted, or what happens when no waits have expired.

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?

It is a single front-loaded sentence with zero filler, and every word is doing work. It is arguably too terse for the opaque domain term, but structurally there is no wasted text.

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

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

For a mutation tool with many runtime siblings, key context is missing: what a 'tick' actually does, what side effects occur, and how it relates to architect_runtime_next or architect_runtime_recheck. Annotations and full schema coverage help, but the core operational concept remains 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 100%; both 'workspace' and the optional 'run' are fully documented in the schema. The description adds no syntax, format, or meaning beyond those structured fields, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Continue') and resource ('notify waits whose deadline passed'), but 'notify wait' is unexplained jargon and the description never relates it to the architect_runtime_* sibling family (next, recheck, status). An agent can infer it resumes expired waits, but cannot confidently distinguish it from related runtime 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 explicit when-to-use, prerequisite, or alternative named. The 'deadline passed' condition describes the waits rather than telling the agent when it should call this tool versus architect_runtime_next or architect_runtime_recheck. Only a weak implication of usage is present.

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?

readOnlyHint, idempotentHint and destructiveHint=false already declare the safety profile, so the description's 'without accepting or changing state' is largely restatement, though 'accepting' adds useful nuance that nothing is committed. It says nothing about what happens if no sdd-workspace.yml exists, whether checks are recomputed or cached, or how failures are surfaced.

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, no filler, with the read-only constraint in the trailing clause. It is efficient but the front-loaded portion is the vague part, and the informative 'without accepting' qualifier is buried at the end.

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 checker with no output schema, the description should convey what comes back (pass/fail, findings, freshness verdicts), and it only gestures at that via three abstract nouns. Combined with the undocumented change_id, an agent knows roughly the intent but not the expected return or the optional-parameter behavior.

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 50%: workspace is documented, but change_id has no description anywhere. The description never mentions change_id, so it adds no meaning about whether it scopes the checks to a specific change or is optional for a workspace-wide check.

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 is 'read' and the objects are named loosely as 'deterministic checks, regression readiness and freshness', but the underlying resource is never pinned down (a check result? a readiness report?). With siblings like architect_sdd_prepare_check, architect_style_check and architect_sdd_read present, the description gives no basis for telling them apart.

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 'without accepting or changing state' hints that this is a non-committal inspection pass, but no alternative is named and no condition is given for choosing it over architect_sdd_prepare_check or architect_sdd_read. The agent must infer the workflow position from the tool name 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is partly covered; the description usefully adds that the write target is a specific file. It does not say whether an existing harvest.json is overwritten, merged, or appended, nor what the 'audit' mode changes — the gaps that matter most given idempotentHint=false.

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 the deliverable path, with the parameter hint folded in rather than padded. Nothing wasted, though the single-sentence form leaves no room for the missing behavioral details.

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

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

For a non-idempotent write tool with no output schema and a 33%-documented schema, the description omits overwrite semantics, the meaning of 'audit', and any relationship to the surrounding SDD pipeline. The result file's structure is only hinted at through a list of categories.

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 33%, so the description must carry the load, and it does not. It explains the 'sources' omission behavior but leaves 'audit' (what does auditing add?) and the expected shape/format of sources entries undocumented in both places.

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 ('Extract') and enumerates the resource categories (requirements, ADRs, scenarios, conflict records) plus the exact output artifact path '.architect-build/harvest.json'. It never names a sibling, so an agent cannot tell from the text alone why this differs from architect_sdd_read or architect_sdd_prepare_check.

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

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

The parenthetical 'auto-discovers sources when omitted' implies when the sources parameter can be skipped, which is real usage guidance. But there is no statement of when to choose this over architect_sdd_read or architect_sdd_prepare_check, and no prerequisites (e.g., sdd-workspace.yml must exist, likely via architect_sdd_init).

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 this is a write operation that is neither idempotent nor destructive, which covers the safety profile. The description adds that presets and existing source files are supported, but it omits critical behavioral details such as what happens if a workspace already exists (important given idempotentHint=false) or what artifacts get created.

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 leads with the verb and resource, with the parenthetical adding relevant scope. No wasted words, though it is arguably too terse for a six-parameter tool.

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

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

For a tool with six parameters, two enums, low schema coverage, and no output schema, one sentence is insufficient. The agent lacks guidance on profile values, reviewer semantics, workspace_id, and re-initialization behavior, leaving meaningful gaps before a confident 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 coverage is only 17%, so the description must compensate but largely does not. It repeats the preset enum values without explaining them, gestures at 'existing source files' without clarifying the allow_existing_sources boolean, and says nothing about profile, reviewer, or workspace_id.

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 ('Initialize a new SDD workspace') plus the target directory, which is clear enough to distinguish it from siblings like architect_sdd_read or architect_sdd_materialize. It does not explicitly contrast with those siblings, keeping it below 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 word 'Initialize' implies this is the first step in an SDD workflow, and the parenthetical hints at supported configurations. However, there is no explicit when-to-use guidance, no prerequisites, and no mention of when to prefer another tool or what to do if a workspace already exists.

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 a non-read-only, non-idempotent, non-destructive write, so the safety bar is lower, but the description adds no context beyond that: it does not say whether existing files are overwritten or merged, whether the run is resumable, what 'frozen basis_digest' means operationally, or what the caller gets back. 'Frozen' hints at immutability but is never explained, so the write semantics remain 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?

One front-loaded sentence with no filler, which is structurally sound, but it is essentially a dense noun phrase of undefined terms rather than a self-contained explanation. Brevity here reflects underspecification more than 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?

This is a high-complexity tool: eight parameters, a nested object, two enums, no output schema, and non-idempotent write behavior. A single jargon sentence cannot convey what the agent needs to select and invoke it correctly, especially the profiles/presets and stub-only mode.

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 13% (just 'workspace'), leaving seven parameters undocumented, including two enums (preset, profile), a nested 'harvest' object, sources, reviewer, stub_only, and workspace_id. The description mentions none of them, 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?

The description names a concrete verb ('Materialize') and lists artifacts produced (document tree, ledgers, wave micro-batches, basis_digest), which is more than a name restatement. However, the terminology is internal jargon and there is no differentiation from adjacent siblings like architect_sdd_init or architect_sdd_propose, so an agent cannot predict the boundary between this and those 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 tool, what prerequisites exist (e.g. whether architect_sdd_init must run first), or which alternative to prefer. The verb implies a scaffold-generation step, but that is inference, not 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, idempotentHint=false and destructiveHint=false; the description usefully adds that it mutates artifacts by stripping thinking blocks, tightening lines, repairing frontmatter and freezing a digest, which tells the agent files are rewritten in place. It does not disclose that the frozen digest may be invalidated by reruns (consistent with idempotentHint=false) nor whether partial failures leave artifacts in an inconsistent 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 the action verb first and a compact parenthetical enumeration; every clause carries information. Slightly dense, 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?

This is a mutating multi-step pipeline with no output schema and incomplete parameter coverage, yet the description says nothing about return values, whether it reports per-step results, error behavior, or ordering relative to sibling stages — despite the tool name also implying a 'check' phase the description never mentions.

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 only 20% (only `workspace` is described), so the description must compensate. It partially does: the named steps map plausibly onto `tighten`, `style_fix` and `stamp`, but `pad_to_min` is never explained, and it is unclear whether 'strip thinking', 'repair frontmatter' and 'freeze digest' are unconditional or controlled by any flag.

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 ('Run') and resource ('built-in post-processing pipeline') and enumerates the six concrete steps it performs, so an agent knows exactly what work happens. It does not differentiate itself from plausible siblings such as architect_style_check, architect_language_repair or architect_sdd_check, which overlap with the 'style fix' and 'repair frontmatter' steps.

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

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

No guidance on when to call this versus the many sibling check/repair tools, no stated preconditions (e.g. that a prior extract/materialize stage produced the artifacts), and no mention of what to do if the pipeline fails. The agent must infer sequencing 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?

The annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false. The description adds meaningful context by saying the candidate is isolated and that the tool 'Never accepts,' clarifying that it does not commit changes. It still omits failure modes, permission expectations, and whether retries are safe, so the added value is moderate rather than rich.

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

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

The description is two short sentences, front-loaded with the action and qualified by the key constraint. There is no filler, though the brevity contributes to gaps captured in 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 tool with six parameters, only 17% schema description coverage, and no output schema, the description is too sparse. It does not explain the structure of the required 'operations' array, the role of 'base_change' or 'operation_id,' or what the tool returns, leaving significant gaps 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 only 17%, so the description must compensate. It hints at the 'skill' and 'expected_snapshot' parameters through 'configured skill grant' and 'expected live snapshot,' but it leaves critical required parameters such as 'operations' undocumented and does not explain 'base_change' or 'operation_id.' This is insufficient for a six-parameter tool with low schema coverage.

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

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

The description states a specific verb and resource with qualifiers: 'Create an isolated candidate' under a 'configured skill grant and expected live snapshot.' However, terms like 'candidate,' 'skill grant,' and 'isolated' are not explained, and the description does not explicitly distinguish this proposal tool from siblings such as architect_sdd_prepare_check, architect_sdd_materialize, or architect_candidate_review.

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 'Never accepts' implies this is for proposing rather than committing changes, but there is no explicit when-to-use guidance, no named alternatives, and no explanation of when an agent should choose this over sibling tools like architect_sdd_prepare_check or architect_candidate_review.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the read is bounded and returns an exact revision, but it does not explain pagination behavior, candidate-vs-live precedence, or error behavior for missing change_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?

The description is a single front-loaded sentence with no wasted words. It is efficient, though its dense jargon ('registered artifact slice', 'exact live or candidate revision') trades clarity for brevity.

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

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

For a tool with five parameters, only 20% schema description coverage, and no output schema, one sentence is not enough. It leaves the agent without clear semantics for candidate revision selection, pagination, or required artifact_id beyond the schema name.

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 20%, with just workspace documented. The description only indirectly suggests limit/offset through 'bounded' and change_id through 'candidate revision'; it does not define artifact_id, change_id semantics, limit/offset defaults, or pagination behavior.

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

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

Names a specific verb and resource: read an artifact slice. The qualifiers 'bounded' and 'exact live or candidate revision' clarify the scope, but the description does not explicitly distinguish this tool from siblings such as architect_sdd_extract, architect_sdd_materialize, or architect_sdd_check.

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 no explicit guidance on when to use this tool versus alternatives, nor when to supply change_id versus read the live revision. The phrase 'live or candidate revision' hints at a branch, but the agent must infer the 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value: it discloses that incomplete rules remain 'unknown' rather than failing, and that the tool carries no approval authority — both material to interpreting results.

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 compact sentences with the core scope front-loaded and zero filler. It is terse to the point of being cryptic in places, but every clause 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 read-only check tool with no output schema, the description should convey what the check returns (violations, pass/fail, unknown markers). It gestures at this with 'incomplete rules stay unknown' but leaves the result shape and the two undocumented identifiers largely 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 coverage is only 33%, with just 'workspace' documented, so the description must carry artifact_id and change_id. It alludes to 'one exact registered revision' but never explains what artifact_id identifies, what change_id adds, or that change_id is optional.

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 (Check) and resource (declared STE-inspired rule subset) scoped to a single registered revision. It distinguishes itself from a general sdd_check by emphasizing 'STE-inspired subset' and disclaims approval authority, though it never names the sibling it should be chosen over.

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 and no routing against siblings like architect_sdd_check, architect_sdd_prepare_check, or architect_language_review, all of which overlap in the check/review space. Only weak implied constraints ('one exact registered revision') hint at 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?

Annotations already declare a mutating (readOnlyHint=false), non-idempotent, non-destructive operation, so the description need not repeat that. It does add real context: only "ready" tasks can be claimed and the call acquires a private attempt lease, implying ownership semantics. However, it omits what happens on contention, lease expiry, or whether a failed claim is an error.

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 waste, which is good, but it is terse to the point of under-specification given the coordination semantics involved. Efficiency here comes partly at the expense of completeness.

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 state-mutating coordination tool with no output schema and no description of return values (lease handle? attempt ID?), lease duration, or failure modes. Combined with undocumented run_id and a dense sibling set, the definition leaves too much for an agent to guess.

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 only 33%: workspace is documented in-schema, but run_id and task_id have no descriptions anywhere. The description's mention of "task" weakly maps to task_id but gives no format, and run_id is completely unaddressed, so the description 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?

Specific verb "claim" plus two concrete resources (core task and private attempt lease). It distinguishes the tool reasonably from siblings like architect_task_heartbeat or architect_task_complete, though domain terms "ready core task" and "attempt lease" are never defined.

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 statement of when to call this versus alternatives such as architect_runtime_next or architect_task_heartbeat, and no mention of preconditions beyond the word "ready." The agent must infer the claim/execute/heartbeat workflow entirely from sibling names.

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 the mutation profile (readOnly=false, destructive=false, non-idempotent), so the safety story is partially covered. The description adds one useful boundary ('never accepts or publishes documents'), but says nothing about what the required lease_token implies, whether operations are applied atomically, or what happens on lease expiry.

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, front-loaded with the action and followed by the key scope restriction. 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 five-parameter, all-required mutation tool with an undocumented nested operations array and no output schema, the description is far too thin. An agent cannot determine what shape the operations must take or what the lease_token governs.

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 only 20%, so the description must carry parameter meaning and it does not. run_id, task_id, lease_token, and the opaque 'operations' array of objects are entirely undocumented 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?

The description says 'submit scoped proposal operations,' but the tool is named architect_task_complete, and the relationship between 'completing a task' and 'submitting proposal operations' is never explained. It does not differentiate this tool from siblings like architect_sdd_propose, leaving the actual purpose ambiguous.

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 is given of when to call this versus architect_sdd_propose, architect_task_claim, or architect_task_heartbeat. There are no preconditions, no exclusions, and no alternative named.

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

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

Annotations declare this is not read-only, not idempotent, and not destructive, but the description adds nothing: it does not say whether a mismatched or expired lease_token is an error, what the renewal window is, or whether a failed renewal invalidates the attempt. For a non-idempotent mutation with no annotation detail, this is a significant gap.

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

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

A single six-word sentence is maximally front-loaded, but here brevity reflects under-specification rather than economy — nothing in the sentence earns its place beyond restating the 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?

With four required parameters, no output schema, sparse annotations, and heavy interaction with the claim/complete/runtime_tick siblings, the description needs lifecycle and failure semantics. It provides none, leaving the agent unable to call it correctly beyond guessing.

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 25% — only workspace is documented. The description implies lease_token must be the currently valid token, which adds a little meaning, but run_id, task_id, and lease_token remain undocumented 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?

The verb "Renew" plus the resource "active attempt lease" identifies the operation, so an agent can tell it is not architect_task_claim or architect_task_complete. However, "exact" is unexplained jargon and the description never says what a lease is, what renewing extends, or how this fits the claim/complete lifecycle.

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 call this versus architect_task_claim or architect_task_complete, no required cadence (heartbeat interval), and no statement about what to do if renewal fails or the lease has lapsed. The agent must infer the entire calling context from the name.

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