@runehand/mcp-server

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 resource or action: bots, flows, conversations, analytics, messaging, and leads. The list/get pairs follow a clear resource-detail distinction, so an agent can reliably select the intended tool.
Naming Consistency5/5
All tools use lowercase snake_case verb_noun naming: list_*, get_*, send_message, create_lead. The pattern is consistent and predictable across the entire surface.
Tool Count5/5
Nine tools is well-scoped for a workspace/bot/conversation/lead management server. Each tool corresponds to a meaningful operation, and there is no redundant bloat.
Completeness4/5
Read/query coverage is strong across bots, flows, conversations, leads, and analytics, with messaging and lead creation included. Minor gaps exist—no lead status update, conversation creation/closure, or flow editing—but these are likely handled outside this server's read-and-engage scope.
Average 3.4/5 across 9 of 9 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 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 failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 must carry the behavioral burden. It does not disclose pagination behavior despite page/per_page parameters, nor whether it returns only metadata or internal flow details, or if any authentication requirements exist.
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 concise clause, but it lacks elaboration on pagination; conciseness is not an issue. However, it is adequately brief and front-loaded, earning a 4.
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 lack of annotations and output schema, the description is incomplete. It does not mention pagination behavior, response structure, or error conditions, leaving significant gaps for a potentially paginated list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only bot_id described). The description repeats bot_id but does not explain page/per_page semantics, which are nondescriptive in schema, thus failing to compensate for the coverage gap.
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 lists flows belonging to a bot identified by UUID. It is specific enough to distinguish from siblings (e.g., list_bots, get_flow) but does not explicitly contrast with them.
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?
No guidance is provided on when to use this tool versus alternatives. While the description implies it is for fetching all flows of a bot, it does not mention alternatives like get_flow for single flow details or how pagination works.
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, the description carries full burden. It adds one behavioral detail ('in executable format') but does not disclose error behavior, permission needs, or side effects. As a read operation, safety is implied but not stated.
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, focused sentence that front-loads the main action and adds a valuable detail about node format. No redundant words.
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 it is a simple read operation with one well-schemaed parameter and no output schema, the description is adequate but not rich. It notes executable nodes but lacks details on return structure or errors, which could be important for an agent.
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 provides 100% coverage with a clear description of flow_id as a UUID. The tool description adds no additional parameter meaning, but the schema fully compensates, so baseline 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 it fetches a single flow and includes nodes in executable format, distinguishing it from list_flows which lists multiple flows. However, it does not explicitly differentiate from other get_* siblings like get_conversation, though the resource type is clear.
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?
No guidance on when to use this vs alternatives. The description implies it is for fetching one flow by ID, but there is no mention of when not to use it or when to prefer sibling tools like list_flows.
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 only restates the basic action and filters, without mentioning pagination behavior, default ordering, return format, or any other operational details needed for a safe invocation.
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 of 12 words. It states the verb, resource, scope, and optional filters with zero wasted words, making it highly concise and 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?
For a simple list tool with no annotations or output schema, the description covers purpose and filter options but omits pagination behavior, return value details, and any safety hints. It is minimally viable but leaves gaps an agent would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only bot_id has a description). The description adds that bot_id and status are optional filters and can be combined, but it says nothing about page or per_page semantics, leaving half the parameters effectively undocumented.
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 lists leads for the workspace, using a specific verb ('list') and resource ('leads') with a scope. It distinguishes from sibling list tools by naming the distinct resource type, though it doesn't explicitly mention alternatives.
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 when to use the tool (when leads are needed for the workspace) and mentions optional filters, but provides no explicit guidance on when not to use it or direct references to alternatives among sibling list 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, the description carries the full transparency burden. It usefully discloses a key side-effect — "Does not trigger the LeadCaptured event" — which is genuinely valuable for orchestration. However, it omits return value, idempotency, error behavior, and any permission requirements, leaving meaningful behavioral gaps 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?
Two dense sentences, both earning their place: the first front-loads the action and scope, the second discloses a critical behavioral caveat. No wasted words or repetition of schema 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?
For an 8-parameter mutation tool with no annotations and no output schema, the description is minimally viable: it establishes purpose and one pivotal side-effect. But it never explains what the tool returns on success, how custom_fields is handled, or failure behavior, which is a clear gap given the absence of any output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%, covering only bot_id and source), so the description must compensate for parameter meaning, but it mentions no parameters at all. The remaining six parameters (name, tags, email, notes, phone, custom_fields) are only inferable by their names and types, and custom_fields' object semantics are entirely unspecified.
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 states a specific verb+resource ("Create a lead") and adds valuable scope: "directly, without an associated conversation." This distinguishes the tool from conversation-based lead creation and from the read-only sibling list_leads, though it does not explicitly name an alternative tool, so it falls just short of a 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?
Usage context is implied: use this tool when you want a lead untethered to a conversation and when avoiding the LeadCaptured event is acceptable. However, there is no explicit when-not-to-use guidance or named alternative (e.g., how leads normally get created), so the guidance remains implicit rather than directive.
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 states the scope (workspace owning the API key) but does not disclose pagination behavior, rate limits, or what happens if no bots exist. For a read-only list operation, it's minimal but not misleading.
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 directly states the tool's purpose. No wasted words, and it's front-loaded with the action 'List'.
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 (no output schema, no nested objects, only two optional pagination params), the description is mostly complete. However, it lacks any mention of pagination behavior or response format, which could be useful for an agent. It's adequate for a simple list tool but could be slightly more informative.
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%, but the parameters (page, per_page) are self-explanatory from their names and types. The description does not add any detail about pagination semantics, but the schema provides basic constraints. Since there are only two simple parameters, the description's lack of detail is acceptable but not ideal.
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 lists bots belonging to the workspace, which is a specific verb+resource. It distinguishes from siblings like list_flows and list_conversations by specifying 'bots' and the workspace scope, though it doesn't explicitly contrast with them.
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 listing bots in the current workspace, but provides no explicit guidance on when to use this tool versus alternatives like list_flows or list_conversations. It doesn't mention any exclusions or prerequisites, so it's adequate but lacks explicit context.
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 burden of behavioral disclosure. It only restates the basic list/filter behavior and fails to mention pagination, response shape, or any operational details beyond the obvious reading of the tool name.
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 one short, front-loaded sentence. It communicates the core scope and optional filters without redundancy, earning its place fully.
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?
The description is minimal for a paged list endpoint with no output schema. It omits pagination semantics, return format details, and enough contextual guidance to fully cover the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with bot_id described in the schema and status exposed via enum. The description adds the optionality and combination of bot_id/status but does not help with page or per_page parameters, leaving significant parameter semantics unexplained.
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 ('List conversations'), the resource ('conversations'), and the workspace scope. It also distinguishes the tool from sibling list tools by resource type and mentions optional filters, making its purpose specific and identifiable.
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 gives clear context for use: listing workspace conversations with optional bot_id/status filtering. It does not explicitly mention alternatives like get_conversation for single conversations, but the behavior and scope are clear enough to imply the appropriate use case.
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 must carry full burden. It indicates a read-only analytics retrieval ('Get workspace KPIs') and references the in-app dashboard but does not disclose permission requirements, rate limits, pagination, or whether the response is a single report or a stream of 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 concise and front-loaded with the verb and resource. It wastes no words and includes a useful clarifying note about being the same data as the in-app dashboard.
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 simple read-only tool with fully documented date parameters, but it lacks explicit information about the output structure or metrics returned. Since there is no output schema and no annotations, the description's vague 'KPIs and quick stats' leaves some ambiguity about what the agent can expect.
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%, already documenting both 'from' and 'to' date params with defaults. The description only says 'for a date range', adding no new parameter semantics beyond what the schema provides.
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 verb 'Get' and the specific resource 'workspace KPIs and quick stats for a date range'. This distinguishes it from all sibling tools, which focus on bots, flows, conversations, conversations, or leads.
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 this tool is used to retrieve workspace analytics for a date range but provides no explicit exclusions or alternative tool recommendations. The phrase 'same data as the in-app dashboard' gives some context but doesn't clearly specify 'when to use this vs. something else'.
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 of behavioral disclosure. It explicitly states that the conversation includes its messages in chronological order, which is meaningful behavioral context beyond just 'get'. It doesn't discuss error handling, but for a read-only fetch, this is acceptable.
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, front-loaded with the core action, and contains no redundant or filler words. Every word contributes to understanding the tool's purpose and behavior.
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 single-parameter read tool, the description effectively covers the essential behavior: retrieving one conversation with its messages in order. It doesn't enumerate all returned fields, but without an output schema and with a straightforward use case, this is adequately complete.
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%, with the only parameter 'conversation_id' clearly documented as 'UUID of the conversation to fetch.' The description adds no additional parameter-level meaning, so the baseline score 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 uses a specific verb ('Get') and a specific resource ('a single conversation'), and adds that it includes messages in chronological order. This clearly distinguishes it from the sibling 'list_conversations' tool, which implies a list operation.
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 phrase 'single conversation' implies this is for fetching one specific conversation, contrasting with 'list_conversations'. However, it does not explicitly name an alternative or provide when-to-use versus when-not-to-use guidance, so it remains at the 'implied usage' level.
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, the description carries the full burden. It discloses the core behavior and the channel-specific delivery nuance, which adds value. However, it does not mention potential side effects, required permissions, or failure scenarios. For a write operation, more behavioral context could be expected.
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, front-loaded with the main action, and includes only essential additional context about channel delivery. Every word earns its place, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description adequately covers the main purpose and the only exception (web vs. external channel). It does not over-explain trivial details, and the lack of an output schema means return values are not required to be described. Slightly more detail on delivery status would improve completeness, but it is generally sufficient.
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 both content and conversation_id having descriptive text in the schema. The tool description adds no additional parameter details beyond what the schema already provides, so it meets the baseline but does not enhance understanding.
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: 'Send a message as the agent in an existing conversation.' This is a specific verb+resource combination, and the channel delivery nuance further clarifies its scope. It is distinct from sibling tools like list_conversations or create_lead, which are not messaging tools.
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 the tool is used for sending messages in existing conversations, and the external channel condition provides context on when delivery differs. It does not explicitly state when not to use it or mention alternatives, but since no sibling tool overlaps in function, this is adequate.
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:

[![runehand-mcp MCP server](https://glama.ai/mcp/servers/echelonlabs-sf/runehand-mcp/badges/card.svg)](https://glama.ai/mcp/servers/echelonlabs-sf/runehand-mcp)

Score Badge

Copy to your README.md:

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

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