Skip to main content
Glama
ckq-aws

Resilience Architect MCP

by ckq-aws
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

DiscoverResourceRelationships

Discover dependencies and relationships for an AWS resource via AWS Config to map connections such as subnet placement or attached security groups.

Instructions

Discover relationships for a specific AWS resource using AWS Config.

This tool retrieves the configuration history for a specific AWS resource
and returns its relationships with other resources. This is useful for
understanding resource dependencies, such as finding which subnet an ALB
is placed in or which security groups are attached to an instance.

Args:
    ctx: The MCP context for logging and communication
    resource_type: AWS resource type (e.g., AWS::EC2::Instance)
    resource_id: AWS resource ID to discover relationships for
    limit: Maximum number of configuration items to retrieve
    chronological_order: Order of configuration items (Reverse or Forward)

Returns:
    Dict containing resource relationships and configuration details

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of configuration items to retrieve
resource_idYesAWS resource ID to discover relationships for
resource_typeYesAWS resource type (e.g., AWS::EC2::Instance, AWS::ElasticLoadBalancingV2::LoadBalancer)
chronological_orderNoOrder of configuration items (Reverse or Forward)Reverse

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses that it reads from AWS Config and returns configuration history plus relationships, and the parameters imply read-only retrieval, but it says nothing about required AWS permissions, pagination, or failure behavior when a resource is not found. Useful context is present but key operational traits are missing.

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?

The core purpose and use cases are front-loaded in two well-formed sentences, with structured Args/Returns sections. The Args section largely duplicates the schema, and the 'ctx' parameter listed does not appear in the input schema, adding minor noise.

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 helpfully sketches the return ('Dict containing resource relationships and configuration details'). Combined with full parameter coverage and worked examples, an agent has enough to invoke it correctly, though pagination and error semantics remain unaddressed.

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 schema already documents all four parameters. The Args block essentially restates the schema text ('AWS resource type', 'AWS resource ID to discover relationships for') without adding format, constraints, or interaction details. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb and resource: it 'retrieves the configuration history for a specific AWS resource and returns its relationships.' This clearly separates it from the sibling SearchResources/List* tools without needing to name them. It stops short of explicit sibling differentiation, so a 4 rather than a 5.

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

Usage Guidelines4/5

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

It gives concrete use-case guidance: 'useful for understanding resource dependencies, such as finding which subnet an ALB is placed in or which security groups are attached to an instance.' This tells the agent when the tool is the right choice. It does not name alternatives or when-not-to-use conditions, so it falls short of a 5.

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