Wrap hardcoded JSX text

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

With no annotations, the description carries the full burden and does so: it discloses the dry-run default, that unwrappable text (split sentences, JSX-rendering expressions) is listed for a human and never rewritten, and that files not binding `t` are never written and come back in `blocked` with client-component status. These are exactly the safety and idempotency facts an agent needs before invoking a rewriting 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?

Front-loaded with the core action and the CLI equivalent, then progressively adds safety constraints. The final sentence is long and packs multiple clauses (binding requirement, blocked, client component, rerun), but every clause carries behavioral information rather than 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?

An output schema exists, so return values need not be enumerated, yet the description still explains the meaning of the `blocked` bucket and how to act on it. For a two-parameter mutation-capable tool with no annotations, nothing an agent needs in order to call it safely is missing.

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

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

Schema coverage is 100%, so both parameters are already documented. The description restates the `write` semantics (reports only unless write is set) but adds nothing about `root` or config resolution beyond what the schema provides, so baseline 3 applies.

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

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

States a concrete verb+resource pair: find hardcoded user-visible text in JSX/TSX and wrap it in a `t` tagged template, and ties it to the `verbaly wrap` CLI command. This is clearly distinguishable from siblings like verbaly_init, verbaly_extract and verbaly_doctor.

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 frames the tool as the onboarding path for an existing codebase and states the report-only default with `write` opting into mutation. It does not, however, name which sibling to use instead when the codebase is already onboarded (e.g. verbaly_extract or verbaly_missing), so the alternatives guidance is implied rather than stated.

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