Keyway MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: diff compares environments, generate creates secrets, inject_run executes commands, list_environments and list_secrets retrieve metadata, scan detects leaks, set_secret modifies data, and validate checks completeness. The descriptions make it impossible to confuse any two tools.
Naming Consistency5/5
All tools follow a consistent 'keyway_verb_noun' pattern with snake_case throughout (e.g., keyway_diff, keyway_generate, keyway_inject_run). This predictable naming scheme makes it easy for agents to understand and select the right tool based on its function.
Tool Count5/5
With 8 tools, this server is well-scoped for secret management, covering essential operations like listing, setting, generating, validating, scanning, and injecting secrets, as well as environment comparison. Each tool serves a unique and necessary function without redundancy.
Completeness5/5
The toolset provides complete coverage for secret management workflows: CRUD operations (list, set, generate), environment handling (list, diff), security (scan, validate), and runtime integration (inject_run). There are no obvious gaps, enabling agents to handle the full lifecycle of secrets in this domain.
Average 3.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
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 states the tool compares secrets to find differences, but doesn't describe what 'differences' entail (e.g., missing, mismatched, or extra secrets), whether it's read-only or has side effects, or any constraints like rate limits or authentication needs. This leaves significant gaps for a tool that likely accesses sensitive data.
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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple comparison tool, making it easy to parse quickly.
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 complexity of comparing secrets across environments, the description is incomplete. With no annotations, no output schema, and minimal behavioral details, it fails to explain what the comparison outputs (e.g., a list of differences, a summary) or any error conditions. This leaves the agent guessing about the tool's behavior and results.
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 100%, with clear descriptions for both parameters ('env1' and 'env2'). The description adds minimal value beyond the schema, as it only implies the parameters are environment names without specifying format or examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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: 'Compare secrets between two environments to find differences.' It specifies the verb ('compare'), resource ('secrets'), and scope ('between two environments'). However, it doesn't explicitly differentiate from sibling tools like 'keyway_list_secrets' or 'keyway_scan', which might also involve secret inspection.
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 prerequisites, such as whether environments must exist or be accessible, or compare it to siblings like 'keyway_list_secrets' for single-environment views. Usage is implied by the purpose but lacks explicit context or exclusions.
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 mentions what the tool detects but lacks details on permissions needed, whether it's read-only or destructive, rate limits, output format, or error handling. For a scanning tool with potential security implications, this is a significant gap in transparency.
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 a single, efficient sentence that front-loads the core action ('Scan the codebase') and specifics ('Detects AWS keys...'). There is no wasted verbiage, making it highly concise and well-structured for quick understanding.
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 complexity of a scanning tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list of findings, report format), error conditions, or behavioral traits like whether it's safe or has side effects. This leaves gaps for an agent to invoke the tool effectively.
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 100%, so the schema already documents both parameters ('path' and 'exclude') with descriptions. The description adds no additional parameter semantics beyond implying scanning occurs in a codebase, which is covered by the schema's 'path' description. This meets the baseline for high schema coverage.
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 with a specific verb ('Scan') and resource ('codebase'), specifying what it detects (AWS keys, GitHub tokens, etc.). It distinguishes from siblings like 'keyway_list_secrets' or 'keyway_set_secret' by focusing on scanning rather than listing or setting. However, it doesn't explicitly differentiate from all siblings (e.g., 'keyway_validate' might also involve scanning), keeping it from a perfect score.
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 prerequisites, exclusions, or compare to siblings like 'keyway_validate' or 'keyway_list_secrets', leaving the agent with minimal context for selection. This lack of explicit usage instructions results in a low score.
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 action but does not cover traits like read-only vs. destructive nature, authentication needs, rate limits, or response format. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple tool with no parameters, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks depth. It covers the basic purpose but does not address behavioral aspects or usage context, which could be beneficial for an AI agent to fully understand the tool's role and limitations.
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 has 0 parameters with 100% coverage, so no parameter information is needed. The description does not add any parameter details, which is appropriate given the schema's completeness, earning a baseline score of 4 for not introducing unnecessary or conflicting information.
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 verb 'List' and the resource 'available environments for the current repository vault', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'keyway_list_secrets', which might list a different type of resource, leaving room for slight ambiguity.
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, such as 'keyway_list_secrets' or other siblings. It lacks context on prerequisites, exclusions, or scenarios where this tool is preferred, offering only a basic statement of function without usage instructions.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions validation and pre-deployment checks, but doesn't describe what happens during validation (e.g., whether it returns a list of missing secrets, throws errors, or logs results), permissions needed, rate limits, or side effects. This is a significant gap for a tool that likely interacts with sensitive data like secrets.
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 and front-loaded: two sentences that directly state the purpose and usage. There is no wasted text, and every sentence adds value by explaining what the tool does and when it's useful, making it efficient and well-structured.
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 complexity (validating secrets, which is a sensitive operation), no annotations, and no output schema, the description is incomplete. It doesn't explain the return values, error handling, or behavioral details needed for safe and effective use. The description alone is insufficient for an agent to fully understand how to invoke and interpret results from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the schema. The description adds no specific parameter semantics beyond the general purpose, so it relies entirely on the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
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: 'Validate that required secrets exist in an environment.' It specifies the verb ('validate') and resource ('required secrets'), and distinguishes it from siblings like keyway_list_secrets or keyway_set_secret by focusing on validation. However, it doesn't explicitly differentiate from keyway_scan or keyway_diff, which might also involve checking secrets, so it's not a perfect 5.
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 provides some usage context: 'Useful for pre-deployment checks.' This implies when to use it (before deployment) but doesn't explicitly state when not to use it or name alternatives among siblings. For example, it doesn't clarify if this should be used instead of keyway_scan for validation purposes, leaving some ambiguity.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the key format constraint, which is useful, but does not cover critical aspects like authentication requirements, rate limits, whether the operation is idempotent, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that front-loads the core action and includes a helpful example for the key format. It avoids unnecessary words, though it could be slightly more structured by separating key constraints from the main action for clarity.
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's complexity (a mutation operation with no annotations and no output schema), the description is insufficient. It lacks details on return values, error handling, permissions, or side effects, which are crucial for an agent to use this tool correctly. The description does not compensate for the absence of structured behavioral data.
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 100%, so the schema already documents all three parameters (name, value, environment) with descriptions. The description adds minimal value by reinforcing the key format for 'name' but does not provide additional syntax, examples beyond the basic one, or context for parameter interactions. Baseline 3 is appropriate as the schema handles most of the parameter documentation.
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 ('Create or update') and resource ('a secret in the Keyway vault'), distinguishing it from sibling tools like keyway_list_secrets or keyway_validate. It specifies the exact operation with the key format constraint, making the purpose unambiguous.
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 for setting secrets in a vault, but does not explicitly state when to use this tool versus alternatives like keyway_list_secrets or keyway_validate. It provides some context (e.g., key format) but lacks guidance on prerequisites, exclusions, or specific scenarios for choosing this tool over others.
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 but only mentions secret isolation. It doesn't disclose critical behavioral traits like execution environment, security implications, error handling, or whether this is a read/write operation. The description is insufficient for a tool that executes commands with secrets.
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 concise sentences with zero waste. First sentence states the core functionality, second adds important security context. Perfectly front-loaded and appropriately sized.
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 command execution tool with secrets injection and no annotations/output schema, the description is incomplete. It lacks information about execution context, security boundaries, return values, error conditions, and how secrets are accessed/loaded. The security-critical nature demands more disclosure.
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 100%, so the schema fully documents all 4 parameters. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for high schema 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 the specific action ('Run a command') with the specific resource ('Keyway secrets injected as environment variables'). It distinguishes from siblings by focusing on command execution with secret injection, unlike list/scan/set operations.
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 context ('Secrets are only available to this command') but doesn't explicitly state when to use this vs. alternatives like keyway_set_secret or keyway_list_secrets. No guidance on prerequisites or exclusions is provided.
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 full burden and does well by disclosing key behavioral traits: it generates secrets (creation action), stores them in a vault (persistence), and importantly states 'The value is never exposed in the conversation' (security/privacy behavior). However, it doesn't mention authentication requirements, rate limits, or error conditions.
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 concise sentences with zero waste. The first sentence states the core functionality, the second adds crucial behavioral context. Every word earns its place, and the most important information is front-loaded.
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 creation tool with no annotations and no output schema, the description provides good context about the generation and storage behavior. However, it doesn't describe what happens on success (e.g., confirmation message, secret reference) or failure conditions. The 'never exposed' statement partially compensates for lack of output schema.
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 100%, so the schema already fully documents all 4 parameters. The description adds no additional parameter semantics beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
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 action ('Generate a secure secret and store it directly in the vault') and distinguishes it from siblings like keyway_set_secret (which likely sets an existing value) and keyway_list_secrets (which lists existing secrets). The phrase 'The value is never exposed in the conversation' adds important differentiation about output behavior.
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 implies usage context ('store it directly in the vault') and distinguishes from alternatives by noting the value is never exposed, but doesn't explicitly state when to use this vs. siblings like keyway_set_secret or keyway_validate. It provides clear operational context but lacks explicit comparison guidance.
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 that the tool returns only keys (not values), which is useful behavioral context. However, it lacks details on permissions, rate limits, or error handling. The description does not contradict any annotations.
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 two concise sentences with zero waste: the first states the purpose and scope, and the second clarifies the return format. It is front-loaded with the core functionality and efficiently conveys necessary 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 low complexity (one optional parameter, no output schema, no annotations), the description is reasonably complete. It covers purpose, scope, and return format. However, without annotations, it could benefit from mentioning safety aspects (e.g., read-only nature) or prerequisites, but this is a minor gap.
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 has 100% description coverage, with one parameter ('environment') fully documented. The description does not add parameter-specific semantics beyond the schema, but since there is only one optional parameter and high schema coverage, a baseline of 4 is appropriate as the schema handles the parameter details adequately.
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 action ('List all secret names') and resource ('in the Keyway vault for the current repository'), distinguishing it from siblings like 'keyway_set_secret' (which creates/updates) and 'keyway_scan' (which likely analyzes). It explicitly mentions what is returned ('only the keys, not the values'), avoiding ambiguity.
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: to retrieve secret names from the current repository's vault. It implies usage by specifying the scope ('current repository'), but does not explicitly state when not to use it or name alternatives (e.g., 'keyway_scan' might list secrets with details).
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:

[![keyway-mcp MCP server](https://glama.ai/mcp/servers/keywaysh/keyway-mcp/badges/card.svg)](https://glama.ai/mcp/servers/keywaysh/keyway-mcp)

Score Badge

Copy to your README.md:

[![keyway-mcp MCP server](https://glama.ai/mcp/servers/keywaysh/keyway-mcp/badges/score.svg)](https://glama.ai/mcp/servers/keywaysh/keyway-mcp)

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/keywaysh/keyway-mcp'

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