Update multiple risks at once by specifying risk IDs and fields. Supports partial updates, applying the same values to all selected risks.
Update multiple risks. Update multiple risks at once in a single request. Specify the risk identifiers and the fields you want to update, and all selected risks will receive the same field values. This endpoint supports partial updates.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds the meaningful constraint that every selected risk receives the same field values and that partial updates are allowed, but omits batch-size limits, permission requirements, or any destructive-impact warning.
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 opening two sentences are redundant — 'Update multiple risks' and 'Update multiple risks at once in a single request' say the same thing. The remaining sentences carry real information, so it recovers, but it is not front-loaded efficiently.
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 batch mutation with no output schema, the description covers the core contract (identifiers + shared field values, partial updates) but leaves ambiguity: the schema allows per-item fields while the description says all risks get identical values. No mention of failure behavior if an id is missing or invalid.
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?
Top-level schema coverage is reported as 0% (the body array itself is undocumented), with only nested item properties carrying descriptions. The description compensates partially by naming risk identifiers and 'fields you want to update', but it does not clarify the array-of-objects body shape or which fields are updatable beyond what the schema already lists.
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 first sentence states a specific verb+resource ('Update multiple risks') and the batch scope is made explicit, which separates it from put_risk (single) and post_batch_delete_risks. However, it never names or contrasts those siblings, so an agent must infer the distinction.
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?
It conveys real usage semantics: one request, uniform field values across all selected risks, and partial-update support. It stops short of saying when to use this versus put_risk or post_batch_update_issues-style alternatives, and gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.