project_boundary

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

With no annotations provided, the description carries the behavioral disclosure burden. It openly states privacy-relevant behavior: it never captures prompt/thinking, never stores a user profile, and treats cwd/repository/manifest alone as unknown. It also discloses the core decision rule for automatic code detection. It does not describe side effects or error behavior, but the disclosed invariants are meaningful and specific.

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: three sentences, each adding information about the tool's purpose, privacy guarantees, and decision rule. It is front-loaded with the core purpose. Minor jargon like 'request boundary' reduces immediate readability, but there is no fluff or 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?

The tool has no output schema, no annotations, and low schema coverage, so the description must provide substantial context. It explains privacy guarantees and the staged-tree rule, but it omits what the returned boundary contains, what the operation parameter means, how the mode enum values differ, and what the tool should be used for in practice. This is incomplete for an agent that must call it correctly.

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

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

Schema description coverage is only 25%, and the description does not compensate for the missing parameter details. The enum values for mode, phase, and operation are not explained beyond the phase list in the purpose statement and the 'Explicit mode wins' rule. Only project_root receives meaningful description, both in the schema and briefly in the tool description, leaving three parameters under-documented.

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 ('Return') and identifies the resource ('one token-capped request boundary') and the scope of phases it applies to (plan/read/edit/build/test/commit). It is reasonably clear, though the term 'boundary' itself is not defined and the description does not explicitly distinguish this tool from related siblings like project_actor_boundary.

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

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

The description does not state when to use this tool versus alternatives, and no sibling or alternative tool is mentioned. Some usage behavior is implied through mode resolution ('Explicit mode wins; only a non-empty staged tree is an automatic code signal'), but there is no direct guidance such as 'use when...' or 'if you need X, use Y instead.'

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