Skip to main content
Glama
Sign In
AWS MCP Server

AWS MCP Server

by marcelobrake
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

aws_iam_list_roles

Retrieve and filter IAM roles in your AWS account to manage access permissions and audit security configurations.

Instructions

List IAM roles in the AWS account with optional path prefix filter.

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_iam_list_roles"
  }
}

Input Schema

NameRequiredDescriptionDefault
profileNoAWS profile name from ~/.aws/config (e.g., 'default', 'production')
regionNoAWS region override (e.g., 'us-east-1', 'sa-east-1')
path_prefixNoIAM path prefix filter (default: '/')
max_itemsNoMaximum number of roles to return

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions the 'optional path prefix filter' capability, implying filtering behavior, but does not explicitly state the read-only/non-destructive nature of the operation, pagination behavior (despite max_items parameter), or the structure/format of returned role data.

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 single-sentence description is appropriately front-loaded with the action ('List IAM roles') and efficiently packs in the scope ('in the AWS account') and key filtering capability without redundancy. It is appropriately sized for the tool's complexity, though slightly more behavioral context would justify a fifth sentence.

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?

Given the absence of annotations and output schema, the description adequately covers the core purpose but leaves gaps regarding return value structure (e.g., does it return ARN, name, or full trust policy?), pagination continuation, and error conditions. It meets minimum viability for a simple list operation but lacks richness expected when structured metadata is missing.

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?

The input schema has 100% description coverage (all 4 parameters documented), establishing a baseline of 3. The description mentions 'optional path prefix filter' which reinforces the schema but adds no new semantic information about parameter usage, valid path formats, or interaction between max_items and implicit pagination.

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 clearly states the specific action ('List') and resource ('IAM roles') being operated on, and scopes it to 'the AWS account'. It implicitly distinguishes from sibling IAM list tools (aws_iam_list_users, aws_iam_list_policies) by specifying 'roles', though it does not explicitly name them as alternatives in the description text.

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?

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as AWS credentials configuration, required IAM permissions (e.g., iam:ListRoles), or when filtering by path_prefix is appropriate versus listing all roles.

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