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

Annotations cover the safety profile (idempotentHint=true, readOnlyHint=false), but the description adds real value beyond them: atomicity, the requirement to reuse exact arguments and key on an unconfirmed retry, and that only a committed receipt proves success. It stops short of describing auth/permission needs or what an uncommitted retry 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 short, front-loaded sentences with no filler; the commit/atomicity point leads. Slight terseness given the tool's complexity, but every sentence earns its place.

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

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

For a 15-parameter, 10-required tool with nested objects, 0% schema coverage, and no output schema, this description is far too thin. It omits any guidance on the payload structure, revision/precondition semantics, or what the receipt contains, leaving large gaps an agent cannot fill from structured data.

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 15 parameters, so the description carries full burden, yet it only vaguely references 'arguments/key' (likely idempotency_key). It adds essentially no meaning for expected_revision, policy_sha256, preparation_id, outcome, changes, or the other structured 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?

States a specific verb (commit) and resource (the authorized scene), and pairing it against the sibling prepare_turn is implicit but inferable. It clearly signals this is the finalization step, though it never names prepare_turn or other siblings explicitly.

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

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

Implied usage is present: 'Only a committed receipt means success' tells the agent this is the terminal commit step, and the retry note establishes retry conditions. However, there is no explicit when/when-not or named alternative (e.g. prepare_turn must precede it), so an agent must infer the workflow ordering.

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=true, and openWorldHint=false. The description adds genuine context beyond them: that the source snapshot is never mutated (copy semantics) and that the premise field captures an intention rather than a realized event. This clarifies behavioral intent that structure alone doesn't 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?

Three short, front-loaded sentences with essentially no filler; the core action leads and qualifications follow. The premise sentence is slightly cryptic in isolation but is dense rather than wasteful.

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 state-mutating creation tool with 5 required parameters and no output schema, the description omits almost everything an agent needs to call it correctly: what is returned, uniqueness/conflict behavior on branch_id or idempotency_key, and the meaning of most parameters. It is more complete than a stub but not adequate given 0% schema documentation.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate and largely doesn't. It only adds meaning for two of them (premise as an intention, from_revision via "current or historical"), leaving campaign_id, branch_id, name, and idempotency_key entirely 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?

The description gives a concrete verb and effect ("Fork a current or historical snapshot") plus the consequence ("Copies point-in-time knowledge"), which is enough for an agent to understand it creates a new derived branch. It does not, however, explicitly name itself as the branch-creation tool or distinguish it from siblings like list_branches or restore_checkpoint.

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 implies the operation forks a snapshot (current or historical), but gives no when-to-use condition, no prerequisites, and no mention of alternatives such as restore_checkpoint. The result is that the agent must infer usage context from the 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, destructiveHint=false, and idempotentHint=true, so safety and idempotency are covered. The description's 'Reuse the creation key on retries' restates idempotency rather than adding new behavior, and adds nothing about auth/permissions or what happens to an existing campaign with the same name.

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

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

Two short sentences, front-loaded with the core action, and the retry note placed last. No filler, every clause carries meaning.

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

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

Given a complex nested world schema, no output schema, and 0% parameter description coverage, the description is thinner than the tool's complexity warrants. It conveys the high-level action but omits mode exclusivity rules, template semantics, and the shape of a supplied world pack.

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

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

Schema description coverage is 0%, so the description must compensate and does so only partially: 'bundled template' maps to the template enum, 'JSON world pack' to the world object, and 'creation key' to idempotency_key. The required 'name' parameter and the deep world structure (genre, rules, actors, events) are never explained.

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 (create) and resource (campaign) and clarifies that it operates from a bundled template OR a supplied JSON world pack, which distinguishes it from read-oriented siblings like list_campaigns. It does not name a sibling explicitly, but the scope is unambiguous.

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

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

The phrase 'from a bundled template or a supplied JSON world pack' implies the two mutually exclusive creation modes (the template enum vs. the world object), and 'Reuse the creation key on retries' gives retry guidance. However, it never states when to choose this tool over create_branch or when prerequisites apply, leaving usage to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds one genuine domain nuance ('NPC values do not follow secret world changes'), but does not explain what 'last observed' means operationally or how branching/campaign state affects the read.

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

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

