Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@shieldly-mcp Analyze this IAM policy for security risks: {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"","Resource":""}]}"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI-Powered Security Analysis for AWS — official MCP server.
Gives any MCP-compatible AI assistant (Claude Code, Claude Desktop, Cursor, etc.) two tools to analyze AWS IAM policies and CloudFormation templates for security risks — privilege escalation paths, wildcards, and other over-permissive access. Powered by Shieldly.
Add to your MCP client config (e.g. Claude Desktop's claude_desktop_config.json,
or Claude Code's .mcp.json):
{
"mcpServers": {
"shieldly": {
"command": "npx",
"args": ["-y", "@shieldly/mcp"]
}
}
}Related MCP server: Security-Use MCP Server
Both tools run in demo mode without an API key (rate-limited, no signup). For
higher limits, set SHIELDLY_API_KEY:
{
"mcpServers": {
"shieldly": {
"command": "npx",
"args": ["-y", "@shieldly/mcp"],
"env": { "SHIELDLY_API_KEY": "sk_live_..." }
}
}
}Get an API key (Builder plan or above): https://www.shieldly.io/app/api
analyze_iam_policyAnalyzes an IAM identity policy, or a cross-account trust+identity pair.
Argument | Type | Description |
| string | The IAM policy JSON as a string. |
|
| Defaults to |
analyze_cloudformation_templateAnalyzes a CloudFormation template — extracts IAM roles/policies and flags over-permissive access.
Argument | Type | Description |
| string | The CloudFormation template JSON as a string. |
MIT
AI-Powered security analysis of a CloudFormation template — extracts IAM roles/policies and flags over-permissive access. Runs in demo mode (rate-limited, no signup) if SHIELDLY_API_KEY is not set.
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | The CloudFormation template JSON as a string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses demo mode behavior (rate-limited, no signup) when API key is missing. However, does not specify whether the analysis is read-only, if it makes external calls, or what happens to the template data. Lacks information on side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, key actions, and demo mode behavior. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description does not explain what the analysis results contain (e.g., report format, severity levels). For a tool with one parameter and known sibling, more detail on return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 applies. Description adds no additional semantic meaning beyond what the schema already provides for the 'template' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states specific action: security analysis of CloudFormation template, extracting IAM roles/policies and flagging over-permissive access. Distinguishes from sibling analyze_iam_policy by focusing on template-level analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs the sibling analyze_iam_policy. Does not mention prerequisites or context like requiring an AWS account or template format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI-Powered security analysis of an AWS IAM policy (identity policy or cross-account trust+identity pair). Flags privilege-escalation paths, wildcards, and other over-permissive access. Runs in demo mode (rate-limited, no signup) if SHIELDLY_API_KEY is not set.
| Name | Required | Description | Default |
|---|---|---|---|
| policy | Yes | The IAM policy JSON as a string. For cross_account, a JSON object with identityPolicy and trustPolicy. | |
| policyType | No | identity (default) for a normal IAM/resource policy, or cross_account. | identity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It mentions 'demo mode (rate-limited, no signup)' and flags privilege-escalation paths, but does not disclose whether the tool is read-only, authentication requirements beyond API key, or output format. The term 'AI-Powered' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and efficiently adding context about demo mode. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, and the description does not explain the format or structure of results (e.g., what 'flags' look like, whether it returns a report, etc.). For a security analysis tool, omitting return value information is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing parameter descriptions for both 'policy' and 'policyType'. The description does not add new information beyond the schema; it merely repeats the cross-account format already present in the schema. Baseline score applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'AI-Powered security analysis of an AWS IAM policy' and specifies it handles both identity and cross-account policies. It distinguishes from the sibling tool 'analyze_cloudformation_template' which targets a different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when analyzing IAM policies and mentions demo mode conditions, but lacks explicit guidance on when not to use it or alternatives beyond the sibling tool. No comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0analyze_cloudformation_templateanalyze_iam_policyScored across 2 tools
Each tool targets a distinct resource type (CloudFormation template vs. IAM policy), with no overlap in inputs or outputs, making disambiguation trivial.
Both tools follow a consistent 'analyze_<resource>' naming pattern using snake_case, making the pattern predictable and easy to understand.
With only two tools, the set feels minimal but not unreasonable given the narrow focus on security analysis of AWS policies and templates. However, the server could benefit from a few more tools for similar resources.
The server covers two important security analysis tasks, but there are obvious gaps such as missing analysis for S3 bucket policies, KMS keys, or other IAM-related resources, limiting its practical use.
AWS cloud security scanners for AI agents — S3, IAM, EC2, EKS, RDS, CloudTrail, CloudWatch Logs
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Detects database migration table locks, terraform cost leaks, and OWASP API flaws.
