Skip to main content
Glama
Sign In
AWS MCP Server

AWS MCP Server

by marcelobrake
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

aws_ec2_describe_security_groups

Retrieve and filter AWS EC2 security group configurations to analyze network access rules, inbound/outbound permissions, and VPC associations for infrastructure management.

Instructions

Describe EC2 security groups. Filter by group IDs, names, or VPC.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aws_ec2_describe_security_groups"
  }
}

Input Schema

NameRequiredDescriptionDefault
profileNoAWS profile name from ~/.aws/config (e.g., 'default', 'production')
regionNoAWS region override (e.g., 'us-east-1', 'sa-east-1')
group_idsNoSecurity group IDs to describe
filtersNoEC2 API filters for security groups

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided, so description carries full disclosure burden. While 'Describe' implies read-only, the description does not confirm non-destructive behavior, mention AWS API rate limits, pagination behavior, or credential requirements beyond the profile parameter.

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?

Extremely concise two-sentence structure with zero waste. Front-loaded with the core purpose (Describe EC2 security groups) followed by filtering capabilities.

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?

Adequate for a read-only describe operation with 100% parameter schema coverage. However, given lack of annotations and output schema, it could benefit from mentioning read-only safety, pagination limits, or result format expectations typical of AWS describe operations.

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

Parameters4/5

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

With 100% schema coverage, baseline is 3. Description adds value by enumerating specific filter types available (group IDs, names, or VPC), providing semantic context for the 'filters' parameter beyond the schema's generic 'EC2 API filters' description.

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?

Specifies clear verb-resource pair (Describe EC2 security groups) and mentions filtering capabilities. However, it does not explicitly differentiate from sibling tool aws_ec2_describe_instances in the description text, relying instead on the tool name.

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?

Provides no guidance on when to use this tool versus alternatives like aws_ec2_describe_instances or VPC-specific tools. Does not mention that all parameters are optional despite 0 required parameters in schema.

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