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

With no annotations, the description carries the full behavioral burden. It transparently discloses the veto power and its consequence ('if veto_triggered is True, the concept should not proceed'), the BYOK mechanism (provider auto-detection, ephemeral keys, garbage collection), and the fact that keys are never stored. These are critical behavioral traits an agent must know before calling. It does not, however, describe error handling or response format, but the output schema covers that.

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 well-structured: the purpose is front-loaded in the first sentence, followed by a bulleted list of specializations, then the veto power warning, and finally the BYOK details. Each section serves a distinct purpose and there is no redundancy. It is longer than minimal, but the length is justified by the tool's complexity and the need to convey the veto and BYOK behaviors.

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 the tool has 8 parameters and an output schema, the description covers the core purpose, veto power, and BYOK, but leaves gaps: it does not explain the meaning of the detail parameter (e.g., 'standard' vs other levels), the role of context or prior_reasoning, or when to prefer this agent over siblings. The output schema covers return values, so that is not an issue, but the lack of routing guidance and parameter semantics for the undocumented parameters makes it only moderately complete.

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 75% (6 of 8 parameters described). The description adds value for llm_provider and api_key by explaining the BYOK behavior (pass both to use own LLM, auto-detection if only key provided, ephemeral storage). However, it does not compensate for the undocumented context, user_uuid, or prior_reasoning parameters, and the detail parameter's possible values remain unexplained. Since coverage is high, the baseline is 3, and the extra BYOK context justifies holding at that level rather than lowering.

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 opens with a specific verb-resource pair ('Consult Z Guardian agent for ethical review and Z-Protocol enforcement') and immediately differentiates from sibling agents by naming the specialization areas (ethical implications, privacy, bias, social impact) and the unique veto power. This clearly distinguishes it from consult_agent_cs and consult_agent_x, which presumably serve other review functions.

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 the tool should be used when ethical review or Z-Protocol compliance is needed, but it never explicitly states when to choose this agent over consult_agent_cs or consult_agent_x, nor does it list exclusions. The specializations give context but leave the decision to the agent's inference rather than providing clear routing guidance.

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