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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Return...', offering no detail about side effects, authorization requirements, error behavior, or output semantics. The verb 'Return' weakly implies read-only behavior, but that is an inference rather than a disclosed trait.

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 short and front-loaded, which is structurally appropriate for a simple retrieval tool. However, its brevity is achieved primarily by omitting useful information, so it is concise without being substantive.

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?

An output schema exists, so return-value documentation may be partially covered by that schema. But the tool has no annotations, five undocumented parameters, and high sibling ambiguity, and the one-line description does not explain what the contract contains, how the parameters affect the result, or why an agent should choose this tool over similar secure-context recipes. This is not enough for confident selection and invocation.

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%, and the description adds no meaning to the five optional parameters (status, channel_id, artifact_id, endpoint_id, object_type_id). An agent cannot determine whether these are filters, identifiers, scopes, or output selectors. The description completely fails to compensate for the schema's lack of parameter documentation.

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 verb, 'Return', and identifies a resource: 'the secure context evidence API and release contract'. However, the resource is vague and essentially restates the tool name with 'API' added, and it does not differentiate this tool from the many sibling recipes_secure_context_* tools.

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 no information about when to use this tool or when to prefer an alternative. With dozens of sibling recipe tools, including secure_context_attestation_pack, secure_context_eval_pack, and secure_context_lineage_ledger, an agent receives no routing guidance. This is a complete absence of usage guidance rather than misleading guidance.

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