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

With no annotations, the description carries the full behavioral burden. It discloses that the answer unblocks the work order and that the options are on the question, but it omits permissions, reversibility, validation behavior, and what happens to the parked question afterward.

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-loaded: it starts with the action, then adds the workflow context and answer constraint. Every sentence contributes useful information without repetition.

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 workflow tool with no annotations and no output schema, the description covers the purpose and use case but leaves gaps around side effects and parameter format. An agent still lacks guidance on where to obtain the parked question or what the tool returns.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for both parameters by saying the question contains options and the answer should be one of them in the owner's words, but it does not clarify whether 'question' is an ID or text, nor the exact expected answer 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 specific verb and resource: 'Answer a parked question.' It clarifies the tool's role in the compile workflow, but it does not explicitly differentiate the tool from its siblings, 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?

It gives clear usage context: use this when the compile found two plausible referent sets and asked a parked question, and the answer unblocks the work order. It does not mention when not to use it or name alternatives, but the triggering condition is unambiguous.

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

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

With no annotations provided, the description carries the full burden, and it does well: it discloses that the call is idempotent by key, that retries should reuse idem_key to avoid double-filing, and that 'edit' cancels before refiling, which is a destructive side effect. It omits what happens on an invalid answer, what authorization the 'owner' requires, and what a call returns.

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

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

Three tight sentences, front-loaded with the core action and its branch semantics before the idempotency note. Every sentence adds information, and none repeats structured fields.

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 an unannotated, four-parameter mutation tool with no output schema, the description covers the state machine, the side effects of each branch, and retry safety. Remaining gaps are the return value (which may be unnecessary, since no output schema exists) and the relationship to file_work_order.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it defines the enumerated values of answer, which fill a real gap left by the untyped string enum in the schema. It also explains idem_key's retry semantics and implies amendments' role via 'edit...refile with amendments.' Only the work_order parameter is left unstated, though its meaning is clear.

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: answering a draft work order's confirmation. The three answer branches are spelled out precisely. It does not, however, distinguish this tool from the sibling file_work_order, which an agent could plausibly confuse with it.

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

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

The description explains what each answer value does (go queues, no cancels, edit cancels and refiles), which effectively guides the caller through the decision branches. But it gives no guidance on when to choose this tool over siblings like file_work_order, and no prerequisites beyond the implicit notion that the owner is the one answering.

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

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

With no annotations, the description carries the full burden. It usefully discloses non-obvious branching behavior: the tool never guesses, and returns either a draft (with the one-line confirmation and BOTH price lines) or a one-tap question. But terminology like "context packet," "node registry," and "price lines" is opaque, and it never states side effects — whether filing persists anything, is idempotent, or merely compiles a preview.

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?

Only two sentences and the routing rule is front-loaded, so nothing is buried. But the prose is dense with undefined internal jargon, which costs a reader more than the length suggests; a short gloss of "context packet" or "price lines" would have earned its space.

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-flavored tool with zero annotation coverage, no output schema, and six parameters, the description covers the branching and the intent fields but omits side effects, permissions, and the meaning of most inputs. Adequate to attempt a call correctly, not adequate to predict its consequences.

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

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

Schema coverage is 0%, so the description must compensate. It does well for the free-form `intent` object, naming spec_sentence (≤ 25 words), goal, acceptance (≥ 1 machine-checkable check) and estimate {build_verify, generate_test}. The other five parameters — request, params, region, selection, conversation — receive no explanation at all, leaving the required `request` and the ambiguous `selection`/`params` 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?

States a specific verb and resource ("File a work order") plus the inputs it consumes ("terse request plus the context packet") and the two possible outputs (a draft or a one-tap question). It never differentiates itself from siblings like confirm_work_order, which is a natural next step, so it stops short of a 5.

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

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

Gives one explicit routing rule — when two referent sets are plausible, answer with answer_question rather than re-filing — which is genuine when/when-not guidance. However it says nothing about when to call this versus confirm_work_order or propose_plan_intention, and prerequisites (context packet must exist?) are only implied.

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

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

