Skip to main content
Glama
awslabs

AWS SRA Verify MCP Server

Official
by awslabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

AWS SRA Verify MCP Server

An MCP server for SRA Verify, a tool that assesses your AWS environment against the AWS Security Reference Architecture (SRA). It uses SRA Verify security checks as MCP tools, letting AI agents discover, describe, and run best practice checks for services like GuardDuty, CloudTrail, IAM, and Security Hub across your Organization's accounts.

What It Does

SRA Verify validates that native AWS security services are properly configured at scale across your AWS Organization. It checks multiple account types - management, audit, log-archive, and application and returns detailed pass/fail findings for each security control.

Security and Compliance is a shared responsibility between AWS and the customer. SRA Verify and the SRA Verify MCP server may help a customer implement controls and best practices on the customer side of the shared responsibility model. Visit the Shared Responsibility Model to learn more.

MCP Tools

Tool

Description

list_services

List all AWS services supported by SRA Verify

list_checks_by_service

Get checks for a specific service (e.g., GuardDuty, CloudTrail, IAM)

list_checks_by_account_type

Get checks filtered by account type (management, audit, log-archive, application, all)

describe_check

Get detailed info about a specific check including severity and requirements

run_check

Execute a security check and return findings with pass/fail status

Supported Services

SRA Verify covers a wide range of AWS security services including: Access Analyzer, Audit Manager, CloudTrail, CloudWatch, Config, GuardDuty, IAM, Inspector, Macie, Organizations, S3, Security Hub, Security Lake, Shield, WAF, and more. Review the full list of checks on the SRA Verify Github.

Note: SRA Verify contains checks for several services, but may not contain a check for every consideration of the AWS Security Reference Architecture. Review the AWS Prescriptive Guidance for more information on AWS Security Reference Architecture.

Related MCP server: AWS Compliance MCP Server

Prerequisites

  • Python 3.10+

  • uv package manager

  • AWS credentials with appropriate read permissions for security services

  • Access to an AWS Organization with SRA account structure (management, audit, log-archive accounts)

Cross-Account Role Setup

To scan member accounts in your AWS Organization, SRA Verify needs an IAM role deployed to each account it will assess. The included 1-sraverify-mcp-roles.yaml CloudFormation template creates this role with least-privilege permissions.

Note: You should use least privilege to restrict the AI agent permissions. The example provided is least-privilege read-only commands, but you should review and update to meet your organizations policies.

Deploy via CloudFormation

Use CloudFormation StackSets to deploy the role across your organization:

  1. Navigate to CloudFormation > StackSets in your management account

  2. Choose Create StackSet and upload 1-sraverify-mcp-roles.yaml

  3. Set the Role parameter to the ARN of the IAM role or user that will run SRA Verify (the principal your AWS profile authenticates as)

  4. Deploy to your target accounts (or the entire organization)

The template creates:

  • SRAMemberMCPRole — an IAM role that SRA Verify assumes in each account

  • SRAVerifyMCPLeastPrivilege — a managed policy with read-only permissions scoped to the AWS services SRA Verify checks

  • SRAVerifyMCPCheckPermissions — additional permissions for account-level checks

The role's trust policy allows only the principal you specify in the Role parameter to assume it.

Note: StackSets don't apply to the management account. You must also deploy 1-sraverify-mcp-roles.yaml as a standalone CloudFormation template to your management account.

Setup

Kiro CLI (Agent Mode)

Create a Custom Agent (Optional)

You can create a dedicated SRA Verify agent for quick access:

Open Kiro or VS Code to create a new agent configuration file.

kiro ~/.kiro/agents/sra.json

Enter the following example configuration file. Update "/path/to/sra-verify-mcp/awslabs/sraverify_mcp_server/" with the absolute path to your cloned repository.

{
  "name": "sra",
  "description": "AWS Security Reference Architecture compliance checker",
  "prompt": "You are an AWS security expert specializing in SRA compliance validation. Use the SRA Verify MCP tools to help users assess their AWS environment against security best practices. When users ask about security checks, proactively discover available checks, explain what they validate, and run them with the appropriate account IDs and parameters. Always provide clear summaries of findings with actionable recommendations.",
  "mcpServers": {
    "awslabs.sraverify-mcp-server": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/sra-verify-mcp/awslabs/sraverify_mcp_server/",
        "run",
        "server.py"
      ],
      "disabled": false,
      "env": {
        "AWS_PROFILE": "my-profile" //Optional, you can remove this to use your default AWS credential chain
      }
    }
  },
  "tools": [
    "*"
  ],
  "toolAliases": {},
  "allowedTools": [
    "@awslabs.sraverify-mcp-server/list*",
    "@awslabs.sraverify-mcp-server/describe*"
  ],
  "resources": [],
  "hooks": {},
  "toolsSettings": {},
  "useLegacyMcpJson": true,
  "model": null
}

