MCP-Confirm

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 ambiguity. For example, ask_yes_no handles simple binary questions, clarify_intent addresses ambiguous requests, confirm_action verifies impactful operations, and verify_understanding checks comprehension—all serving different confirmation needs without overlap.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with clear, descriptive names. Examples include analyze_logs, search_logs, collect_rating, and verify_understanding, maintaining uniformity throughout the set without any deviations in style or structure.
Tool Count5/5
With 8 tools, the server is well-scoped for handling user confirmation and verification tasks. Each tool earns its place by covering distinct aspects like questioning, clarification, logging, and feedback, avoiding both bloat and insufficiency.
Completeness5/5
The tool set provides complete coverage for the confirmation domain, including standard confirmations (ask_yes_no, confirm_action), intent handling (clarify_intent, verify_understanding), feedback collection (collect_rating), logging (analyze_logs, search_logs), and customization (elicit_custom), with no apparent gaps.
Average 3.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under 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?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this is a read-only operation, if it requires specific permissions, what the output format might be, or any rate limits, leaving significant gaps in understanding the tool's behavior.
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 function without unnecessary words. It's appropriately sized and front-loaded, 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 a statistical analysis tool with no annotations and no output schema, the description is insufficient. It lacks details on what statistical methods are used, the format of results, or any constraints, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what the schema provides (100% coverage). It mentions 'confirmation history logs' but doesn't clarify how parameters like 'groupBy' relate to the analysis, so it meets the baseline for high schema coverage without adding extra value.
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 action ('perform statistical analysis') and target resource ('confirmation history logs'), making the tool's purpose understandable. However, it doesn't differentiate from sibling tools like 'search_logs', which might also operate on logs but with different functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_logs' or other siblings. It lacks context about appropriate scenarios, prerequisites, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool collects ratings but doesn't explain how (e.g., scale, format), whether it's interactive or passive, what happens to the data, or any limitations (e.g., rate limits). This leaves key behavioral traits unspecified for a tool that likely involves user interaction.
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 unnecessary words. It's front-loaded and appropriately sized, making it easy to parse quickly while conveying the essential action.
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 (collecting user feedback, which may involve interaction and data handling), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like response format, error handling, or user experience implications, leaving gaps that could hinder effective tool invocation.
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 has 100% description coverage, clearly documenting both parameters. The description doesn't add any meaning beyond the schema, such as examples of typical 'subject' values or how 'description' enhances the rating context. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('collect') and resource ('user satisfaction rating'), specifying it's for AI's response or help quality. However, it doesn't explicitly distinguish this from sibling tools like 'ask_yes_no' or 'elicit_custom', which might also involve user feedback collection, leaving some ambiguity about its unique role.
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, timing (e.g., after an interaction), or differentiate from siblings like 'ask_yes_no' for binary feedback or 'elicit_custom' for open-ended input, leaving the agent to infer usage 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 full burden of behavioral disclosure. While it mentions 'pagination', it doesn't describe the return format, what fields are included in search results, error conditions, rate limits, or authentication requirements. For a search tool with 10 parameters and no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 purpose. Every word earns its place: 'Search' (verb), 'confirmation history logs' (resource), 'with various filters and pagination' (key capabilities). There's no redundancy or unnecessary elaboration.
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 (10 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain what the search returns (e.g., log entries with specific fields), how results are ordered, error handling, or performance characteristics. For a search tool with rich filtering options, more context about the output and behavioral traits is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are well-documented in the input schema itself. The description adds marginal value by mentioning 'various filters and pagination', which aligns with the schema parameters but doesn't provide additional syntax, format details, or usage examples beyond what's already in the schema descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.
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: 'Search confirmation history logs with various filters and pagination'. It specifies the verb ('search'), resource ('confirmation history logs'), and scope ('with various filters and pagination'). However, it doesn't explicitly differentiate this search tool from sibling tools like 'analyze_logs', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'analyze_logs' or explain the difference between searching logs and other confirmation-related tools (e.g., 'ask_yes_no', 'confirm_action'). There's no context about prerequisites, typical use cases, 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 full burden for behavioral disclosure. While it indicates this is a verification step, it doesn't describe what happens after verification (e.g., does it return confirmation, trigger next steps, or require user response?), nor does it mention any constraints like rate limits or permission requirements for a tool that interacts with user understanding.
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 with zero wasted words. It's appropriately sized for a tool with clear parameters and no complex behavioral nuances needing explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., confirmation object, user response, or next step trigger), nor does it address behavioral aspects like whether this blocks execution or how verification failures are handled, leaving critical gaps for agent understanding.
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 thoroughly. The description adds no additional meaning about parameters beyond what's in the schema, meeting the baseline expectation but not providing extra value like explaining how parameters interact or typical usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as verifying AI understanding of user requirements before proceeding, which is a specific verb-action combination. However, it doesn't differentiate from sibling tools like 'clarify_intent' or 'confirm_action' that might serve similar verification purposes, preventing 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 like 'clarify_intent' or 'confirm_action'. It mentions 'before proceeding' which gives some temporal context, but offers no explicit when/when-not rules or comparison to sibling tools, leaving significant 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 that the tool is for confirmation of 'potentially impactful operations,' hinting at safety or caution, but lacks details on how the confirmation is handled (e.g., user interaction flow, response format, or any side effects). For a tool with no annotations, this leaves significant gaps in understanding its behavior beyond the 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, well-structured sentence that efficiently conveys the tool's purpose and context. It is front-loaded with the core function and includes necessary qualifiers without redundancy. Every word earns its place, making it highly concise and easy to parse.
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 complexity (a confirmation tool with 3 parameters) and the absence of annotations and output schema, the description provides a basic but incomplete picture. It covers the purpose and hints at usage context but lacks details on behavioral aspects, return values, or interaction specifics. This is adequate for a simple tool but leaves room for improvement in fully guiding 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 has 100% description coverage, with clear descriptions for all three parameters ('action', 'impact', 'details'). The description doesn't add any additional meaning beyond what the schema provides, such as examples or usage tips. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately documents the parameters without extra value from the description.
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: 'Ask user to confirm an action before proceeding with potentially impactful operations.' It specifies the verb ('ask to confirm') and the resource/context ('action'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'ask_yes_no' or 'verify_understanding', which might serve similar confirmation purposes, so it falls short of 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('before proceeding with potentially impactful operations'), suggesting when to use this tool. However, it doesn't provide explicit guidance on when to choose this over alternatives like 'ask_yes_no' or 'verify_understanding', nor does it specify exclusions or prerequisites. The guidance is present but limited to a general implication.
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 states the tool creates a dialog but doesn't describe what happens after creation (e.g., how user responses are handled, whether it's blocking, or any permissions/rate limits). This leaves significant gaps for a tool that interacts with users.
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 includes necessary context without redundancy, making it appropriately sized for the tool's complexity.
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 complexity (user interaction with custom schema) and lack of annotations or output schema, the description is adequate but incomplete. It covers the basic purpose and usage context but misses behavioral details like response handling, which are crucial for effective use by an AI 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?
Schema description coverage is 100%, so the schema already documents both parameters ('message' and 'schema'). The description adds minimal value by implying these parameters define the dialog's content and structure, but doesn't provide additional syntax, format details, or examples beyond what the schema offers.
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 ('Create') and resource ('custom confirmation dialog with specific schema'), making the purpose understandable. It distinguishes from standard tools but doesn't explicitly differentiate from sibling tools like 'ask_yes_no' or 'confirm_action' which might also handle confirmations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('when standard tools don't fit'), which helps guide selection. However, it doesn't specify when NOT to use it or name explicit alternatives among the sibling tools, such as 'ask_yes_no' for simpler confirmations.
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 describes the tool's purpose and context but lacks details on behavioral traits such as how the user's response is handled, whether it blocks execution, or any error conditions. However, it 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 a single, efficient sentence that front-loads the key information ('Ask a yes/no confirmation question') and includes essential context without any wasted words. Every part of the sentence contributes to understanding the tool's use.
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 (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose and usage context well, but lacks details on behavioral aspects like response handling or error cases, which could be beneficial 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 schema description coverage is 100%, with the parameter 'question' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
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 ('Ask a yes/no confirmation question') and the resource ('to the user'), with a precise purpose ('when the AI needs clarification or verification'). It distinguishes from siblings like 'clarify_intent' or 'confirm_action' by specifying the binary yes/no format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'when the AI needs clarification or verification.' This provides clear context for usage, distinguishing it from alternatives like 'elicit_custom' or 'verify_understanding' by focusing on binary confirmation scenarios.
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 describes the tool's purpose (asking for clarification) but lacks details on behavioral traits such as how it interacts with the user (e.g., via UI prompts), whether it's idempotent, or any rate limits. The description is adequate but minimal for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information (action and condition) with zero wasted words. It is appropriately sized for the tool's complexity and earns its place by clearly defining purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose and usage well but lacks details on behavioral aspects like interaction flow or error handling. With no output schema, it doesn't need to explain return values, but could benefit from more context on how the tool operates.
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 thoroughly. The description does not add any parameter-specific information beyond what the schema provides (e.g., it doesn't explain how 'options' should be formatted or typical use cases for 'ambiguity'). Baseline 3 is appropriate when the schema handles 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 specific action ('Ask user to clarify their intent') and the condition ('when the request is ambiguous or could be interpreted multiple ways'). It distinguishes this tool from siblings like 'ask_yes_no' or 'confirm_action' by focusing on intent clarification rather than binary confirmation or verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'when the request is ambiguous or could be interpreted multiple ways.' This provides clear context for usage versus alternatives like 'verify_understanding' (which might confirm rather than clarify) or 'elicit_custom' (which is more open-ended).
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:

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

Score Badge

Copy to your README.md:

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

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/mako10k/mcp-confirm'

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