@quikrun/mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action or aspect of snippet management. There is minor potential confusion between update_snippet and update_snippet_code, but descriptions clearly differentiate settings updates from code updates. All other tools are unambiguous.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., list_snippets, get_snippet, create_snippet, delete_snippet). The only minor deviation is list_snippets using plural, which is standard for collection operations. Overall, the pattern is highly predictable.
Tool Count5/5
With 9 tools, the server is well-scoped for snippet management. Each tool serves a necessary function in the lifecycle, and there is no redundancy or bloat.
Completeness5/5
The tool set covers the full snippet lifecycle: create, read, update (settings and code), delete, duplicate, run, and deploy. This provides complete coverage without any obvious gaps that would hinder typical workflows.
Average 3.9/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 burden of behavioral disclosure. It only says 'update' without detailing effects, return values, permissions, or whether partial updates are supported, leaving significant ambiguity for a mutation tool.
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, concise sentence that effectively communicates the tool's scope. It avoids redundancy and front-loads the key action and resource.
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?
The tool is relatively simple, and the schema thoroughly documents all parameters. However, there is no output schema or behavioral notes about what the update returns or how partial updates are handled, leaving some contextual gaps that the description does not fill.
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%, so the baseline is 3. The description lists the majority of parameters (name, visibility, language, runtime) but omits the required 'slug' parameter, which the schema handles. The added value over the schema is minimal.
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: 'Update a snippet's settings' and lists the specific fields it can modify. This distinguishes it from the sibling tool 'update_snippet_code', which handles code updates rather than settings.
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 by indicating it updates settings, which contrasts with update_snippet_code, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The guidance is implied rather than direct.
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 must carry the behavioral disclosure burden. It only states the creation action and the optional parameters, plus the language default. It does not mention side effects, return behavior, authentication needs, whether prompt is used to scaffold code, or any other operational consequences.
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, well-structured sentence that leads with the core action and immediately conveys optional parameters. Every word earns its place, with no redundant or filler content.
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?
This is a relatively simple tool with three optional parameters and no output schema. The description covers the core purpose and all parameters, making it minimally viable. However, the lack of annotations and absence of return-value or side-effect information leaves some contextual gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying that language defaults to 'javascript' (schema only says 'Defaults server-side') and by explaining that 'prompt' is a natural-language description of what the snippet should do. This provides useful semantic context for all parameters.
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 opens with 'Create a new snippet,' which is a specific verb+resource statement that clearly distinguishes this tool from siblings like update_snippet, duplicate_snippet, and delete_snippet. It also lists the optional fields (name, language, prompt), reinforcing what the tool does.
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?
Usage is implied by the verb 'create'—this tool is for creating new snippets rather than updating, duplicating, or deleting them. However, there is no explicit guidance on when to choose this over create-related siblings like duplicate_snippet, or any exclusions or alternatives.
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 takes on the full burden of behavioral disclosure. It includes '[DESTRUCTIVE]' and 'This cannot be undone,' which clearly warns about the irreversible nature of the deletion, a critical behavioral trait.
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 concise sentence with an emphasis tag. Every word adds value, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with no output schema, the description covers the essential warning about permanence. However, it doesn't mention potential error conditions (e.g., slug not found) or permission requirements, which would be useful but are not strictly necessary.
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 input schema already fully describes the 'slug' parameter as 'The snippet slug to delete.' The description only echoes 'by slug' without adding format details, examples, or constraints, so it provides minimal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (snippet), and the method (by slug). This distinguishes it from sibling tools like update_snippet or duplicate_snippet, which perform different operations.
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 update_snippet for modifying a snippet. It simply states the operation without contextual 'when to use' or 'when not to use' information.
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. It mentions the return value (new slug and name) but does not disclose side effects such as whether code is copied, if a new resource is created (implied by 'duplicate'), permission requirements, or impact on the original snippet. This is minimal disclosure for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and includes the return information. No redundant words or filler.
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?
The tool is simple with one parameter, and the description covers the purpose and return value. While behavioral details are sparse, the low complexity and full schema coverage make the description adequate. Missing side effects are not critical in this context.
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 coverage is 100%: the only parameter 'slug' has a clear description. The tool description does not add additional meaning, but with full schema coverage, the baseline of 3 applies.
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 duplicates a snippet and specifies the returned data (new slug and name). 'Duplicate' is a specific action distinct from sibling tools like delete, create, update, and run.
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 clearly implies usage: calling this on an existing snippet slug to create a copy. However, it does not explicitly mention when not to use it or alternatives like create_snippet, though the context is intuitive for a simple tool.
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 the full burden of behavioral disclosure. It does indicate the destructive nature via 'Overwrites the current draft code,' but it does not clarify whether the published snippet is affected, require permissions, or mention reversibility. Some critical behavior is disclosed, but not enough for a mutation tool.
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 sentences long and immediately states the action and effect. Every word earns its place, and the overwrite warning is concise. There is no redundancy or filler.
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 simple tool with only two parameters and no output schema, the description provides enough context: it states what is saved (source code), where (to a draft), and the effect (overwrites current draft). It does not explain return values, but that is acceptable without an output schema. It lacks deeper context about interactions with other snippet states, but the description is effectively complete for its simplicity.
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 input schema already provides 100% coverage with descriptions for both parameters ('Full source code to save to the draft' and 'The snippet slug'), so the description adds minimal extra meaning. It reaffirms that the code is source code but does not introduce new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Save') and resource ('source code to a snippet's draft'), clearly distinguishing it from sibling tools like update_snippet, which likely handles metadata. It also adds the key behavioral detail that it 'Overwrites the current draft code,' making the tool's scope explicit.
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 the tool is for saving code to a snippet's draft, but it does not explicitly state when to use this tool versus alternatives like update_snippet. No exclusions or alternative tools are mentioned, leaving the usage context implicit rather than overt.
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, placing the burden on the description. It discloses return values (output, HTTP response summary, logs) and override capabilities, which is helpful. However, it does not mention potential side effects, required permissions, or whether execution has implications beyond returning data, which is a notable gap for an execution tool.
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 concise sentence that front-loads the core purpose, then lists optional behaviors without redundancy. It is appropriately sized for the tool's complexity and leaves no unnecessary wording.
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?
The description specifies return values and optional parameters, which covers the key aspects of a run operation even without an output schema. It could explicitly mention side effects or clarify whether it runs a saved draft versus deployed code, but the current text is largely complete for basic usage.
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?
All six parameters have schema descriptions, so the schema already provides high coverage. The description adds the concept of 'overrides' for method, path, body, and bodyType, and links code to ad-hoc execution, but this is marginal enhancement rather than new semantic meaning. Baseline 3 is appropriate.
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 runs a snippet and returns output, HTTP response summary, and logs, which is a specific action that distinguishes it from sibling CRUD and deployment tools. The verb 'Run' is direct and the resource 'snippet' is identified, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for executing snippets with optional overrides and ad-hoc code, which clearly positions it as the execution tool among sibling CRUD and deployment operations. It does not explicitly contrast with get_snippet or other tools, but the context makes when to use it clear enough.
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 the full burden of behavioral disclosure. It states the core action—publishing the current draft as the live version—which implies a state change. However, it does not mention potential side effects (e.g., whether the draft is cleared, reversibility, or permission requirements), leaving some aspects of behavior undocumented.
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, concise sentence that fully expresses the tool's purpose without filler or repetition. It is front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and no annotations, the description fully conveys the essential function. It tells the user exactly what the tool does, and nothing additional is needed for basic usage.
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 input schema covers the single parameter 'slug' with a description ('The snippet slug.'). The tool description adds no new parameter-level meaning beyond the schema, so with 100% schema coverage, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('publish') and resource ('a snippet's current draft'), conveying the action of making a draft live. It is distinct from sibling tools like create, update, or delete, leaving no ambiguity about its purpose.
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 implicitly communicates when to use the tool (when a user wants to make a snippet draft the live version), and the context is clear. It does not explicitly name alternatives or exclusions, but for a simple tool with one action, the usage context is adequately conveyed.
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, the description carries the full burden. The verb 'Get' implies a read-only operation, and the description adds specifics about the return content ('metadata and full source code'). This is sufficient for a simple read tool, though it does not mention error conditions or explicit side-effect freedom.
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 sentence of 9 words, front-loaded with the action and object. Every word earns its place, with no redundant or filler content.
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 its simplicity (one parameter, no output schema), the description is largely complete. It states what the tool returns (metadata and full source code). However, it could be improved by noting behavior on missing slugs, but this is not critical for a basic get operation.
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% for the single parameter 'slug', and the schema already describes it as 'The snippet slug'. The description only reinforces that the slug is the identifier. It adds no extra meaning beyond the schema, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('one snippet's metadata and full source code'), and the input ('by slug'). This effectively distinguishes it from sibling tools like list_snippets (which returns multiple snippets) or update_snippet (which modifies).
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 that this tool is for retrieving a single snippet when the slug is known. It does not explicitly mention alternatives, but the phrase 'one snippet' implicitly differentiates from list_snippets. No exclusionary guidance is provided, but the usage scenario is clear.
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, the description carries the burden. It discloses that the tool returns a compact summary with specific fields and that it lists all snippets, indicating a read-only broad retrieval. It does not discuss pagination or rate limits, but for a list tool this is minimal; the behavior is well conveyed.
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, front-loaded sentence that lists the output fields succinctly without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and lack of output schema, the description fully covers what the tool does and what the response contains. It is complete for a listing tool of this simplicity.
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 zero parameters, so the baseline for parameter semantics is 4. The description adds context about the output fields, but there are no parameter details to clarify; thus a 4 is appropriate.
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 uses a specific verb 'List' and resource 'QuikRun snippets', clearly distinguishing it from sibling tools like get_snippet (single) and create/update/delete. It also details the output fields, making its 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 retrieving an overview of all snippets, but it does not explicitly state when to use this tool versus alternatives like get_snippet, nor does it mention any exclusions or prerequisites. However, the 'List all' phrasing provides clear context.
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:

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

Score Badge

Copy to your README.md:

[![quikrun-mcp MCP server](https://glama.ai/mcp/servers/exit150/quikrun-mcp/badges/score.svg)](https://glama.ai/mcp/servers/exit150/quikrun-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/exit150/quikrun-mcp'

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