td_errors

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

With no annotations provided, the description carries the full burden and does so well: it discloses that the traversal is breadth-first and bounded, that the budget can run out before reaching user operators when starting from `/`, and that node errors are otherwise invisible. This is meaningful behavioral context beyond the raw schema.

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 tight and front-loaded: the purpose appears in the first sentence, followed by why the tool exists and how to choose the path. The longer budget explanation is directly relevant to avoiding a realistic failure mode, so 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?

Given a single optional parameter and an output schema that can document return values, the description is complete for a diagnostic tool. It covers purpose, when to use it, path-selection pitfalls, and the bounded-walk behavior. No important operational context appears to be 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 description coverage is 0%, so the description must explain the `path` parameter, and it does thoroughly: the default is the project, `/` is usually the wrong target, the walk is bounded, and users should point at their built component. This adds substantial meaning beyond the schema's bare type/default.

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 clearly states the tool returns every operator at or under `path` that is reporting an error or warning, and explains why this matters (errors shown as UI colours are otherwise invisible). It does not explicitly distinguish itself from sibling diagnostic tools such as td_status or td_health, so it stops short of a full sibling differentiation.

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 explicitly advises checking after building something, warns that the default is the project rather than `/`, and tells the user to point at the component they built. It gives clear context and an exclusion (root is usually wrong), but it does not reference alternative tools or state when to prefer a sibling tool over this one.

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