Skip to main content
Glama
Knuckles-Team

CISO Assistant MCP Server

Api evidence revisions attachment retrieve

ciso_assistant_api_evidence_revisions_attachment_retrieve
Read-onlyIdempotent

Retrieve the attachment linked to a specific evidence revision by ID, enabling review, download, or verification of supporting compliance evidence.

Instructions

API endpoint that allows evidence revisions to be viewed or edited.

Input Schema

NameRequiredDescriptionDefault
idYes

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?

The description says evidence revisions can be 'viewed or edited', which implies write capability, while annotations declare readOnlyHint=true and the endpoint name indicates retrieve. This is a direct contradiction of the declared read-only safety profile, and the description adds no useful behavioral context such as what attachment data is returned.

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 definition is a single sentence and structurally compact, but the sentence is generic boilerplate that does not earn its place. Brevity here reflects under-specification rather than efficient communication.

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 one-parameter retrieve endpoint with no output schema, the description should at least identify that it retrieves an evidence revision attachment and what the id represents. It instead gives a generic DRF-style sentence that omits the resource, action outcome, and parameter meaning.

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?

The single required `id` parameter has 0% schema description coverage, and the description does not explain what the id refers to or how it is used. It adds no meaning beyond the bare parameter name in the schema.

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 says only that it is an API endpoint for evidence revisions to be viewed or edited, without mentioning the attachment resource that the tool name identifies. It is generic enough to be confused with evidence_revisions_retrieve or other revision tools, and does not state a specific retrieve action.

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 on when to use this attachment-retrieve endpoint versus siblings such as evidence_revisions_retrieve, evidence_revisions_object_retrieve, or evidences_attachment_retrieve. The agent is left to infer usage entirely from the tool name and schema.

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