Skip to main content
Glama

Validate Operation

validate_operation

Verify AWS operation validity and authorization, including parameter checks, before execution.

Instructions

Check if an operation is valid and allowed without executing

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
serviceYes
operationYes
parametersNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. The key behavioral guarantee 'without executing' is disclosed, which is important. However, it does not explain what 'valid' or 'allowed' mean in terms of side effects, permission checks, or whether validation has any external effects. Some transparency is present, but not deep.

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?

One sentence, front-loaded, and every phrase earns its place. The core behavior and key non-execution constraint are stated in a single efficient sentence with no fluff or repetition.

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

Completeness3/5

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

The tool is relatively simple and has an output schema, so return-value documentation is not required here. Still, there is no guidance on when to use this versus aws_query/aws_execute, and the parameter semantics are thin. It is minimally viable but lacks enough surrounding context to be considered complete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for undefined parameters. It gives only slight meaning to 'operation' by saying operations can be valid and executable, but 'service' and 'parameters' remain unexplained. The description adds minimal semantic value beyond the schema's bare parameter names.

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?

The description uses a specific verb ('Check') with a clear resource ('an operation') and defines the scope precisely: 'valid and allowed without executing.' This clearly distinguishes it from execution-oriented siblings like aws_execute and aws_query, which actually run operations.

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 phrase 'without executing' implies this is the safe pre-check tool to use before running an operation, but it does not explicitly name alternatives or state when to avoid this tool. The usage context is implied rather than directly stated.

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