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

With no annotations, the description carries the full burden, yet it never says whether this is a non-mutating inspection, what happens when a guard trips (blocking error vs. findings list), or whether omitting diff_text falls back to the working tree or staged changes. Only the set of checks is disclosed, not the behavior around them.

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. It is efficient, though the terseness borders on under-specification rather than tightness.

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 and no annotations, so the description should explain the result shape (pass/fail, findings per guard) and default input behavior; it does neither. For a verification tool whose whole value is its verdict, that leaves the agent unable to predict what it gets back.

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 optional parameter is documented in the schema, so the baseline applies. The description does not clarify the important implied semantics of omitting diff_text (what gets inspected by default) even though zero parameters are required.

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

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

A concrete verb ("Verifies") plus resource ("code or git diff") that clearly separates it from the baton read/write/rehydrate siblings. The three guard names are internal jargon that the description never explains, so the agent knows it checks something but not what each guard enforces.

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, no preconditions (e.g., before committing or writing skeleton files), and no reference to alternatives or when not to use it. The agent must infer the trigger point 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?

With no annotations, the description carries the full burden, and it does disclose two useful behavioral facts the schema does not: the tool writes a file to a fixed path (.vicem/BATON.md) and derives content from current project plus git/session state. It omits critical mutation behavior — whether an existing BATON.md is overwritten, whether a backup exists, and what 'compressed' means operationally.

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

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

A single front-loaded sentence with no filler; the artifact path and derivation source come early. It is efficient, though the brevity contributes to the guidance gaps noted elsewhere rather than being a fault of structure.

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-required-parameter file-writing tool with no output schema and no annotations, the description covers what is produced but not what the baton is for downstream (vicem_rehydrate) or what happens on a repeat call. Adequate minimum, with a real gap around idempotency and lifecycle.

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%, including the 4000-token default for budgetTokens, so the schema already documents all three parameters. The description adds no further semantics about how goal or targetAgent influence the emitted baton, so the 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?

States a specific verb and artifact: creates a compressed U-Shaped Context Baton written to .vicem/BATON.md from the current project and git/session state. An agent can tell this is the write-side counterpart to vicem_read_baton from the name alone, but the description never explicitly contrasts itself with the read/rehydrate/guard 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?

There is no when-to-use guidance, no precondition (e.g., run at end of session, before handing off), and no mention of the alternatives vicem_rehydrate or vicem_read_baton. The agent must infer the handoff workflow entirely from the 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?

With no annotations, the description carries the full burden. 'Reads' correctly signals a non-mutating operation and the drift check is a disclosed behavior beyond the name, but there is no explanation of what drift detection returns, whether drift makes the call fail or merely reports a flag, or what the agent should do with that result.

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 tight sentence with the resource first and the drift check second. No filler, nothing redundant.

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

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

For a zero-param read with no output schema, the definition should say roughly what comes back (baton contents, drift status, or an error on drift) and how it relates to vicem_rehydrate. It says what it touches but not what the caller receives or should do with a drift result.

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 clarify; the baseline for a parameterless tool 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?

States a specific verb and resource ('Reads the current .vicem/BATON.md') plus a secondary behavior ('checks for git HEAD drift'), which clearly separates it from vicem_create_baton. It does not distinguish itself from vicem_check_guard or vicem_rehydrate, which sound adjacent.

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 vicem_rehydrate or vicem_check_guard, and no prerequisites or sequencing hints. The agent must infer that this is the cheap way to inspect current state before deciding on other actions.

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 does disclose two meaningful traits: the data source (ledger.json) and that secrets are redacted in the returned code. It does not state what happens when a symbol is missing/not skeletonized, nor any permission or error behavior.

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

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

A single front-loaded sentence with zero waste; the core action and its justification are stated immediately.

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 and no annotations, the description conveys what comes back (exact redacted source) and where it comes from. Only failure/edge-case behavior is unstated, which is a minor 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 both parameters are already documented with examples. The description adds nothing beyond the schema, 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?

States a specific verb (restores) and resource (secret-redacted source code of a skeletonized function/class) with its source (.vicem/ledger.json). The operation is clearly distinct from the baton/guard siblings, though it does not explicitly name or contrast them.

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 'so you never write { ... } placeholders' implies the context of use (when a function body has been skeletonized), but there is no explicit when-to-use/when-not guidance or reference to alternatives such as vicem_read_baton.

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