ciso_assistant_api_policies_duplicate_createCreate a duplicate of an existing policy by ID, enabling versioning, reuse, or modification without manual re-entry.
API endpoint that allows applied controls to be viewed or edited.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Changes observed during successful MCP inspections.
v2.3.6Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent knows this is a non-idempotent write. The description adds nothing about duplication semantics – whether relationships, owners, or linked controls are copied, or what the response is – and its 'viewed' framing is inconsistent with a write operation, so it actively degrades rather than informs.
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 every word of it is wasted because the content describes a different endpoint entirely. Brevity without accuracy does not earn credit.
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?
A mutating, non-idempotent duplicate operation with no output schema, an undocumented id parameter, and zero annotation-documented behavior needs a description that explains what gets copied and how to call it. This description supplies none of that and substitutes an unrelated generic DRF docstring.
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?
One required parameter (id) with 0% schema description coverage, and the description never mentions it. The agent cannot tell from any source whether 'id' is the id of the policy to duplicate or something else, nor what happens if it is invalid.
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 says the endpoint lets 'applied controls' be 'viewed or edited', but the tool is ciso_assistant_api_policies_duplicate_create – a duplicate/create operation on policies. Both the resource and the action are wrong, so an agent reading this would form a completely false model of the tool.
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 when-to-use guidance at all, and the only implied usage (view or edit applied controls) is misleading given the tool duplicates a policy. Nothing distinguishes it from siblings such as ciso_assistant_api_policies_create or ciso_assistant_api_policies_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.