Skip to main content
Glama
krishna-goje

quicksight-mcp

by krishna-goje

snapshot_analysis

Read-only

Captures the current state of a QuickSight analysis for QA comparison before changes. Use diff_analysis afterward to verify what changed.

Instructions

Take a snapshot of the current analysis state for QA comparison.

Use this BEFORE making changes. After changes, use diff_analysis to compare and verify exactly what changed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
analysis_idYesThe QuickSight analysis ID.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile (non-mutating capture) is covered. The description adds workflow lifecycle context (must precede changes, feeds diff_analysis), which is useful. However it says nothing about where the snapshot is stored, whether it persists across sessions, or whether repeated snapshots overwrite prior ones — meaningful behavior for a snapshot tool that remains undisclosed.

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

Conciseness5/5

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

Three short sentences, zero filler, and the primary action plus the sequencing constraint are front-loaded before the sibling pointer. Every sentence earns its place.

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?

With an output schema present, return values need no explanation, and readOnlyHint covers safety. The before/after workflow pairing with diff_analysis is fully conveyed. Minor residual gap: persistence/scope of the snapshot is not addressed, which matters for a tool whose whole value is a retrievable baseline.

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?

Schema description coverage is 100% with a single required parameter (analysis_id) already documented in the schema as "The QuickSight analysis ID." The description adds no format, sourcing, or constraint detail beyond that, so the baseline 3 applies.

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

Purpose5/5

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

States a specific verb+resource ("take a snapshot of the current analysis state") plus the reason ("for QA comparison"), and explicitly names the sibling diff_analysis that consumes the result. An agent can distinguish this from backup_analysis/restore_analysis/clone_analysis without opening a schema.

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

Usage Guidelines5/5

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

Explicit when-to-use: "Use this BEFORE making changes." Explicit alternative and its selecting condition: "After changes, use diff_analysis to compare and verify exactly what changed." Nothing is left to inference.

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