Skip to main content
Glama
Knuckles-Team

CISO Assistant MCP Server

Api privacy right requests status retrieve

ciso_assistant_api_privacy_right_requests_status_retrieve
Read-onlyIdempotent

Fetches the status of a privacy right request from CISO Assistant so you can track its progress and support privacy compliance workflows.

Instructions

API endpoint that allows right requests to be viewed or edited.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.6

TDQS

C2.2/5.0
Behavior1/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description says the endpoint allows right requests to be 'edited', implying write capability. That directly conflicts with the read-only annotation and gives an agent no accurate picture of the call's behavior.

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?

It is a single short sentence with no padding, so it is not bloated; however brevity here comes from under-specification rather than from precise wording, since the sentence conveys no operation-specific information.

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

Completeness2/5

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

With no output schema, no annotations covering return data, and zero parameters, the description is the only source of information about what comes back, and it says nothing about the status payload. For an enumeration endpoint, the agent has no idea whether it receives a list of strings, objects, or a single record.

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

Parameters4/5

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

The tool takes zero parameters, which is the baseline-4 case. The description adds nothing about parameters, but with an empty schema there is nothing that needs compensating.

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 generic DRF boilerplate: 'API endpoint that allows right requests to be viewed or edited' restates the resource name without stating the specific operation. The tool name promises a status enumeration ('status_retrieve'), yet the prose never mentions statuses or what this endpoint returns, so an agent cannot distinguish it from the sibling _retrieve, _list, or _update endpoints.

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 when-to-use guidance, no alternatives named, and no hint that this endpoint is a lookup of allowed status values rather than a record fetch. The only guidance-like phrase ('viewed or edited') points in the wrong direction.

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