Api privacy processings create

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

Annotations declare readOnlyHint=false and openWorldHint=true, i.e. a mutating operation, while the description frames it as a CSV/XLSX export. No information is given about required permissions, side effects, or what the single body payload should contain, so the description actively misleads rather than adds context.

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?

It is a single short sentence, but brevity here comes from being boilerplate copy-pasted from a mixin docstring rather than from disciplined editing. The content does not earn its place because it is unrelated to the tool.

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 create/mutation endpoint with an untyped body, no output schema, and annotations that only flag non-idempotency, the description supplies none of what an agent needs: what object is created, what the payload must contain, or what comes back.

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?

There is one parameter (a free-form `body` object) with 0% schema description coverage, so the description must compensate and it does not. Nothing is said about the fields of the privacy processing to submit, required vs optional attributes, or the payload format.

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?

"Generic export mixin for CSV/XLSX exports" describes a different operation entirely from the tool's name, which is a create endpoint for privacy processings. It names no verb or resource relevant to creating a processing and cannot be distinguished from the sibling export tools it accidentally describes.

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?

There is no guidance on when to call this versus siblings such as ciso_assistant_api_privacy_processings_list, partial_update, or the dedicated export_csv/export_xlsx tools. The one sentence present points the agent toward the wrong family of tools.

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