ciso_assistant_api_privacy_purposes_listRetrieve and filter privacy processing purposes with pagination, search, and ordering to support compliance reporting and data mapping.
Override the list method to inject optimized data into the serializer context.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| limit | No | ||
| offset | No | ||
| search | No | ||
| ordering | No | ||
| max_pages | No | ||
| processing | No | ||
| legal_basis | No | ||
| article_9_condition | No |
Changes observed during successful MCP inspections.
v2.3.6Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint, idempotentHint and openWorldHint, the description adds no behavioral context at all — no pagination, filtering, or result-shape information. Its only sentence describes internal serializer behavior that is meaningless to a caller.
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 sentence, so not verbose, but it is front-loaded with internal jargon ('Override the list method', 'serializer context') rather than the user-facing action. Brevity here reflects missing content rather than tight writing.
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?
Nine undescribed parameters, no output schema, and no annotation-derived explanation in the text; the description leaves almost every question an agent would have unanswered. For a paginated list endpoint with filters, this is grossly insufficient.
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 are 9 parameters (id, limit, offset, search, ordering, max_pages, processing, legal_basis, article_9_condition) with 0% schema description coverage, and the description says nothing about any of them. The burden of explaining these undocumented parameters is entirely unmet.
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 is an implementation note about overriding the list method and injecting data into the serializer context; it never states that the tool lists privacy purposes or what a caller would use it for. The resource is only inferable from the tool name, not the description.
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?
No indication of when to use this versus the many sibling list/retrieve endpoints (e.g. privacy_purposes_retrieve, privacy_purposes_object_retrieve), nor any prerequisites or exclusions. The agent has to guess entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.