Skip to main content
Glama

ec2-describe_security_groups

Retrieve AWS EC2 security group details including rules, tags, and associated resources for security auditing, compliance checks, and network troubleshooting.

Instructions

Retrieve detailed security group information with comprehensive filtering for network security analysis.

This tool provides complete security group data including ingress/egress rules, associated resources,
and tags. Critical for security auditing, compliance checking, and network troubleshooting.

**Required Parameters:**
- profile_name (str): AWS profile name from ~/.aws/credentials
- region (str): AWS region (e.g., 'us-east-1', 'eu-west-1')

**Optional Parameters:**
- group_ids (List[str]): Specific security group IDs to retrieve
  Example: ['sg-12345678', 'sg-87654321']

- group_names (List[str]): Security group names (VPC security groups use IDs, not names)
  Example: ['web-server-sg', 'database-sg']

- filters (Dict[str, Any]): Advanced filtering options
  **Basic Filters:**
  - 'group-name': ['web-server-sg', 'database-sg'] - Filter by name
  - 'group-id': ['sg-12345678'] - Filter by ID
  - 'description': ['Web server security group'] - Filter by description

  **Network Filters:**
  - 'vpc-id': ['vpc-12345678'] - Filter by VPC (most common)
  - 'owner-id': ['123456789012'] - Filter by AWS account ID

  **Rule-based Filters:**
  - 'ip-protocol': ['tcp', 'udp', 'icmp'] - Filter by protocol
  - 'from-port': [22, 80, 443] - Filter by port range start
  - 'to-port': [22, 80, 443] - Filter by port range end
  - 'cidr': ['10.0.0.0/16', '0.0.0.0/0'] - Filter by CIDR block

  **Tag Filters:**
  - 'tag:Name': ['web-tier', 'db-tier'] - Filter by Name tag
  - 'tag:Environment': ['production', 'staging'] - Filter by Environment tag
  - 'tag-key': ['Owner'] - Filter by tag key existence

- max_results (int): Limit results (5-1000). Default: no limit
- next_token (str): Pagination token from previous request

**Common Use Cases:**
1. Audit VPC security groups: filters={'vpc-id': ['vpc-12345678']}
2. Find groups allowing SSH: filters={'from-port': [22], 'to-port': [22]}
3. Security compliance check: filters={'cidr': ['0.0.0.0/0']} (find public access)
4. Find groups by tag: filters={'tag:Environment': ['production']}
5. Owner-based filtering: filters={'owner-id': ['123456789012']}

**Response includes:** Group ID, name, description, VPC ID, owner ID, ingress/egress rules
(with ports, protocols, source/destination), tags, and associated resources.

Essential for security auditing and network access control management.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionYes
profile_nameNodefault
group_idsNo
group_namesNo
filtersNo
max_resultsNo
next_tokenNo
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (retrieves security group data), what it returns (group ID, name, description, rules, tags, etc.), and includes pagination behavior via 'next_token'. However, it lacks details on error conditions, rate limits, or authentication requirements beyond profile/region parameters.

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 description is well-structured with clear sections (purpose, parameters, use cases), but is quite lengthy. While most content is valuable given the complex tool, some redundancy exists (e.g., repeating filtering examples). It could be more front-loaded with critical information before detailed parameter breakdowns.

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?

For a complex tool with 7 parameters, 0% schema coverage, and no output schema, the description does an excellent job covering parameter semantics and use cases. It describes what the response includes. However, it lacks information about error handling, rate limits, or authentication requirements, which would be valuable for a security-focused AWS tool.

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

Parameters5/5

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

Given 0% schema description coverage, the description compensates fully by providing detailed parameter information. It clearly distinguishes required vs. optional parameters, gives examples for all parameters (e.g., region format, group_ids examples), and provides extensive documentation for the complex 'filters' parameter with multiple categories and examples. This adds significant value beyond the bare schema.

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 clearly states the tool's purpose: 'Retrieve detailed security group information with comprehensive filtering for network security analysis.' It specifies the verb ('retrieve'), resource ('security group information'), and scope ('detailed' with 'comprehensive filtering'), distinguishing it from siblings like ec2-describe_instances or ec2-describe_vpcs.

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?

The description provides clear context for when to use the tool: 'Critical for security auditing, compliance checking, and network troubleshooting.' It includes 'Common Use Cases' with specific examples, but does not explicitly state when not to use it or name alternatives among sibling tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Havoc24k/aws-sa-tools-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server