Skip to main content
Glama
Knuckles-Team

CISO Assistant MCP Server

Api ebios rm stakeholders create

ciso_assistant_api_ebios_rm_stakeholders_create

Create EBIOS RM stakeholders to map risk ecosystem actors and support threat analysis in CISO Assistant.

Instructions

api_ebios_rm_stakeholders_create

Input Schema

NameRequiredDescriptionDefault
bodyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.6

TDQS

D1.5/5.0
Behavior1/5

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

Annotations already state readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, but the description contributes zero behavioral context on top of that: no mention of what is created, side effects, validation failures, or whether duplicates are allowed. With annotations carrying the entire profile, the description provides no added value.

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?

The text is a one-token identifier with no sentence structure and no front-loaded explanation. Its brevity is under-specification rather than conciseness, since nothing informative is communicated.

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?

For a mutating create endpoint with a free-form body, no output schema, and zero parameter documentation, the description supplies nothing an agent needs to call it correctly. It is completely inadequate relative to the tool's complexity.

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

Parameters1/5

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

Schema description coverage is 0% and the single 'body' parameter is an untyped free-form object (additionalProperties: true, nullable, default null) with no description. The tool description does not say which properties the body must contain, so an agent has no way to construct a valid payload from either source.

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 description is the raw operation identifier 'api_ebios_rm_stakeholders_create', which merely restates the tool name and title. It implies the resource (EBIOS RM stakeholders) and the action (create) only through the name itself, adding no sentence that states what the tool actually does or how it differs from siblings such as stakeholders_create vs stakeholders_batch_action_create.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool, what preconditions exist (e.g. an existing EBIOS RM study), or why to choose it over ciso_assistant_api_ebios_rm_stakeholders_batch_action_create. Nothing is said about required permissions or the parent study context.

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