No annotations are provided, so the description carries the full burden. 'Read' plus the content enumeration implies a safe, non-mutating fetch and tells the agent what fields come back, which is real disclosure. It says nothing about payload size/cost, latency, whether any state is marked as seen or advanced, or permissions — notable gaps for a tool that aggregates project state and conversation history.

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 verb and resource, then the payload list, then the parameter rule. No filler, and the most decision-relevant content (what you get back) comes first. The dense parenthetical enumeration is long but each item earns its place by naming a distinct returned field.

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

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

With no annotations and no output schema, the description is the sole source of contract information. It does a fair job describing the return payload, which is the harder half, but leaves three of four inputs undocumented and gives no cost or side-effect signal. For a four-parameter aggregate-read tool, that is adequate but clearly short of 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 4 optional params, so the description must compensate. It only addresses `selection` ('pass the node ids you are looking at'), leaving `params`, `region`, and `conversation` entirely undefined — an agent cannot tell what a region string looks like or what shape `conversation` objects take. The phrase 'current params' refers to returned data, not the `params` input, adding further ambiguity.

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

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

The description gives a specific verb ('Read') and resource ('the context packet for a view') and then enumerates exactly what the packet contains: referents, params, history, labels, project state, budget, vocabulary. That enumeration makes the tool distinguishable from siblings like read_night_plan or list_vocabulary, which each return a subset of this payload. The jargon ('§1.4', 'the world's own situation') costs it a point, since an agent without the spec cannot decode those phrases.

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 guidance is a parameter rule ('Pass the node ids ... omit them for the world's own situation'), which says how to call it, not when to prefer it. There is no statement about when to use this omnibus context read versus read_night_plan (budget) or list_vocabulary (vocabulary), despite clear payload overlap with both siblings. No when-not-use or exclusion is offered.

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

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

With no annotations at all, the description carries the full behavioral burden. Its noun-phrase framing signals a read operation rather than a mutation, and the 'closed, typed vocabulary' plus 'coming-soon edges' wording reveals domain semantics (statuses can be pending/incomplete). It does not state permissions, result size, pagination, or ordering, which is a meaningful gap for a zero-annotation tool.

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

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

Two compact sentences with no filler: the resource and its fields come first, then the filter scenario. The 'taste notes' and 'coming-soon edges' phrasing is domain flavor that doubles as semantic signal rather than pure padding.

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

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

For a single-optional-param read tool with no output schema, the description covers what the entries contain and what filtering yields. It falls short on the status value domain and on any hint of result shape or size, leaving an agent to discover those by calling.

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 optional parameter with 0% schema description coverage, so the description must compensate. It explains the semantics of the status filter (surface not-yet-filled edges) but never indicates the accepted values for status, so an agent cannot choose a value without trial and error.

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 the resource precisely and non-tautologically: the closed, typed vocabulary of words, along with the fields each entry carries (kinds, owners, statuses, param schemas, taste notes). The verb is only implied by the tool name, but an agent can tell this is a retrieval of vocabulary entries and that no sibling tool does the same thing.

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?

'Filter by status to see the coming-soon edges — the gaps that only a work order can close' gives one concrete usage scenario and implicitly points toward file_work_order as the follow-up. There is no explicit when-not guidance or named alternative for the unfiltered call, so usage is implied rather than fully prescribed.

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

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

With no annotations, the description does substantial work: it discloses that the proposal is priced by the cost model, that the cost band covers only the slate row plus the owner's decision (zero GPU, attention estimate flagged [e]), and that downstream work is priced separately. It omits what the tool returns and whether duplicate/withdrawn proposals are handled.

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

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

Purpose is front-loaded in the first clause and the pricing caveat is genuinely load-bearing rather than filler. The parenthetical '[e]' marker and repeated 'prices the proposal, not the work' phrasing add some density that a reader must parse twice.

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?

Behavior is well covered for a no-annotation mutation, but with zero schema descriptions, no output schema, and a nullable night plus an open-ended cost_estimate object, the description leaves the agent guessing about required shapes and what comes back. Adequate, 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 coverage is 0%, so the description must explain three parameters and largely doesn't. 'Intention' and the optional 'night' target are only hinted at by the phrase 'the night's slate', and 'cost_estimate' is never tied to the parameter or its expected keys/units.

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+resource+destination: proposing a plan intention to the night's slate under kind plan.intention, which implicitly separates it from the sibling propose_recipe_edit. The domain jargon ('night', 'slate', 'band') makes intent graspable but not instantly crisp.

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 an explicit prerequisite ('read world://context first') and a quality bar ('aim the proposal at a real gap'). It also draws a clear boundary — the owner reads the slate and starts the night, not the agent — but never names a sibling alternative or a when-not-to-propose case.

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

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

With no annotations, the description carries the full burden. It usefully discloses that unknown params are refused outright and the prediction is committed before a render exists — real behavioral traits. However, it never says whether the proposal is applied or merely queued for approval, what state changes result, whether it requires a node/region to exist, or what comes back.

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?

At three sentences it is short, but it is not front-loaded: the operative fact (this proposes a recipe edit) is never stated and the opening sentence is atmospheric filler. The parenthetical section reference (§5.1) costs space without helping an agent act.

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

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

A five-parameter mutation-style tool with nested objects, no annotations, no output schema, and zero schema descriptions needs the description to do heavy lifting. Instead it covers ordering and rejection semantics while leaving the argument shapes and result behavior undocumented.

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 five parameters. The description only gestures at `word` (its own param schema is the contract) and `prediction` (sealed first); it says nothing about `node`, `region`, the expected shape of `params`, or what a prediction object should 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 description opens with metaphorical framing ("Change the world through the typed vocabulary") rather than stating a plain verb+resource: that this proposes an edit to a recipe. The mechanics it does disclose (the seal ordering, the param schema as contract) are about side-constraints, not the core action, so an agent has to infer the purpose from the tool name 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?

It does name one sibling and a sequencing rule — the render is requested separately via request_render, so the bet is sealed before its test exists — which is genuine routing help. But there is no guidance on when to choose this over propose_plan_intention, file_work_order, or other siblings, and no prerequisites 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?

With no annotations, the description carries the burden and does substantial work: it discloses that this is an enqueue (not a synchronous render), that a separate seat consumes the queue, that a measured cost model prices the ask as p50/p95, and that outputs get provenance and licence metadata. It doesn't state whether queued jobs can be cancelled or what happens on rejection, keeping it below 5.

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

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

Three sentences, front-loaded with the verb and resource, but the prose is dense and metaphorical ('a night of props', 'ride the intention', 'the genbatch seat consumes the queue'), which costs parsing effort without adding precision.

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 5-parameter mutation-ish tool with no annotations and no output schema, the description conveys the async queue semantics and pricing behavior well but omits what is returned on enqueue and leaves two parameters (night, cost_estimate) undocumented anywhere. Adequate, 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 coverage is 0% across 5 parameters, so the description must compensate and partially does: it explains kind (prop.512/prop.1024, priced per variant), count (scales p50 ask and p95 rail), and intention (what to make, how many seeds). However 'night' and 'cost_estimate' receive no explanation at all, leaving real gaps.

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 ('Queue a generative batch (genbatch)') and describes the full pipeline: local image model + TRELLIS.2 producing measured, judged props recorded as assets with provenance and licence. Jargon ('a night of props') slightly obscures the object, but the operation is distinguishable from siblings like request_render or propose_plan_intention.

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, when-not-to-use, or named alternative is given. The phrase 'the genbatch seat consumes the queue' hints at the async execution model but doesn't tell an agent when to pick this over request_render or propose_plan_intention. Usage must be inferred.

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

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

With no annotations available, the description does carry some of the burden by disclosing the shape of what comes back: slated tasks with their asks, the night's rails, the owner's two cost/fit lines, and remaining budget when a night is running. It says nothing about persistence, permissions, or freshness of the plan, and the return description is phrased in unexplained jargon.

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 that states the core purpose first, with no filler. But the sentence is over-packed — five distinct concepts crammed into one clause chain with parenthetical jargon — which costs readability without adding routing value.

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

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

With no output schema and no annotations, the description must explain the return value, and it does list the components. It falls short because key terms ('asks', 'the bar', 'filer's override', 'p50') are never defined, forcing a dependency on list_vocabulary that the description does not 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No misleading parameter hints are given.

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 the resource ('the night's plan and its price') and enumerates what it contains — slated tasks, asks, the bar, the owner's lines, and remaining budget — so the domain is clear. However, it never uses a plain verb (read/retrieve) and leans on undefined in-house terms ('asks', 'the bar', 'the owner's two lines'), so an agent must infer the operation from the tool name rather than the prose.

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 siblings such as get_context or propose_plan_intention, and no preconditions or exclusions. Usage is only implied by the fact that it returns a plan rather than mutating one.

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

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

With no annotations the description carries the full burden, and it does disclose meaningful behavior: the call is queued rather than synchronous, it is priced by a measured cost model ("kind rung.N"), and the queue row is authoritative until the engine lands. That is genuine async/cost disclosure an agent needs. It still omits permissions, failure modes, and how to observe completion, and the disclosure is wrapped in metaphor that slows comprehension.

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

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

Purpose and rung levels are front-loaded, but "the engine that renders it is the recipe half's seat, so until it lands the queue row is the honest state" spends a full sentence on ornamental phrasing for a simple idea (rendering is asynchronous; poll the queue). Dense project-specific vocabulary reduces parseability rather than adding 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 4-parameter, zero-annotation, no-output-schema tool, the description covers only the rung scale and the queued nature of the request. It leaves entry_paths semantics, branch semantics, cost/quoting mechanics, and any notion of what a successful call returns or how to check status undocumented.

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

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

Schema description coverage is 0%, so the description must compensate, and it does partially: `rung` is fully demystified (1/2/3 with distinct visual fidelity) and `seed` is tied to reproducibility matching a prediction. `entry_paths` and `branch` receive no explanation at all, leaving half the parameters as bare typed fields.

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

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

The opening clause gives a concrete verb and resource ("Request a render or preview of entries") and the parenthetical defines the three rung levels concretely (fast layout / mid with lighting and materials / full), which is real semantic content. Sibling differentiation is absent, and the second half drifts into opaque house jargon ("core's door", "recipe half's seat"), but the core purpose is still recoverable.

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 prefer this over alternatives, no prerequisites, no when-not-to-use. The only guidance is a consistency constraint ("Price a sealed prediction against the SAME rung and seed you render"), which implies a companion prediction flow but never names a tool from the sibling list or explains the choice between render and preview.

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

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

No annotations exist, so the description carries the full burden and does a good job: it discloses the return shape (cursor plus events since since_seq), states that rewinding is free, and clarifies that it is the polling form of world://dirty notifications. It omits permission requirements and any volume/pagination limits, which prevents a top score for a no-annotation tool.

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

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

Three sentences, front-loaded with the verb, then the return contract, then the usage qualifier — no filler. Some density-jargon ('world.dirty', 'the recipe moves') slightly raises parsing cost but is tied to the domain.

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

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

With no output schema and no annotations, the description does the work of explaining the return value and the push/poll split, which is what an agent needs to call it. It leaves open event volume, ordering guarantees, and whether a subscription persists server-side.

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

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

Schema coverage is 0%, so the description must compensate, and it does: since_seq is explained as the watermark for which dirty events are returned, and 'rewind is free' clarifies that a smaller or reset value is safe. It does not state the default of 0 or the units/ordering of seq, leaving a small gap.

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

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

States a specific verb and resource ('Subscribe to world.dirty') and immediately defines the payload: 'what changed in the world and when' plus the returned cursor {branch, head, seq}. It also distinguishes itself from the push mechanism it mirrors, so an agent knows this is the polling variant rather than a generic subscribe.

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

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

Explicitly says this is for 'clients that cannot' hold a subscription stream, so the when-to-use condition is stated alongside the alternative it replaces. It stops short of naming any peer tool in the sibling list or stating exclusions relative to them, which keeps it below a 5.

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