Alternatively, you can run directly with uvx.

{
  "name": "sra",
  "description": "AWS Security Reference Architecture compliance checker",
  "prompt": "You are an AWS security expert specializing in SRA compliance validation. Use the SRA Verify MCP tools to help users assess their AWS environment against security best practices. When users ask about security checks, proactively discover available checks, explain what they validate, and run them with the appropriate account IDs and parameters. Always provide clear summaries of findings with actionable recommendations.",
  "mcpServers": {
    "awslabs.sraverify-mcp-server": {
      "command": "uvx",
      "args": [
        "sraverify-mcp"
      ],
      "disabled": false
    }
  },
  "tools": [
    "*"
  ],
  "toolAliases": {},
  "allowedTools": [
    "@awslabs.sraverify-mcp-server/list*",
    "@awslabs.sraverify-mcp-server/describe*"
  ],
  "resources": [],
  "hooks": {},
  "toolsSettings": {},
  "useLegacyMcpJson": true,
  "model": null
}

You can update my-profile with the AWS CLI profile that has permissions to assume the SRAMemberMCPRole, or remove it to use your default AWS credentials.

To invoke the agent, include --agent sra when starting a new chat.

kiro-cli chat --agent sra

Usage Examples

Kiro CLI Agent Prompts

Note: These prompts are provided as an example. Generative AI is non deterministic and you may get different results. Always use least privilege and human-in-the-loop to prevent unwanted changes.

Once configured, you can use natural language prompts with the Kiro CLI agent:

Discovery:

[sra] > List all AWS services that SRA Verify can check
Running tool list_checks_by_account_type with the param (from mcp server: awslabs.sraverify-mcp-server)
 ⋮  {
 ⋮    "account_type": "all"
 ⋮  }
 - Completed in 0.16s

> SRA Verify can check the following 17 AWS services:

1. Account
2. AuditManager
3. CloudTrail
4. Config
5. EC2
6. FirewallManager
7. GuardDuty
8. IAM Access Analyzer
9. Inspector
10. Macie
11. Organizations
12. S3
13. SecurityHub
14. SecurityIncidentResponse
15. SecurityLake
16. Shield
17. WAF

Would you like to see the available checks for any specific service?
[sra] > Show me all GuardDuty checks available
Running tool list_checks_by_service with the param (from mcp server: awslabs.sraverify-mcp-server)
 ⋮  {
 ⋮    "service": "GuardDuty"
 ⋮  }
 - Completed in 0.14s

> Here are all 25 GuardDuty checks available in SRA Verify:

## Application Account Checks (12)
Core Configuration:
- **SRA-GUARDDUTY-01** (HIGH) - GuardDuty detector exists
- **SRA-GUARDDUTY-02** (LOW) - GuardDuty finding frequency is set
- **SRA-GUARDDUTY-03** (HIGH) - GuardDuty detector is enabled

Data Sources:
- **SRA-GUARDDUTY-04** (MEDIUM) - DNS logs enabled
- **SRA-GUARDDUTY-05** (MEDIUM) - VPC flow logs enabled
- **SRA-GUARDDUTY-08** (HIGH) - CloudTrail logs enabled

Protection Features:
- **SRA-GUARDDUTY-06** (HIGH) - S3 protection enabled
- **SRA-GUARDDUTY-07** (HIGH) - EKS protection enabled
- **SRA-GUARDDUTY-09** (HIGH) - Malware protection for EBS enabled
- **SRA-GUARDDUTY-10** (HIGH) - RDS protection enabled
- **SRA-GUARDDUTY-11** (HIGH) - EKS runtime protection enabled
- **SRA-GUARDDUTY-12** (HIGH) - Lambda protection enabled

Agent Management:
- **SRA-GUARDDUTY-17** (HIGH) - EKS addon management enabled
- **SRA-GUARDDUTY-18** (HIGH) - ECS Fargate agent management enabled
- **SRA-GUARDDUTY-19** (HIGH) - EC2 agent management enabled

## Management Account Checks (2)
- **SRA-GUARDDUTY-13** (HIGH) - Service administration delegated
- **SRA-GUARDDUTY-14** (HIGH) - Delegated admin is audit account