Two short sentences with the core purpose front-loaded and no filler. The second sentence is terse to the point of being cryptic, but nothing is wasted.

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

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

With no output schema and three fully undocumented required parameters, the description should carry more weight. It never says what the returned 'values' look like, how they are scoped by campaign/branch, or what happens when no knowledge has been observed.

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 schema documents nothing about viewer, campaign_id, or branch_id. The description maps 'viewer' to 'one actor, player, or gm' but leaves campaign_id and branch_id entirely unexplained, so it only partially compensates 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 resource ('last observed values known to one actor, player, or gm'), which pins down the per-viewer knowledge concept. It does not, however, differentiate itself from close siblings like get_state or read_canon, whose names overlap heavily with this concept.

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

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

There is no statement of when to use this tool versus get_state, read_canon, or read_history, nor any prerequisite or exclusion beyond a passing note about NPCs. The agent must infer the intended context from the 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context: that the original idempotency key must be reused and that a missing receipt does not authorize a new key. This is meaningful behavioral disclosure beyond annotations, though it is phrased cryptically and says nothing about return contents.

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, both dense and front-loaded, with no filler. The second sentence is syntactically convoluted but still earns its place as a behavioral warning.

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

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

There is no output schema, so return values need not be explained, but the tool involves non-trivial idempotency/recovery semantics and three undocumented parameters against 0% schema coverage. The description covers the key idempotency rule but omits what campaign_id and branch_id scope, leaving it only minimally adequate.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it only obliquely references the idempotency_key as 'original key'. campaign_id and branch_id are entirely undocumented in both schema and description. The description partially compensates for the coverage gap but leaves most parameters unexplained.

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

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

The description states a specific action on specific resources ('read every pending check', 'look up an exact committed receipt'), giving a verb+resource pairing. However, terms like 'pending check' and 'committed receipt' are undefined domain jargon, and it never distinguishes this tool from siblings like roll_check or restore_checkpoint. It conveys intent but leaves the exact purpose partially opaque.

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 second sentence ('No receipt at read time is not permission to replay with a new key') is a behavioral caution, not guidance on when to choose this tool over alternatives. There is no statement of when to invoke it versus restore_checkpoint, roll_check, or get_state. 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuine behavioral context not in the annotations: the viewer-dependent redaction of GM facts versus disclosure of the authoritative ledger, which tells the agent what data visibility to expect.

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

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

Two tight sentences with no waste, and the core action ('Read branch state and revision') is front-loaded ahead of the view semantics.

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, yet the description only gestures at return content ('state and revision') without indicating what state comprises or the revision format. For a read tool whose safety profile is already carried by annotations, this is adequate but leaves the agent guessing about the payload.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the semantics of 'viewer' (player redacts GM facts, gm exposes the ledger), which is the one enum parameter, but says nothing about campaign_id or branch_id beyond their self-evident names.

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 ('Read branch state and revision'), which is distinct from siblings like read_history, get_knowledge, and get_recovery. However, it never names or contrasts with any sibling tool, so differentiation relies on inference.

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

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

The description explains the condition for choosing a view ('player view hides GM facts; gm view includes the authoritative ledger'), which is useful guidance for the viewer parameter. It gives no guidance on when to call get_state versus read_history, get_recovery, or read_canon.

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 cover the safety profile (write, closed-world, idempotent, non-destructive), and the description adds genuine behavioral context beyond them: text is stored with derived hashes and line citations, external file/URL references are unavailable, and existing source IDs are immutable so editions require new IDs. The immutability rule is a meaningful trait not expressed by the annotations.

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

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

Three short, front-loaded sentences with no filler. The primary action leads, followed by scope limits and the ID rule, so nothing needs to be re-read.

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

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

For a 2-parameter tool with annotations present and no output schema, the description covers the key storage behavior and the ID immutability rule. It falls short on the campaign_id parameter and the documents array semantics, which are undocumented everywhere.

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

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

Schema description coverage is 0%, so the description must carry the load. It only alludes to the 'id' (immutable source IDs) and the text field; campaign_id, title, the array structure, and the 20-item cap are entirely unexplained in both schema and description.

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

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

