Delete multiple custom fields from Paperless-NGX in bulk by passing field IDs; set confirm true to acknowledge permanent system-wide removal.
Bulk edit custom fields. ⚠️ WARNING: 'delete' operation permanently removes custom fields from the entire system.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Must be true when operation is 'delete' to confirm destructive operation | |
| operation | Yes | ||
| custom_fields | Yes |
Changes observed during successful MCP inspections.
v2.2.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the safety burden, and it does disclose the key trait: 'delete' permanently removes fields from the entire system, which is a global, irreversible side effect beyond the schema. It omits auth requirements and what happens to documents using the deleted fields, keeping it short of a 5.
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?
Two short sentences, with the destructive warning surfaced up front and no filler. Efficient, though it spends words on 'bulk edit' framing that the schema actually narrows to delete-only.
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 destructive mutation with no annotations and no output schema, the description covers the critical hazard but omits prerequisites (confirm must be true), the delete-only operation reality, and any return behavior. Adequate but with clear gaps.
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 only 33%, so the description should compensate but adds nothing about parameters. The custom_fields array of numbers (field IDs) is undocumented, and the confirm flag's destructive-precondition role is left entirely to the schema.
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 names a verb ('bulk edit') and resource ('custom fields'), but 'edit' oversells the tool: the operation enum permits only 'delete', so a reader expecting edits could be misled. It also does not distinguish this from the sibling delete_custom_field.
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 guidance on when to use this bulk tool versus the singular delete_custom_field, nor when bulk deletion is appropriate over individual calls. The delete warning hints at scope but never states the selecting condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.