guard_dominance

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

With no annotations provided, the description carries the behavioral transparency burden and does meaningful work: it states that the tool returns proven, skippable, or undecided evidence and explicitly declares that it never emits a safety verdict. This is important non-obvious behavioral information, absent even though the tool is inference-oriented.

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 filler. The action is front-loaded, the result vocabulary is compact, and the 'never emits a safety verdict' clarification earns its place because it prevents the agent from misusing the result.

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 moderately simple graph-analysis tool, the description covers the main query, the input relationship, and the result classes. There is no output schema, so the description is the only place where the return concept is defined; it does define it. It would be stronger if it also explained what happens for unrecognized guards or unsatisfied preconditions, but the definition is still usable.

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 phrase 'entry-to-effect call path' adds meaning to the two required string parameters, entry and effect. However, with schema description coverage of only 25%, the description still leaves depth undefined and does not clarify how the optional parameters interact with the dominance analysis. It partially helps but does not fully compensate for the sparse schema.

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 uses specific language: it checks whether recognized guards dominate an effect, and explicitly states the result is evidence rather than a safety verdict. This cleanly separates it from a safety-assessing tool. It doesn't name a particular sibling to differentiate from, but the main operation is clear.

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 implies when the tool is useful: when you need guard-dominance evidence on an entry-to-effect call path. It also implies when not to use it: when what you actually need is a safety verdict. But it provides no explicit when/when-not guidance and names no alternative tools.

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