Skip to main content
Glama
ckq-aws

Resilience Architect MCP

by ckq-aws
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

CreateFISExperimentTemplate

Creates a new AWS FIS experiment template defining targets, actions, and stop conditions for fault injection experiments.

Instructions

Create a new AWS FIS experiment template.

This tool creates a new experiment template that defines the parameters for
fault injection experiments, including targets, actions, and stop conditions.

Args:
    ctx: The MCP context for logging and communication
    clientToken: Client token for idempotency
    description: Description of the experiment template
    role_arn: IAM role ARN for experiment execution
    name: Required name for the experiment template (will be added as Name tag)
    tags: Optional additional tags to apply to the template
    stop_conditions: Conditions that stop the experiment
    targets: Target resources for the experiment
    actions: Actions to perform during the experiment
    log_configuration: Configuration for experiment logging
    experiment_options: Additional experiment options
    report_configuration: Configuration for experiment reporting

Returns:
    Dict containing the created experiment template

Raises:
    Exception: For AWS API errors or when writes are disabled

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesRequired name for the experiment template (will be added as Name tag)
tagsNoOptional additional tags to apply to the template
actionsNoActions to perform during the experiment
targetsNoTarget resources for the experiment
role_arnYesIAM role ARN for experiment execution
clientTokenYesClient token for idempotency
descriptionYesDescription of the experiment template
stop_conditionsNoConditions that stop the experiment
log_configurationNoConfiguration for experiment logging
experiment_optionsNoAdditional experiment options
report_configurationNoConfiguration for experiment reporting

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries full behavioral burden. It usefully discloses idempotency handling via clientToken and that writes may be disabled, but does not state required IAM permissions, whether the operation is reversible, or the shape/contents of the returned dict beyond 'the created experiment template'.

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?

The two-sentence summary is well front-loaded, but the bulk of the text is an Args list that duplicates the input schema one-for-one and includes 'ctx', which is not an agent-facing parameter. The duplication is filler rather than earned content.

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?

For an 11-parameter creation tool with no annotations and no output schema, the description is only minimally adequate: it identifies the tool and error behavior but omits permission requirements, return-value contents, and how the nested/opaque structures (actions, targets, stop_conditions) should be shaped. The agent is left to infer most integration details.

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%, so the baseline is 3. The Args section simply restates the schema's own descriptions verbatim (e.g., 'Optional additional tags to apply to the template') and adds no format, constraint, or structural meaning beyond what is already structured data.

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 first sentence states a specific verb+resource ('Create a new AWS FIS experiment template'), and the second sentence clarifies what a template contains (targets, actions, stop conditions). This cleanly separates it from sibling UpdateFISExperimentTemplate, GetFISExperimentTemplate, and the List* tools.

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 create versus update an existing template, when this is preferable to other siblings, or what prerequisites (e.g., a valid IAM role, enabled writes) must hold. The only hint is the buried 'Raises ... when writes are disabled' line, which is a failure condition rather than usage guidance.

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