States a specific verb (store/ingest) and resource (supplied story text), with the added detail that hashes and line citations are derived. This distinguishes it from the read-side siblings like read_canon and search_canon, though it never names them explicitly.

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

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

Gives operational constraints (no file or URL access; new editions need new IDs) which imply how to call it, but does not state when to prefer this over alternatives such as create_branch or commit_turn. Usage is implied rather than explicit.

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, so the safety profile is covered. The description adds useful data-model context ('no global active branch') but says nothing about pagination, ordering, auth, or result size.

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

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

Two short sentences, front-loaded with the return content, and the clarifying note follows with zero filler. Nothing could be trimmed without losing information.

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

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

For a simple list tool with annotations carrying the safety profile and no output schema, the description adequately covers what is returned but omits the required campaign_id scope and any notion that branches are per-campaign. That omission leaves an agent guessing about the one required input.

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

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

Schema description coverage is 0% and the description never mentions the required campaign_id parameter, so it adds no meaning beyond the schema. The name is fairly self-explanatory, which keeps this above 1, but the description does not compensate for the coverage gap.

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

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

States a specific verb and resource ('List explicit branch IDs and origin revisions') and adds a scope clarification ('no global active branch') that distinguishes it from any notion of a global state. It does not name a sibling tool like create_branch, so it falls just short of the top tier.

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 implicit guidance is that this is the read-only way to discover branches, and the note about no global active branch prevents one misuse. There is no explicit when-to-use statement, no alternative named (e.g., create_branch for mutation), and no prerequisite explanation.

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 rich annotation set (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false) already tells the agent this is a safe, repeatable, closed-world read. The description adds only the phrase "in this owner database" and discloses nothing about pagination, ordering, result limits, or what happens when no campaigns exist, so it contributes almost no behavioral signal beyond the annotations.

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

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

A single short sentence, front-loaded with the verb and resource, with no filler or repetition. It is not bloated, though it is thin enough that the trailing scope phrase "in this owner database" does most of the distinguishing work.

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

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

For a zero-parameter list tool this covers the minimum: what is listed and whose campaigns are listed. However, with no output schema the return shape is entirely undisclosed, "owner database" is left undefined, and there is no indication of ordering or pagination, leaving real gaps for an agent that needs to consume the results.

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

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

The tool takes zero parameters and the schema forbids additional properties, so there is no parameter semantics for the description to explain. Per the rubric, a 0-parameter tool gets a baseline of 4.

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

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

States a specific verb ("List") and resource ("campaigns") plus a scope qualifier ("in this owner database"), so the agent knows this is a read/enumeration of campaigns. It implicitly contrasts with the sibling create_campaign via the verb, but never names an alternative or clarifies what a campaign record contains.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as create_campaign or any filter/branch-scoped listing siblings. The agent must infer that this is the enumeration entry point purely from the name.

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 idempotency (true), destructiveness (false), and open-world scope, so the description is not the sole carrier here. It adds useful behavioral context by enumerating what is returned and clarifying that the story is not advanced, but it never explains why readOnlyHint is false (what gets written or persisted) or what happens when the caller's revision is stale, which matters given "current revision" and the known_policy_sha256 parameter.

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 purpose, then the return payload, then the key constraint. Every sentence contributes and there is 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?

With no output schema, the description helpfully lists what comes back (state, canon, GM context, policy, pending checks), which is real added value. But for a non-read-only tool with five undocumented parameters and no stated ordering relative to commit_turn, it leaves prerequisite, concurrency, and persistence questions unanswered.

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, so the description carries the full explanatory burden and fails it. It never mentions query, branch_id, campaign_id, or known_policy_sha256; only the loose word "policy" in the return list hints at the policy hash, and "player action" loosely maps to player_action. Agents get no guidance on concurrency, defaults, or what the two seemingly unrelated inputs (query, known_policy_sha256) are for.

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 (prepare an exact player action) and scopes it to "the current revision," which is far more than a restatement of the name. It also implies differentiation from commit_turn via "Does not advance the story," though it never names that sibling outright, so an agent must infer the pairing.

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 statement that it does not advance the story suggests it is a pre-step to commit_turn, but no condition, prerequisite, or alternative is stated explicitly. An agent can guess the workflow but is given no when-to-use rules.

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, and the description reinforces this while adding a domain-specific side effect beyond the annotations: no NPC knowledge is granted. That is genuinely new information because 'NPC knowledge' is not covered by any hint. It still doesn't say whether events are returned as a list, how they're ordered, or whether the preview is stable across calls.

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

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

