Skip to main content
Glama
SightRadar MCP Server

SightRadar MCP Server

Official

Check a collection deletion

get_deletion_status
Read-onlyIdempotent

Track collection deletion progress, including phase, verified-gone status, purge timing, retry attempts, and last error, to confirm completion or diagnose blocks.

Instructions

Track a collection deletion: phase (not_deleting, deletion_pending, deleting, completed, blocked), whether the data is verified gone (verified_zero), purge_after, attempts and the last error. Free.

Input Schema

NameRequiredDescriptionDefault
collection_idYesCollection id, e.g. an event or album id. Any text except '/', '\', '.' and '..'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive behavior, and the description adds genuinely new context beyond them: the full state machine (not_deleting through blocked), verified_zero, purge_after, retry attempts, last error, and that calls are free. The main gap is what happens when collection_id is unknown or never existed.

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

Conciseness4/5

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

One dense sentence, front-loaded with the verb and resource, then the returned fields in priority order. The trailing word 'Free' is slightly abrupt but is a useful cost signal and costs almost nothing.

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

Completeness4/5

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

There is no output schema, so the description properly serves as the return-value documentation by listing phases and fields such as verified_zero, purge_after, attempts and last error. It is nearly complete for this complexity; only the unknown-collection outcome is unstated.

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?

There is a single parameter at 100% schema coverage, including a description and character restrictions, so the schema carries the load. The description adds no parameter-level meaning beyond that baseline.

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

Purpose4/5

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

The description opens with a specific verb and resource, 'Track a collection deletion', and enumerates the phase values, which makes it distinguishable from sibling delete_collection (which initiates) and restore_collection. It does not explicitly say 'read-only status polling', but the phase list makes the monitoring role clear.

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

Usage Guidelines3/5

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

The monitoring role is implied by the phase enumeration, but there is no explicit when-to-use statement such as 'call after delete_collection to poll progress' and no mention of alternatives or when this is unnecessary. An agent must infer the workflow from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.