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

Annotations already declare readOnlyHint, idempotentHint, and closed-world, so the safety profile is covered. The description adds genuine non-annotation context: the response shape is not uniform, `allowed` is the only field safe to read across both variants, and the two shapes correspond to two different backend endpoints. It stops short of stating failure modes (invalid artifact_id, contract mismatch on inputs) or rate limits.

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 core guarantee ("Always returns `allowed`") is front-loaded and the shape divergence is explained before the artifact list. It is information-dense but the enumeration of pub_* IDs and their domains duplicates the schema's artifact_id description, which is the one removable block.

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 tool with a polymorphic response, nested objects, and mixed authentication requirements, the description covers auth (no key for pub_*), the polymorphic return contract, a cross-reference to outputSchema for exact shapes, and the available demo artifacts. An agent has everything needed to call it correctly without guessing the response shape.

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 every parameter including the pub_* ID list and the api_key/domain_id split is already documented in structured data. The description largely restates the schema's artifact_id guidance rather than adding new meaning about how `decision` must match an artifact action or how `inputs` keys are validated. Baseline 3 applies when the schema carries the load.

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?

"Check whether an AI decision is allowed, denied, or needs escalation according to a sealed NOMOS governance artifact" names a specific verb (check/verify), a specific resource (a decision against a sealed artifact), and the three possible outcomes. It is clearly distinguishable from siblings generate_governance (producing artifacts) and detect_contradictions (auditing rules), and the mention of artifact types further narrows the scope.

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 gives concrete routing guidance between artifact classes: use pub_* IDs for public demos with no API key, and your own Studio artifact IDs (plus domain_id) for custom governance. It does not explicitly state when to prefer this tool over ask_authority, so the sibling-level exclusion is missing, but the intra-tool selection guidance is strong.

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