contabo_audits

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

Annotations already declare readOnlyHint=true, but the description adds real context beyond that: the server rejects write operations until started with CONTABO_ENABLE_WRITES=1, and parameter sets are validated per operation. That is meaningful behavioral disclosure for a tool whose name alone doesn't reveal the enforcement mechanism.

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 read-only caveat and the operation-selection rule are well front-loaded, but the 16-line operation list largely restates the const values already present in the oneOf schema and pads every line with the redundant '(audit)' suffix. Functional, but not tight.

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 16-way discriminated union with no output schema, the description gives the agent the operation roster, the selection rule, the read-only constraint, and a pointer to contabo_reference, which is enough to invoke it correctly. Missing pagination behavior and a sense of what an audit entry contains, but those are minor given the absent 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 description coverage is 100%, so the schema already documents page, size, dates, orderBy, and per-operation identifiers; baseline is 3. The description adds only structural guidance about the discriminated union ('one operation, its own parameter set') and defers detailed semantics to contabo_reference, adding little beyond the schema itself.

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?

States a specific resource ('Contabo audit logs for every resource type') and enumerates the 16 covered resource types, which lets an agent separate it from sibling management tools like contabo_instances or contabo_firewalls. The retrieval verb is only implied ('audit logs', repeated 'List history'), not stated directly in the opening, but the scope is unambiguous.

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?

Tells the agent to 'Choose exactly one operation' and that each operation has its own validated parameter set, and routes to contabo_reference for full docs. It never states when to use this audit-log tool rather than the live-resource siblings, so the agent must infer that this is retrospective history rather than current state.

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