AWS CDK MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation4/5
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).
Naming Consistency2/5
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.
Tool Count4/5
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.
Completeness3/5
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.
Average 3.6/5 across 7 of 7 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness2/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
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. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose 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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tmp_cdk_mcp_server MCP server](https://glama.ai/mcp/servers/AkM-2018/tmp_cdk_mcp_server/badges/card.svg)](https://glama.ai/mcp/servers/AkM-2018/tmp_cdk_mcp_server)

Score Badge

Copy to your README.md:

[![tmp_cdk_mcp_server MCP server](https://glama.ai/mcp/servers/AkM-2018/tmp_cdk_mcp_server/badges/score.svg)](https://glama.ai/mcp/servers/AkM-2018/tmp_cdk_mcp_server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AkM-2018/tmp_cdk_mcp_server'

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