A single sentence with no filler, front-loading the action and immediately qualifying the non-mutating scope. 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?

With no output schema and 0% parameter coverage, the description should clarify what a 'preview' actually returns and what the undocumented destination/elapsed_minutes inputs mean. Annotations cover the safety profile, but the agent still cannot predict the response or the effect of the optional parameter.

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

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

Schema description coverage is 0% across four parameters, so the description carries the full burden and supplies nothing: campaign_id, branch_id, elapsed_minutes, and especially the optional 'destination' are never explained. An agent gets no help on what destination means (travel destination? branch target?) or how elapsed_minutes bounds relate to the 1440 cap.

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 (preview) and a well-scoped resource (deterministic time-driven world events), and the qualifier 'without changing the save' implicitly separates it from commit_turn/prepare_turn. It never names a sibling explicitly, so differentiation is left partly to inference.

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

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

The phrase 'without changing the save or granting NPC knowledge' implies this is a dry-run/simulation step to use before committing a turn, but no explicit when-to-use or when-not-to-use guidance is given. Alternatives such as commit_turn or prepare_turn are not 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 already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds that the payload includes a hash and line citation, which is genuinely useful return context, but says nothing about lookup failure behavior or what a 'canon chunk' comprises.

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; the verb and resource come first and the return detail is appended compactly.

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

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

For a simple read tool with rich annotations, the essentials are mostly covered, but two undocumented required parameters and no clarification of what a canon chunk is or how lookup failures surface leave gaps. No output schema exists, so the brief mention of hash/line citation is a helpful but thin substitute.

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?

Two required string parameters (campaign_id, chunk_id) have 0% schema description coverage, so the description carries the full burden - and it names neither parameter. It never explains that chunk_id is the exact identifier to read or that campaign_id scopes the lookup.

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

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

States a specific verb (read) and resource (canon chunk), and adds that the result includes a hash/line citation. The word 'exact' implicitly contrasts with search_canon, but no sibling is named explicitly, so the differentiation is left to inference.

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

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

There is no statement of when to use this tool versus search_canon or read_history, and no prerequisites (e.g., needing an existing chunk_id from a prior search). The only signal is the adjective 'exact', which hints at direct-ID lookup but is never spelled out.

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 fully covered. The description adds only the mild signal that it surfaces "live" (current) schemas and reinforces no-write behavior; it discloses no permission needs, caching, or freshness guarantees 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?

Two short sentences, front-loaded with the content enumeration. The trailing "No save changes" clause is slightly wasteful, restating something the readOnly annotation already conveys, but otherwise there is no 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 two-parameter, no-output-schema read tool, the description broadly conveys what comes back, but it omits how tool_name scopes the "tools" section and gives no hint about the shape or size of returned documentation. Adequate but with a clear gap on the second parameter.

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 schema documents only types and the section enum. The four listed content categories map loosely onto the enum values (overview/workflows/packs/tools), which partially compensates, but the tool_name parameter is never mentioned and its relationship to section="tools" is left unexplained.

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

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

States a clear verb ("Read") and lists the specific resource categories it returns: operating skill/overview, workflows, pack format, and live tool schemas. This distinguishes it as the meta-documentation reader among gameplay siblings, though it never names an alternative tool to contrast against.

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 or when-not-to-use guidance and no alternative is referenced. "No save changes" is a safety aside, not usage direction, leaving the agent to infer when this meta tool should be called versus siblings like get_state or read_canon.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: newest-first ordering, branch-invariance, and origin being separate and clamped to the fork point. Pagination mechanism is hinted via next_before_revision.

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 dense sentences with the core purpose front-loaded and no filler. Slightly cryptic field naming (next_before_revision vs the before_revision param) keeps it from a 5.

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

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

For a read-only tool with no output schema, the description covers ordering, pagination, and origin/branch behavior well, which is what an agent needs to call it correctly. Remaining gaps (limit bounds, id semantics) are minor.

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

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

