Contract Testing: Get Audit Log

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, lowering the burden. The description adds useful behavioral context: workspace scope, default sort order, keyset pagination mechanism, and default page size. It does not mention rate limits or auth, but the annotation coverage makes this gap minor.

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 with a front-loaded purpose, a clear Toolset label, and an organized use-case list. However, the Parameters block largely duplicates the input schema, adding unnecessary length.

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?

It covers purpose, workspace scope, all seven parameters, defaults, and realistic use cases. The only noticeable gap is the absence of any description of the audit event record shape, which matters more because there is no output schema.

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 100% with descriptions for all seven parameters. The description largely restates those schema meanings and adds only an explicit 'keyset pagination' label and use-case hints, so it stays at the schema baseline without significant added value.

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 one-sentence description 'Retrieve the audit log of events in the workspace' uses a specific verb and resource, and the use-case list clarifies the tool's role. Among the many siblings, no other tool targets audit logs, so it is inherently differentiated.

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 'Use Cases' section lists four concrete scenarios (reviewing changes, investigating pact publications, compliance filtering, tracking deployments), telling an agent exactly when to call it. No alternative audit-log tool exists among siblings, so no when-not-to-use instruction is needed.

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