Provides prescriptive guidance for building applications with AWS CDK, including search for GenAI constructs and streamlining the creation of Amazon Bedrock Agent schemas and OpenAPI specifications.
Offers documentation for AWS Lambda layers, provides implementation guidance for Python-specific layers, and integrates with AWS Lambda Powertools for security and compliance automation.
Click on "Install 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., "@AWS CDK MCP Server Find an AWS Solutions Construct pattern for S3 to Lambda"
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.
MCP server for AWS Cloud Development Kit (CDK) best practices, infrastructure as code patterns, and security compliance with CDK Nag.
Prescriptive patterns with AWS Solutions Constructs and GenAI CDK libraries
Structured decision flow for choosing appropriate implementation approaches
Security automation through CDK Nag integration and Lambda Powertools
Work with CDK Nag rules for security and compliance
Explain specific CDK Nag rules with AWS Well-Architected guidance
Check if CDK code contains Nag suppressions that require human review
Search and discover AWS Solutions Constructs patterns
Find recommended patterns for common architecture needs
Get detailed documentation on Solutions Constructs
Search for GenAI CDK constructs by name or type
Discover specialized constructs for AI/ML workloads
Get implementation guidance for generative AI applications
Access comprehensive documentation for AWS Lambda layers
Get code examples for generic Lambda layers and Python-specific layers
Retrieve directory structure information and implementation best practices
Seamless integration with AWS Documentation MCP Server for detailed documentation
Use this tool when creating Bedrock Agents with Action Groups that use Lambda functions
Streamline the creation of Bedrock Agent schemas
Convert code files to compatible OpenAPI specifications
Requirements: Your Lambda function must use BedrockAgentResolver from AWS Lambda Powertools
Lambda Dependencies: If schema generation fails, a fallback script will be generated. If you see error messages about missing dependencies, install them and then run the script again.
Integration: Use the generated schema with bedrock.ApiSchema.fromLocalAsset() in your CDK code
Related MCP server: CDK API MCP Server
This diagram provides a comprehensive view of the recommended CDK implementation workflow:
graph TD
Start([Start]) --> A["CDKGeneralGuidance"]
A --> Init["cdk init app"]
Init --> B{Choose Approach}
B -->|"Common Patterns"| C1["GetAwsSolutionsConstructPattern"]
B -->|"GenAI Features"| C2["SearchGenAICDKConstructs"]
B -->|"Custom Needs"| C3["Custom CDK Code"]
C1 --> D1["Implement Solutions Construct"]
C2 --> D2["Implement GenAI Constructs"]
C3 --> D3["Implement Custom Resources"]
%% Bedrock Agent with Action Groups specific flow
D2 -->|"For Bedrock Agents<br/>with Action Groups"| BA["Create Lambda with<br/>BedrockAgentResolver"]
%% Schema generation flow
BA --> BS["GenerateBedrockAgentSchema"]
BS -->|"Success"| JSON["openapi.json created"]
BS -->|"Import Errors"| BSF["Tool generates<br/>generate_schema.py"]
BSF -->|"Missing dependencies?"| InstallDeps["Install dependencies"]
InstallDeps --> BSR["Run script manually:<br/>python generate_schema.py"]
BSR --> JSON["openapi.json created"]
%% Use schema in Agent CDK
JSON --> AgentCDK["Use schema in<br/>Agent CDK code"]
AgentCDK --> D2
%% Conditional Lambda Powertools implementation
D1 & D2 & D3 --> HasLambda{"Using Lambda<br/>Functions?"}
HasLambda --> UseLayer{"Using Lambda<br/>Layers?"}
UseLayer -->|"Yes"| LLDP["LambdaLayerDocumentationProvider"]
HasLambda -->|"No"| SkipL["Skip"]
%% Rest of workflow
LLDP["LambdaLayerDocumentationProvider"] --> Synth["cdk synth"]
SkipL --> Synth
Synth --> Nag{"CDK Nag<br/>warnings?"}
Nag -->|Yes| E["ExplainCDKNagRule"]
Nag -->|No| Deploy["cdk deploy"]
E --> Fix["Fix or Add Suppressions"]
Fix --> CN["CheckCDKNagSuppressions"]
CN --> Synth
%% Styling with darker colors
classDef default fill:#424242,stroke:#ffffff,stroke-width:1px,color:#ffffff;
classDef cmd fill:#4a148c,stroke:#ffffff,stroke-width:1px,color:#ffffff;
classDef tool fill:#01579b,stroke:#ffffff,stroke-width:1px,color:#ffffff;
classDef note fill:#1b5e20,stroke:#ffffff,stroke-width:1px,color:#ffffff;
classDef output fill:#006064,stroke:#ffffff,stroke-width:1px,color:#ffffff;
classDef decision fill:#5d4037,stroke:#ffffff,stroke-width:1px,color:#ffffff;
class Init,Synth,Deploy,BSR cmd;
class A,C1,C2,BS,E,CN,LLDP tool;
class JSON output;
class HasLambda,UseLayer,Nag decision;CDKGeneralGuidance: Get prescriptive advice for building AWS applications with CDK
GetAwsSolutionsConstructPattern: Find vetted architecture patterns combining AWS services
SearchGenAICDKConstructs: Discover GenAI CDK constructs by name or features
GenerateBedrockAgentSchema: Create OpenAPI schemas for Bedrock Agent action groups
LambdaLayerDocumentationProvider: Access documentation for Lambda layers implementation
ExplainCDKNagRule: Get detailed guidance on CDK Nag security rules
CheckCDKNagSuppressions: Validate CDK Nag suppressions in your code
CDK Nag Rules: Access rule packs via cdk-nag://rules/{rule_pack}
AWS Solutions Constructs: Access patterns via aws-solutions-constructs://{pattern_name}
GenAI CDK Constructs: Access documentation via genai-cdk-constructs://{construct_type}/{construct_name}
Lambda Powertools: Get guidance on Lambda Powertools via lambda-powertools://{topic}
Install uv from Astral or the GitHub README
Install Python using uv python install 3.10
Install AWS CDK CLI using npm install -g aws-cdk (Note: The MCP server itself doesn't use the CDK CLI directly, but it guides users through CDK application development that requires the CLI)
Configure the MCP server in your MCP client configuration (e.g., for Amazon Q Developer CLI, edit ~/.aws/amazonq/mcp.json):
{
"mcpServers": {
"awslabs.cdk-mcp-server": {
"command": "uvx",
"args": ["awslabs.cdk-mcp-server@latest"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
},
"disabled": false,
"autoApprove": []
}
}
}or docker after a successful docker build -t awslabs/cdk-mcp-server .:
{
"mcpServers": {
"awslabs.cdk-mcp-server": {
"command": "docker",
"args": [
"run",
"--rm",
"--interactive",
"--env",
"FASTMCP_LOG_LEVEL=ERROR",
"awslabs/cdk-mcp-server:latest"
],
"env": {},
"disabled": false,
"autoApprove": []
}
}
}When using this MCP server, you should consider:
Reviewing all CDK Nag warnings and errors manually
Fixing security issues rather than suppressing them whenever possible
Documenting clear justifications for any necessary suppressions
Using the CheckCDKNagSuppressions tool to verify no unauthorized suppressions exist
Before applying CDK NAG Suppressions, you should consider conducting your own independent assessment to ensure that your use would comply with your own specific security and quality control practices and standards, as well as the local laws, rules, and regulations that govern you and your content.
Use this tool to get prescriptive CDK advice for building applications on AWS.
Args:
ctx: MCP context
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool 'gets prescriptive CDK advice' but doesn't describe what form this advice takes (e.g., text, structured data), whether it requires authentication, rate limits, or any side effects. The mention of 'ctx: MCP context' in the Args section is redundant with the input schema and doesn't add 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two sentences, but the second sentence ('Args: ctx: MCP context') is redundant given the empty input schema and doesn't add value. The first sentence clearly states the purpose, but overall structure could be improved by removing the unnecessary Args reference.
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 the tool has no parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., text advice, structured recommendations), how comprehensive the guidance is, or any limitations. For a guidance-providing tool with zero structured metadata, more behavioral context is needed.
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?
The tool has 0 parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to compensate for any parameter documentation gaps. The Args section mentioning 'ctx: MCP context' is unnecessary but doesn't detract significantly from the baseline score for a parameterless tool.
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's purpose: 'get prescriptive CDK advice for building applications on AWS.' This specifies both the verb ('get') and resource ('prescriptive CDK advice'), though it doesn't explicitly differentiate from sibling tools like 'ExplainCDKNagRule' or 'GetAwsSolutionsConstructPattern' which also provide CDK-related guidance.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts where this tool is preferred over sibling tools like 'ExplainCDKNagRule' or 'SearchGenAICDKConstructs', leaving the agent to infer usage from the general purpose statement alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if CDK code contains Nag suppressions that require human review.
Scans TypeScript/JavaScript code for NagSuppressions usage to ensure security
suppressions receive proper human oversight and justification.
Args:
ctx: MCP context
code: CDK code to analyze (TypeScript/JavaScript)
file_path: Path to a file containing CDK code to analyze
Returns:
Analysis results with suppression details and security guidance
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| file_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's scanning behavior and security oversight purpose, but doesn't mention performance characteristics, error handling, or what happens when both 'code' and 'file_path' parameters are provided/null. Some behavioral context is missing for a tool that analyzes code.
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 appropriately sized with clear sections (purpose, scanning behavior, args, returns). Every sentence adds value, though the 'Args' and 'Returns' sections could be integrated more naturally. The information is front-loaded with the core purpose stated first.
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?
For a code analysis tool with no annotations, no output schema, and 2 parameters, the description provides adequate but incomplete coverage. It explains what the tool does and the parameters, but lacks details about return format, error conditions, and the relationship between the two input parameters. The security guidance mentioned in returns is vague.
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?
With 0% schema description coverage and 2 parameters, the description adds meaningful context beyond the bare schema. It explains that 'code' contains CDK code to analyze and 'file_path' points to a file with CDK code, clarifying the dual input approach. However, it doesn't specify format requirements or mutual exclusivity rules.
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's purpose with specific verbs ('Check', 'Scans') and resources ('CDK code', 'TypeScript/JavaScript code', 'NagSuppressions usage'). It distinguishes itself from siblings by focusing on security suppression analysis rather than general guidance, rule explanation, or schema generation.
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 CDK code for security suppressions, but doesn't explicitly state when to use this tool versus alternatives like 'ExplainCDKNagRule' or 'CDKGeneralGuidance'. No exclusions or prerequisites are mentioned, leaving some ambiguity about the tool's specific context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a specific CDK Nag rule with AWS Well-Architected guidance.
CDK Nag is a crucial tool for ensuring your CDK applications follow AWS security best practices.
Basic implementation:
```typescript
import { App } from 'aws-cdk-lib';
import { AwsSolutionsChecks } from 'cdk-nag';
const app = new App();
// Create your stack
const stack = new MyStack(app, 'MyStack');
// Apply CDK Nag
AwsSolutionsChecks.check(app);
```
Optional integration patterns:
1. Using environment variables:
```typescript
if (process.env.ENABLE_CDK_NAG === 'true') {
AwsSolutionsChecks.check(app);
}
```
2. Using CDK context parameters:
```typescript
3. Environment-specific application:
```typescript
const environment = app.node.tryGetContext('environment') || 'development';
if (['production', 'staging'].includes(environment)) {
AwsSolutionsChecks.check(stack);
}
```
For more information on specific rule packs:
- Use resource `cdk-nag://rules/{rule_pack}` to get all rules for a specific pack
- Use resource `cdk-nag://warnings/{rule_pack}` to get warnings for a specific pack
- Use resource `cdk-nag://errors/{rule_pack}` to get errors for a specific pack
Args:
ctx: MCP context
rule_id: The CDK Nag rule ID (e.g., 'AwsSolutions-IAM4')
Returns:
Dictionary with detailed explanation and remediation steps
| Name | Required | Description | Default |
|---|---|---|---|
| rule_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (explains rules) and hints at output format ('detailed explanation and remediation steps'), but lacks critical behavioral details such as whether it's a read-only operation, if it requires external resources, error handling, or performance characteristics. The description adds some context but falls short for a tool with no annotation coverage.
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 poorly structured and verbose. It includes extensive code examples and implementation patterns that are irrelevant to the tool's core function of explaining rules, burying the key information. The front-loading is weak, with the purpose stated upfront but followed by distracting content. Sentences like 'CDK Nag is a crucial tool...' don't earn their place in a tool description.
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 annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers the basic purpose and parameter example but misses critical context: no details on output structure, error cases, dependencies, or integration with sibling tools. For a tool with one parameter but rich expected output ('dictionary with detailed explanation'), more completeness is needed to guide effective use.
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 0%, so the description must compensate. It provides the parameter 'rule_id' in the Args section with an example ('AwsSolutions-IAM4'), which adds meaning beyond the bare schema. However, it doesn't explain parameter constraints, format rules, or where to find valid rule IDs, leaving gaps in semantic understanding. The value added is moderate but incomplete.
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's purpose: 'Explain a specific CDK Nag rule with AWS Well-Architected guidance.' It specifies the verb ('explain') and resource ('CDK Nag rule'), though it doesn't explicitly differentiate from sibling tools like 'CDKGeneralGuidance' or 'CheckCDKNagSuppressions' which might cover related but different functionality.
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 provides no explicit guidance on when to use this tool versus alternatives. While it mentions CDK Nag's importance and includes implementation examples, it doesn't clarify scenarios where this explanation tool is preferred over other siblings like 'CheckCDKNagSuppressions' or general guidance tools. Usage is implied through the examples but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate OpenAPI schema for Bedrock Agent Action Groups from a file.
This tool converts a Lambda file with BedrockAgentResolver into a Bedrock-compatible
OpenAPI schema. It uses a progressive approach to handle common issues:
1. Direct import of the Lambda file
2. Simplified version with problematic imports commented out
3. Fallback script generation if needed
Args:
ctx: MCP context
lambda_code_path: Path to Python file containing BedrockAgentResolver app
output_path: Where to save the generated schema
Returns:
Dictionary with schema generation results, including status, path to generated schema,
and diagnostic information if errors occurred
| Name | Required | Description | Default |
|---|---|---|---|
| lambda_code_path | Yes | ||
| output_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's progressive approach to handle issues (direct import, simplified version, fallback), which adds useful behavioral context beyond basic functionality. However, it lacks details on error handling, performance, or side effects like file system changes.
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 well-structured and front-loaded with the main purpose, followed by details on the progressive approach and parameter explanations. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 the tool's complexity (converting Lambda files with a progressive approach) and no output schema, the description is mostly complete: it explains the purpose, usage, parameters, and return value structure. However, it could benefit from more details on error cases or output specifics to fully compensate for the lack of structured fields.
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?
With 0% schema description coverage, the description compensates by explaining both parameters: 'lambda_code_path' as the path to the Python file containing BedrockAgentResolver app, and 'output_path' as where to save the generated schema. This adds essential meaning beyond the bare schema, though it could specify expected formats or constraints.
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 specific verb 'Generate' and resource 'OpenAPI schema for Bedrock Agent Action Groups', specifying it converts a Lambda file with BedrockAgentResolver. It distinguishes from sibling tools by focusing on schema generation from Lambda files, unlike siblings that handle CDK guidance, nag rules, or construct patterns.
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 provides clear context for when to use this tool: when you have a Lambda file with BedrockAgentResolver and need to generate a Bedrock-compatible OpenAPI schema. It does not explicitly state when not to use it or name alternatives among siblings, but the context is sufficiently clear for its specific purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and discover AWS Solutions Constructs patterns.
AWS Solutions Constructs are vetted architecture patterns that combine multiple
AWS services to solve common use cases following AWS Well-Architected best practices.
Key benefits:
- Accelerated Development: Implement common patterns without boilerplate code
- Best Practices Built-in: Security, reliability, and performance best practices
- Reduced Complexity: Simplified interfaces for multi-service architectures
- Well-Architected: Patterns follow AWS Well-Architected Framework principles
When to use Solutions Constructs:
- Implementing common architecture patterns (e.g., API + Lambda + DynamoDB)
- You want secure defaults and best practices applied automatically
- You need to quickly prototype or build production-ready infrastructure
This tool provides metadata about patterns. For complete documentation,
use the resource URI returned in the 'documentation_uri' field.
Args:
ctx: MCP context
pattern_name: Optional name of the specific pattern (e.g., 'aws-lambda-dynamodb')
services: Optional list of AWS services to search for patterns that use them
(e.g., ['lambda', 'dynamodb'])
Returns:
Dictionary with pattern metadata including description, services, and documentation URI
| Name | Required | Description | Default |
|---|---|---|---|
| pattern_name | No | ||
| services | No |
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 (provides metadata about patterns), mentions key benefits of Solutions Constructs, and explains the return format. However, it doesn't specify whether this is a read-only operation, if there are rate limits, or authentication requirements.
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 well-structured with clear sections (overview, benefits, usage guidance, parameters, returns) and every sentence adds value. It's appropriately sized for a tool with 2 parameters and no annotations, with no redundant or unnecessary 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 the tool's moderate complexity (2 optional parameters, no output schema, no annotations), the description is quite complete. It explains purpose, usage, parameters, and return format. The only minor gap is the lack of explicit behavioral details like read-only status or error conditions, but overall it provides sufficient context for effective use.
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?
The schema description coverage is 0%, so the description must fully compensate. It provides an 'Args' section that clearly explains both parameters with concrete examples: 'pattern_name' as an optional specific pattern identifier and 'services' as an optional list to search for patterns using those services. This adds substantial value beyond the bare schema.
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's purpose as 'Search and discover AWS Solutions Constructs patterns' and provides specific context about what Solutions Constructs are. It distinguishes this tool from siblings by focusing on pattern metadata retrieval rather than guidance, rule explanation, or other CDK-related functions.
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 includes a dedicated 'When to use Solutions Constructs' section with three explicit scenarios, providing clear context for when this tool is appropriate. It also mentions that for complete documentation, users should use the returned 'documentation_uri' field, giving practical guidance on next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide documentation sources for Lambda layers.
This tool returns information about where to find documentation for Lambda layers
and instructs the MCP Client to fetch and process this documentation.
Args:
ctx: MCP context
layer_type: Type of layer ("generic" or "python")
Returns:
Dictionary with documentation source information
| Name | Required | Description | Default |
|---|---|---|---|
| layer_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool returns documentation source information and instructs the MCP Client to fetch/process documentation, but doesn't describe what the MCP Client actually does with this information, whether there are rate limits, authentication requirements, or what format the returned information takes. The description is insufficient for a tool that appears to trigger external fetching/processing.
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 appropriately concise with clear sections: purpose statement, action description, args, and returns. Each sentence serves a purpose, though the 'ctx: MCP context' parameter documentation in the Args section is redundant since it's not in the actual input schema.
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?
For a tool with no annotations, no output schema, and that appears to trigger external fetching/processing, the description is incomplete. It doesn't explain what the MCP Client does with the documentation source information, what format the returned dictionary takes, or what happens after the client fetches/processes documentation. The behavioral implications are underspecified.
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?
The description adds meaningful context for the single parameter 'layer_type' by specifying it accepts 'generic' or 'python' values. With 0% schema description coverage and only 1 parameter, this provides essential semantic information beyond the bare schema. However, it doesn't explain what distinguishes 'generic' from 'python' layers in terms of documentation sources.
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's purpose: 'Provide documentation sources for Lambda layers' and 'returns information about where to find documentation for Lambda layers'. It specifies the resource (Lambda layers) and action (provide documentation sources). However, it doesn't explicitly differentiate from sibling tools, which appear to be CDK-related rather than Lambda layer documentation tools.
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 provides no guidance on when to use this tool versus alternatives. It mentions the tool 'instructs the MCP Client to fetch and process this documentation' but doesn't specify when this is appropriate or what alternatives exist. There's no mention of prerequisites, constraints, or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for GenAI CDK constructs by name or type.
The search is flexible and will match any of your search terms (OR logic).
It handles common variations like singular/plural forms and terms with/without spaces.
Content is fetched dynamically from GitHub to ensure the most up-to-date documentation.
Examples:
- "bedrock agent" - Returns all agent-related constructs
- "knowledgebase vector" - Returns knowledge base constructs related to vector stores
- "agent actiongroups" - Returns action groups for agents
- "opensearch vector" - Returns OpenSearch vector constructs
The search supports subdirectory content (like knowledge bases and their sections)
and will find matches across all available content.
Args:
ctx: MCP context
query: Search term(s) to find constructs by name or description
construct_type: Optional filter by construct type ('bedrock', 'opensearchserverless', etc.)
Returns:
Dictionary with matching constructs and resource URIs
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| construct_type | No |
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 does an excellent job describing key behavioral traits: the search uses OR logic, handles variations (singular/plural, spacing), fetches content dynamically from GitHub, supports subdirectory content, and searches across all available content. This provides substantial operational context beyond basic functionality. The only minor gap is not mentioning potential rate limits or authentication requirements.
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 well-structured and appropriately sized. It starts with the core purpose, then explains behavioral characteristics, provides concrete examples, and ends with parameter and return documentation. Every sentence adds value, though the 'Args' and 'Returns' sections could be integrated more seamlessly into the narrative flow rather than appearing as separate labeled sections.
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 the tool's moderate complexity (search with flexible matching), no annotations, and no output schema, the description provides excellent coverage. It explains the search behavior, parameters, and return format. The only gap is that without an output schema, the description could provide more detail about the structure of the returned dictionary (what fields it contains beyond 'matching constructs and resource URIs').
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?
The schema description coverage is 0%, so the description must fully compensate. It successfully adds rich meaning beyond the schema: it explains that 'query' searches by name or description with flexible matching, provides multiple examples of how queries work, and clarifies that 'construct_type' is an optional filter with examples of possible values ('bedrock', 'opensearchserverless'). This completely documents both parameters' semantics and usage patterns.
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 searches for GenAI CDK constructs by name or type, providing a specific verb ('Search') and resource ('GenAI CDK constructs'). It distinguishes itself from sibling tools like 'GenerateBedrockAgentSchema' or 'GetAwsSolutionsConstructPattern' by focusing on search functionality rather than generation or pattern retrieval. However, it doesn't explicitly contrast with all siblings (e.g., 'CDKGeneralGuidance'), leaving some room for improvement.
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 provides clear context for when to use this tool: when searching for constructs by name or description, with optional type filtering. It includes multiple concrete examples that illustrate appropriate use cases. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools, which would elevate the score to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes focused on different aspects of CDK development: guidance, security analysis, construct discovery, and documentation. However, 'ExplainCDKNagRule' and 'CheckCDKNagSuppressions' both relate to CDK Nag security analysis and could potentially overlap in usage scenarios, though their specific functions differ (rule explanation vs. suppression checking).
The naming is highly inconsistent with multiple patterns: 'CDKGeneralGuidance' (CamelCase), 'CheckCDKNagSuppressions' (CamelCase with verb prefix), 'ExplainCDKNagRule' (CamelCase with verb prefix), 'GenerateBedrockAgentSchema' (CamelCase with verb prefix), 'GetAwsSolutionsConstructPattern' (CamelCase with verb prefix), 'LambdaLayerDocumentationProvider' (CamelCase), and 'SearchGenAICDKConstructs' (CamelCase with verb prefix). There's no unified naming convention across the toolset.
With 7 tools, the count is reasonable for a CDK-focused server. The tools cover guidance, security analysis, construct discovery, and documentation - a well-scoped set that doesn't feel overly sparse or bloated. However, the scope is somewhat broad (covering both general CDK and specific GenAI/Bedrock constructs), which slightly reduces the appropriateness.
The toolset covers several important CDK areas: guidance, security analysis (Nag), construct discovery (Solutions Constructs and GenAI constructs), and documentation. However, there are notable gaps in core CDK operations - no tools for actually deploying, synthesizing, or managing CDK stacks/applications. The focus is heavily on advisory and discovery functions rather than operational capabilities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Unified API to query AWS, GCP, Azure and generate Terraform/CLI execution kits for AI agents.
Public agentic AI doctrine tools plus authenticated architecture, design, and spec validators.
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AkM-2018/tmp_cdk_mcp_server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