Schema coverage is 0% across 5 params, so the description must carry the load. It meaningfully explains origin semantics and before_revision pagination, but limit, campaign_id, and branch_id are left undocumented, so compensation is only partial.

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 ('Read complete committed events'), plus ordering ('newest first'), which separates it from sibling read tools like read_canon or get_state. It does not explicitly name a sibling it replaces, 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?

Usage is implied by 'complete committed events' and the origin note, giving context on when origin vs branch applies. However, no alternative tool is named and no explicit when-to-use vs read_canon/get_state guidance is given, so it lands at minimum-viable.

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=true, destructiveHint=false, but the description adds meaningful nuance beyond them: the operation is an append of a new revision rather than an overwrite, and 'Never erase history' reinforces the append-only contract. It does not mention permission requirements or how conflicts on expected_revision 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?

One sentence, front-loaded with the usage precondition, then the behavioral contract. No filler, no redundancy.

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

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

The behavioral story is adequate and annotations cover the safety profile, but with five undocumented required parameters and no output schema, an agent still lacks the semantics needed to construct a correct call. Complete on intent, incomplete on 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?

Five required parameters with 0% schema description coverage, and the description mentions none of them. Critical semantics such as the difference between expected_revision (concurrency guard) and target_revision (snapshot to restore), or the role of idempotency_key, are left entirely unexplained.

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 effect: 'append a revision restoring a saved snapshot', and scopes what the snapshot includes (knowledge and world clocks). It is clearly distinguishable from siblings like get_recovery or read_history, though it never names them explicitly.

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

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

'Only when the player explicitly requests it' is an explicit, unambiguous trigger condition. It does not, however, name alternatives such as get_recovery or read_history for inspecting state without restoring it, so routing to siblings is left to inference.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false. The description adds real context beyond them: that purpose/difficulty/stakes are fixed, that a purpose cannot be rerolled, and that the complete check set plus a context hash are returned. That is useful behavioral detail for a persistence 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 tight sentences with the core action front-loaded, followed by the immutability rule and the return summary. No wasted words, though the sentences are terse to the point of under-explaining the missing parameters.

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 10-parameter mutation tool with no output schema, the description helpfully summarizes the return value. However, it is far too thin for the parameter surface, leaving most required fields unexplained, so an agent cannot call it correctly from the definition alone.

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 10 parameters (8 required), so the description carries the full burden. It names only purpose, difficulty and stakes, leaving campaign_id, branch_id, preparation_id, check_id, attribute, basis and situational 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?

States a specific verb and resource: 'Persist a server d20 result' with the fixed attributes (purpose, difficulty, stakes). It is clear what the tool does, though it does not explicitly differentiate itself from siblings like preview_world or get_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?

Offers only a single constraint ('No rerolling a purpose') rather than guidance on when to call this versus alternatives. There is no mention of prerequisites (e.g., needing a preparation or branch first) or when-not-to-use, leaving usage to inference.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description still adds real value beyond them: the ranking engine (FTS5/BM25), CJK bigram tokenization, and the important recall caveat that a miss does not prove absence. It omits result shape and whether the search is scoped by campaign.

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

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

Two sentences, no filler, and the core capability is front-loaded before the usage caveat. Every clause carries information an agent can act on.

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

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

With no output schema, the description should describe what a hit contains and how limit bounds results; instead it only implies hits are readable. The safety profile is fully carried by annotations, so the remaining gaps are the undocumented parameters and undefined return shape — adequate but incomplete for a search tool.

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

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

Schema description coverage is 0% across three parameters, so the description carries the full burden and largely fails it: query, campaign_id, and limit (default 4, max 8) are never explained. Only 'CJK bigrams' indirectly hints at how the query string is tokenized; the scoping role of campaign_id and the cap on limit are left 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 ('Search local canon') plus the retrieval mechanism (FTS5/BM25, CJK bigrams), which distinguishes it from siblings like read_canon and get_knowledge. It does not name an alternative explicitly, but the ranking-based full-text framing is enough for an agent to tell it apart from direct-read 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?

'Read hits before citing; a miss is not proof of absence' guides how to interpret and act on results, which is useful workflow context. However, it never states when to choose this tool over read_canon, get_knowledge, or read_history, so the alternative-selection guidance is only implied.

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