Skip to main content
Glama
Knuckles-Team

CISO Assistant MCP Server

Api resilience asset assessments batch action create

ciso_assistant_api_resilience_asset_assessments_batch_action_create

Eliminate repetitive individual updates by performing batch actions on multiple resilience asset assessments at once.

Instructions

Perform a batch action on multiple objects.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.6

TDQS

C2/5.0
Behavior2/5

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

Annotations already state readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true; the description adds nothing about what gets mutated, whether deletes are possible in a "batch action", permission requirements, or atomicity/partial-failure behavior. No contradiction with annotations, but zero added value for a high-risk multi-object mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no filler, but it is under-specified rather than concise — the brevity comes from omitting content rather than from tight editing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A bulk-mutating endpoint on resilience asset assessments with no parameters, no output schema, and thin annotations: the description should carry the full burden of explaining the action vocabulary, target selection, and effect, and it does none of this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema declares zero parameters, so there is nothing for the schema to document; the description likewise says nothing about the expected action type or object identifiers. For a batch endpoint that almost certainly requires a payload (ids + action), this silence leaves the agent without any semantics — only the zero-parameter baseline keeps this above a 2.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The sentence "Perform a batch action on multiple objects" restates the title's generic wording without naming the resource (resilience asset assessments) or the action being performed. An agent cannot distinguish it from the dozens of sibling `*_batch_action_create` tools, nor guess what a "batch action" entails here.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus the per-object siblings (`..._assets_..._partial_update`, `..._update`, `..._destroy`) or the other 100+ batch-action tools. No prerequisites, no exclusions, no indication of what payload to send.

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

Deploy Server

Other Tools