## Audit Account Checks (7)
Organization-Wide Configuration:
- **SRA-GUARDDUTY-15** (HIGH) - Auto-enablement configured
- **SRA-GUARDDUTY-16** (HIGH) - Member account limit not reached

Auto-Enablement for Features:
- **SRA-GUARDDUTY-20** (HIGH) - S3 data events auto-enablement configured
- **SRA-GUARDDUTY-21** (HIGH) - EBS Malware Protection auto-enablement configured
- **SRA-GUARDDUTY-22** (HIGH) - EKS Audit Logs auto-enablement configured
- **SRA-GUARDDUTY-23** (HIGH) - Runtime Monitoring auto-enablement configured
- **SRA-GUARDDUTY-24** (HIGH) - Lambda Network Logs auto-enablement configured
- **SRA-GUARDDUTY-25** (HIGH) - RDS Login Events auto-enablement configured

Running Checks:

[sra] > Run SRA-GUARDDUTY-01 check for audit account 123456789012 using role SRAMemberMCPRole

Running tool run_check with the param (from mcp server: awslabs.sraverify-mcp-server)
 ⋮  {
 ⋮    "check_id": "SRA-GUARDDUTY-01",
 ⋮    "audit_accounts": [
 ⋮      "123456789012"
 ⋮    ],
 ⋮    "log_archive_accounts": null,
 ⋮    "role_arn": "arn:aws:iam::123456789012:role/SRAMemberMCPRole"
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[sra] > y

 - Completed in 11.689s

> ## SRA-GUARDDUTY-01 Check Results

Account: 123456789012 (Code Prod)
Status: Completed with 1 failure

### Summary
- ✅ Passed: 16 regions
- ❌ Failed: 1 region
- **Total:** 17 regions checked

### Failed Region
ap-northeast-3 (HIGH severity)
- **Issue:** GuardDuty detector does not exist
- **Remediation:** Enable GuardDuty in ap-northeast-3

### Passing Regions
GuardDuty detectors are properly configured in:
- ap-south-1, eu-north-1, eu-west-3, eu-west-2, eu-west-1
- ap-northeast-2, ap-northeast-1, ca-central-1, sa-east-1
- ap-southeast-1, ap-southeast-2, eu-central-1
- us-east-1, us-east-2, us-west-1, us-west-2

### Recommendation
Enable GuardDuty in ap-northeast-3 to ensure comprehensive threat detection coverage across all AWS regions, even those not actively used for workloads. This prevents blind spots where unauthorized activity could go undetected.

 ▸ Time: 28s

Comprehensive Validation:

[sra] > Run all GuardDuty checks for my audit account 123456789012 in us-east-1 and summarize the results

Running tool run_check with the param (from mcp server: awslabs.sraverify-mcp-server)
 ⋮  {
 ⋮    "audit_accounts": [
 ⋮      "123456789012"
 ⋮    ],
 ⋮    "check_id": "SRA-GUARDDUTY-01",
 ⋮    "region": "us-east-1"
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[sra] > y

Running tool run_check with the param (from mcp server: awslabs.sraverify-mcp-server)
 ⋮  {
 ⋮    "audit_accounts": [
 ⋮      "123456789012"
 ⋮    ],
 ⋮    "check_id": "SRA-GUARDDUTY-02",
 ⋮    "region": "us-east-1"
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[sra] > y

Running tool run_check with the param (from mcp server: awslabs.sraverify-mcp-server)
 ⋮  {
 ⋮    "audit_accounts": [
 ⋮      "123456789012"
 ⋮    ],
 ⋮    "check_id": "SRA-GUARDDUTY-03",
 ⋮    "region": "us-east-1"
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

[sra] > y

 - Completed in 1.150s

 - Completed in 1.65s

 - Completed in 1.592s

_truncated the other 22 run_check calls_

> ## GuardDuty Security Assessment Summary

Account: 123456789012 (Audit)
Region: us-east-1
Total Checks: 25

### Overall Results
- ✅ Passed: 23 checks (92%)
- ❌ Failed: 1 check (4%)
- ⚠️ Errors: 1 check (4%)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


### Critical Issues

❌ FAILED - SRA-GUARDDUTY-13: GuardDuty service administration NOT delegated (HIGH)
- **Issue:** GuardDuty service administration is not delegated to any account
- **Impact:** Lack of centralized management reduces security visibility and control across the organization
- **Remediation:** Delegate GuardDuty administration to the audit account (123456789012) from the management account using AWS Organizations

⚠️ ERROR - SRA-GUARDDUTY-14: Cannot verify delegated admin configuration (HIGH)
- **Issue:** BadRequestException when accessing GuardDuty organization information
- **Impact:** Cannot verify if the delegated admin is properly configured as the audit account
- **Remediation:** Check IAM permissions and AWS Organizations configuration

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


### Passing Checks Summary

✅ Core Configuration (3/3)
- Detector exists
- Detector is enabled
- Finding frequency set (SIX_HOURS)

✅ Data Sources (3/3)
- DNS logs enabled
- VPC flow logs enabled
- CloudTrail logs enabled

✅ Protection Features (6/6)
- S3 protection enabled
- EKS protection enabled
- Malware protection for EBS enabled
- RDS protection enabled
- EKS runtime protection enabled
- Lambda protection enabled

✅ Agent Management (3/3)
- EKS addon management enabled
- ECS Fargate agent management enabled
- EC2 agent management enabled

✅ Organization Configuration (7/7)
- Auto-enablement configured for new accounts
- Member account limit not reached
- S3 data events auto-enablement configured
- EBS Malware Protection auto-enablement configured
- EKS Audit Logs auto-enablement configured
- Runtime Monitoring auto-enablement configured
- Lambda Network Logs auto-enablement configured
- RDS Login Events auto-enablement configured

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


### Key Recommendations

1. Critical: Delegate GuardDuty administration to this audit account from the management account to enable centralized security management across the
organization

2. Investigate: Resolve the permissions error for organization-level checks (SRA-GUARDDUTY-14)

3. Optional: Consider changing finding frequency from 6 hours to 15 minutes or 1 hour for faster threat response in critical environments

Your GuardDuty configuration is excellent with comprehensive protection features, all data sources enabled, and proper auto-enablement policies for new
accounts. The primary gap is the missing delegated administration setup.

 ▸ Time: 1m 47s

Kiro IDE (Power)

Note: These prompts are provided as an example. Generative AI is non deterministic and you may get different results. Always use least privilege and human-in-the-loop to prevent unwanted changes.

The SRA Verify Power bundles the MCP server with onboarding workflows and steering files for a guided experience.

Install the Power

  1. Open Kiro IDE

  2. Before installing the power, update the path/to/sra-verify-mcp/awslabs/sraverify_mcp_server/ in mcp.json with the absolute path to your cloned repository.

  3. Open the Powers panel (choose the Powers icon in the sidebar or use the Command Palette: Kiro: Open Powers)

  4. Choose Add Custom Power.

  5. Choose Import power from a folder.

  6. Select /path/to/powers/sra-verify

Configure Your AWS Profile

After installing the power, update the AWS profile in the MCP configuration:

  1. Open ~/.kiro/settings/mcp.json in your workspace. You can also choose the edit button next to MCP Servers in the Kiro tab.

  2. Find the AWS_PROFILE value — it defaults to SRA_VERIFY_MCP_PROFILE_NAME

  3. Replace SRA_VERIFY_MCP_PROFILE_NAME with your actual AWS CLI profile name:

{
  "mcpServers": {
    "power-sra-verify-awslabs.sraverify-mcp-server": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/sra-verify-mcp/awslabs/sraverify_mcp_server/",
        "run",
        "server.py"
      ],
      "disabled": false,
      "env": {
        "AWS_PROFILE": "my-profile" // Update this profile
      }
    }
  }
}

Run Onboarding

Once the power is installed and configured, use this prompt in Kiro chat to walk through the interactive setup:

I just installed SRA Verify power and want to set it up

The onboarding workflow will:

  • Discover your AWS accounts automatically (or collect them manually)

  • Identify your management, audit, and log-archive accounts

  • Detect your active AWS regions

  • Configure your cross-account role ARN

  • Save everything to a steering file for future use

Kiro IDE Chat Prompts

In Kiro IDE with the power installed you can use natural language prompts. You don't have to be as specific because the steering file gives Kiro additional context.

                                    Check my Researcher account for GuardDuty 03

Kiro
> Including Steering Documents sra-verify-environment.md

I'll check the Researcher01 account for GuardDuty check 03. Let me first activate the sra-verify power and then run the check.

> Activated Kiro power sra-verify

Now I'll run the GuardDuty check 03 for the Researcher01 account. Let me first describe the check to understand what it validates, then run it.

> Used Kiro power sra-verify describe_check

> Used Kiro power sra-verify run_check

Great news! The GuardDuty check 03 passed for your Researcher01 account.

Check Results:

Status: PASS ✓
Account: Researcher01 (123456789012)
Region: us-east-1
Severity: HIGH
What was checked: This validates that the GuardDuty detector is enabled in the account. The detector represents the GuardDuty service in the specific region - if disabled, it won't provide threat intelligence.

Finding:

Detector status is ENABLED
Detector ID: 02bf72b27729788EXAMPLE06a31eb
No remediation needed
Your Researcher01 account has GuardDuty properly enabled and running in us-east-1.

Next steps

Think about how you can use this with your other MCP servers and workflows.

  • Add ticket system MCP to automatically create tickets for failed findings.

  • Use the AWS MCP Server to reference AWS documentation and make AWS API calls

  • Ask for remediation guidance, code samples, CloudFormation templates to fix failed findings.

Available Tools

5 tools
describe_checkA

Get detailed information about a specific check.

Args: check_id: The check ID (e.g., 'SRA-GUARDDUTY-01')

Returns: Dictionary with check details including name, service, account_type, description, severity

ParametersJSON Schema
NameRequiredDescriptionDefault
check_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

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

With no annotations provided, the description should disclose behavioral traits. It minimally mentions that the tool returns a dictionary with details, but does not address authentication, rate limits, side effects, or whether it is safe/read-only. This is insufficient for a read operation.

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?

The description is very concise: one line summary, followed by Args and Returns sections. Every sentence adds value, and the structure is clear and easy to parse.

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?

Given that an output schema exists, the description adequately summarizes the return fields (name, service, etc.) without needing to restate the schema. For a simple tool with one parameter, it covers the essential information, though it could reference the output schema for exact structure.

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?

The input schema only specifies 'check_id' as a string with a title. The description adds significant value by providing an example format ('SRA-GUARDDUTY-01'), which helps agents understand the expected format. Schema description coverage is 0%, so the example compensates well.

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 action 'Get detailed information' and the resource 'specific check'. It distinguishes itself from sibling tools like 'list_checks_by_account_type' and 'run_check' by focusing on a single check's details.

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

Usage Guidelines3/5

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

The description implies usage when you have a check_id and need details, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. The example format provides some guidance.

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

list_checks_by_account_typeA

Get all checks filtered by account type.

Args: account_type: Filter by account type ('application', 'audit', 'log-archive', 'management', 'all')

Returns: Dictionary mapping check IDs to check information

ParametersJSON Schema
NameRequiredDescriptionDefault
account_typeNoall

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided, so the description carries full burden. It only states the function and return format but discloses no behavioral traits such as ordering, pagination, error conditions, or permissions.

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?

Very concise (two sentences plus a Return line), front-loaded with purpose. Every sentence adds value; no wasted words.

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 simple tool with one optional parameter and a clear return type (dictionary), the description is nearly complete. It explains the filter and output format. Could mention that account_type defaults to 'all' (from schema), but that is minor.

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?

Schema description coverage is 0%, but the description adds allowed values ('application', 'audit', 'log-archive', 'management', 'all') that are not present in the input schema (no enum). This adds meaningful constraint beyond the 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 states 'Get all checks filtered by account type' which uses a specific verb and resource, and distinguishes from siblings like list_checks_by_service (filter by service) and describe_check (describe single check).

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?

No explicit guidance on when to use this tool versus alternatives like list_checks_by_service or describe_check. The description only lists allowed values for account_type but does not provide context for selection.

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

list_checks_by_serviceA

Get all checks filtered by service.

Args: service: Filter by service name (e.g., 'GuardDuty', 'CloudTrail', 'IAM')

Returns: Dictionary mapping check IDs to check information for the specified service

ParametersJSON Schema
NameRequiredDescriptionDefault
serviceYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It describes the return format as a dictionary mapping check IDs to check information, but it does not mention potential side effects, authentication needs, or rate limits. The tool is a simple list operation, so the description is adequate but not rich.

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?

The description is extremely concise with a single-sentence purpose followed by short args and returns sections. It is front-loaded and free of unnecessary words, earning its place with every sentence.

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?

Given the tool's simplicity (single parameter, output schema provided), the description adequately covers purpose, parameter semantics, and return structure. However, it lacks guidance on error conditions or usage context, which would make it fully complete.

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?

The input schema provides only the parameter name and type with no description. The description adds meaning by stating 'Filter by service name (e.g., 'GuardDuty', 'CloudTrail', 'IAM')', giving examples that help the agent understand valid values. This compensates for the zero schema description coverage.

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 'Get all checks filtered by service', which is a specific verb and resource. It further specifies the filtering criterion, distinguishing it from sibling tools like 'list_checks_by_account_type' and 'describe_check'.

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

Usage Guidelines3/5

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

The description implies usage when needing checks for a specific service but does not explicitly state when to use this tool versus alternatives like 'list_checks_by_account_type'. There is no guidance on when not to use it or mention of prerequisites.

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

list_servicesA

Get all services supported by SRA Verify.

Returns: Dictionary containing the list of supported services.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

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

No annotations provided, so the description carries full burden. It states it returns a dictionary but does not disclose that it is a read-only operation, any authentication requirements, or potential side effects. Minimal behavioral context.

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?

Two sentences, front-loaded with purpose, no wasted words. Perfectly concise for a simple tool with no parameters.

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 no annotations and no output schema details, the description is adequate but not thorough. While the tool is simple, missing information like whether the list is static or if any permissions are needed lowers completeness.

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?

No parameters exist. The description confirms return type ('Dictionary'). Schema coverage is 100%, and the description adds value by explaining the output, justifying a baseline 4.

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 explicitly states 'Get all services supported by SRA Verify,' which is a specific verb+resource combination. It clearly distinguishes from sibling tools that deal with checks, not services.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. However, since sibling tools are about checks, the usage context is implied. A score of 3 reflects adequate but missing explicit recommendations.

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

run_checkA

Run a security check and return results.

Args: check_id: The check ID to run (e.g., 'SRA-GUARDDUTY-01') audit_accounts: List of AWS accounts used for Audit/Security Tooling (required for some checks) log_archive_accounts: List of AWS accounts used for Logging (required for some checks) role_arn: Optional IAM role ARN to assume for running the check region: Optional AWS region to target (if not specified, checks all regions)

Returns: Dict with findings and summary, or error if check fails.

ParametersJSON Schema
NameRequiredDescriptionDefault
check_idYes
audit_accountsNo
log_archive_accountsNo
role_arnNo
regionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

Without annotations, the description discloses return format (Dict with findings/summary or error), parameter behaviors (e.g., region defaults to all), and conditional requirements for audit/log accounts. It does not explicitly state read-only or destructive nature, but the context of a security check implies mutation is unlikely.

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?

The description is concise with clear Args and Returns sections. Every sentence adds value without redundancy, and the structure facilitates quick scanning for key details.

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?

Given 5 parameters, conditional requirements, and an output schema, the description covers the tool's behavior and return values well. Minor gap: it could mention prerequisites like permissions or that some checks may require specific account types, but sibling tools handle listing details.

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?

Schema description coverage is 0%, but the description fully explains each parameter: check_id with example, audit_accounts/log_archive_accounts with context, role_arn as optional, region with default behavior. This adds significant meaning beyond the raw 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 performs 'Run a security check and return results,' which is a specific verb and resource. It distinguishes from siblings that describe, list, or manage checks.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus siblings like describe_check or list_checks. The usage is implied by the tool's action, but no when-not-to-use or alternative suggestions are provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.0.1
    • First observeddescribe_check
    • First observedlist_checks_by_account_type
    • First observedlist_checks_by_service
    • First observedlist_services
    • First observedrun_check
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: describing a specific check, listing checks by account type, listing checks by service, listing all services, and running a check. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., describe_check, list_checks_by_account_type). No deviations.

Tool Count5/5

Five tools is well-scoped for a security verification server, covering needs to list, describe, and run checks without excess or deficiency.

Completeness4/5

The set covers listing (by service and account type), describing, and running checks. A minor gap is the lack of a dedicated tool to retrieve historical results, but the core lifecycle is covered.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • AWS MCP Audit

    oldcoder01
    F
    license
    D
    quality
    D
    maintenance
    Enables read-only assessment of AWS environments by inventorying resources, running security and operational checks, and generating actionable reports with cost analysis. Designed for contractors with support for assume-role authentication using external IDs.
    10
    -

  • AWS Compliance MCP Server

    aditya0529
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables LLMs to perform automated compliance scanning of AWS infrastructure against PCI-DSS, CIS, and Well-Architected frameworks. It provides tools for scanning, remediation, and audit report generation.
    MIT

  • Cinch MCP Server

    nirhalfon
    A
    license
    A
    quality
    B
    maintenance
    Enables MCP-compatible agents to query security checklists, protocols, and framework mappings to safely build and operate AI agents, with tools for checklist runs, protocol lookup, mapping lookup, and threat search.
    9
    CC BY-4.0