Skip to main content
Glama
Knuckles-Team

CISO Assistant MCP Server

Api resilience asset assessments quali impact retrieve

ciso_assistant_api_resilience_asset_assessments_quali_impact_retrieve
Read-onlyIdempotent

Retrieve qualitative impact assessments for resilience asset assessments by ID to support risk analysis and compliance reporting.

Instructions

api_resilience_asset_assessments_quali_impact_retrieve

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.6

TDQS

D1.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description contributes nothing further — no note about what the qualifier field represents, how it is computed, what permissions are needed, or what happens when the assessment lacks a qualitative impact.

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?

It is short, but only because it is under-specified rather than dense. There is no front-loaded statement of intent and the single 'sentence' is a bare identifier with underscores.

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?

With no output schema, no annotation-level detail about the returned payload, and no additional description text, an agent has no way to know what this endpoint returns or how to interpret it. For a retrieval tool with an undocumented id, this is completely inadequate.

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 required parameter 'id' is an untyped-semantics string. The description does not say whether this id refers to the asset assessment, the qualifier, or a related object, so the one parameter that must be supplied is left ambiguous.

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 just the tool name re-typed as a string, so it conveys the same information as the identifier and nothing more. The name does imply retrieving a qualitative-impact value for a resilience asset assessment, which is marginally better than a pure tautology, but no verb-object statement or scope is provided.

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 indication of when to use this tool, and it is surrounded by near-identical siblings such as ciso_assistant_api_resilience_asset_assessments_retrieve and ciso_assistant_api_resilience_escalation_thresholds_quali_impact_retrieve. Nothing tells an agent which of these to select for which need.

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