Skip to main content
Glama
Knuckles-Team

CISO Assistant MCP Server

Api ebios rm strategic scenarios destroy

ciso_assistant_api_ebios_rm_strategic_scenarios_destroy
DestructiveIdempotent

Delete an EBIOS RM strategic scenario by its ID to remove obsolete risk analysis data. Use this action to clean up scenarios no longer relevant to your risk assessment.

Instructions

api_ebios_rm_strategic_scenarios_destroy

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.6

TDQS

D1.4/5.0
Behavior1/5

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

The description adds zero behavioral context beyond annotations. It does not state that deletion is permanent/irreversible, whether cascading deletes affect dependent operational scenarios or attack paths, whether permissions are required, or what a success response looks like. The destructiveHint=true annotation carries the entire burden and the description contributes nothing to it.

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

Conciseness2/5

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

Short, but the content is an unedited machine identifier rather than a front-loaded human sentence. Brevity here reflects under-specification, not concision.

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 destructive, open-world delete tool referencing an ID with no output schema, no annotations-explaining text, and dozens of similarly named destroy siblings – the description provides nothing to disambiguate which entity is removed or what the consequences are.

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?

Only one parameter ('id', required) and schema description coverage is 0%, so the description should clarify that the id is the strategic scenario's own ID rather than a study ID – an ambiguity that matters given the many nested EBIOS RM entities. It does not, but the 1-param schema makes the gap small. Baseline for a single simple id is roughly 3.

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

Purpose1/5

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

The description is literally the tool's internal name repeated ('api_ebios_rm_strategic_scenarios_destroy'), a raw generated identifier with underscores. It never states in plain language that this deletes an EBIOS RM strategic scenario, and reveals nothing about the resource beyond what the name already encodes.

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?

No usage guidance at all: no when-to-use, no prerequisites, no mention of related siblings such as strategic_scenarios_list, strategic_scenarios_retrieve, or the analogous *_destroy endpoints for feared events, operational scenarios, or studies.

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