ACOMO MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: list_apis and list_components provide overviews, describe_api and describe_component give detailed information, api_schemas extracts specific parts, generate_request_template creates templates, call_api executes calls, and health checks server status. The descriptions make it easy to differentiate between listing, describing, extracting, generating, calling, and checking operations.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_apis, describe_api, call_api). The verbs (list, describe, generate, call, health) are clear and appropriately paired with nouns (apis, components, request_template, api), creating a predictable and readable naming convention throughout the set.
Tool Count5/5
With 8 tools, this server is well-scoped for its purpose of interacting with an API documentation system (acomo). Each tool serves a specific function in the workflow (listing, describing, extracting, generating, calling, and health checking), and none appear redundant or unnecessary, making the count appropriate for the domain.
Completeness5/5
The tool set provides complete coverage for the domain of API documentation exploration and interaction: it allows listing APIs and components, describing them in detail, extracting schemas, generating request templates, calling APIs, and checking server health. There are no obvious gaps, as it supports the full lifecycle from discovery to execution.
Average 2.7/5 across 8 of 8 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states the basic action without mentioning authentication requirements, rate limits, error handling, side effects, or response format. For a tool that presumably makes external API calls, this lack of behavioral information is critically inadequate.
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 extremely concise - a single Japanese sentence that directly states the core action. There's no wasted language or unnecessary elaboration. While this conciseness comes at the cost of completeness, the structure is efficient and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 4 parameters, nested objects, no output schema, and no annotations, the description is completely inadequate. It doesn't explain what the tool returns, how to interpret results, what errors might occur, or any behavioral characteristics. The description fails to provide the necessary context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 4 parameters (body, operationId, pathParams, query), the description provides no information about any parameters. It mentions 'operationId' in the action but doesn't explain what it is, how to obtain valid values, or what the other parameters do. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'operationIdを指定してAPIを呼び出す' (specify operationId to call API) states the basic action but is vague about what resource it operates on and doesn't distinguish from siblings. It mentions 'API' generically rather than specifying what type of API or what the tool actually does with it. Compared to siblings like 'list_apis' or 'describe_api', it's unclear what makes this tool unique beyond the basic verb 'call'.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or exclusions. Given siblings like 'generate_request_template' and 'describe_api', there's no indication of when this direct call tool should be preferred over preparatory or descriptive tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions extraction of parameters/requestBody/responses, but doesn't specify what format the output is in (e.g., JSON, text), whether it's a read-only operation (implied but not stated), or any error conditions. The description adds minimal context beyond the basic action, leaving key behavioral traits unclear.
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 sentence in Japanese that directly states the action. It's front-loaded with the core purpose and avoids unnecessary words. However, it could be more structured by explicitly naming the resource (e.g., 'from an API schema') for better clarity, but it's efficiently phrased.
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 (extracting API components), lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the output format, error handling, or how it relates to sibling tools like describe_api. For a tool that likely returns structured data about APIs, more context is needed to use it effectively.
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?
The schema has 1 parameter (operationId) with 0% description coverage, so the description must compensate. It mentions 'operationIdから' (from operationId), implying the parameter is an identifier for an API operation, but doesn't explain what operationId refers to (e.g., an OpenAPI operation ID, a specific endpoint), its format, or where to obtain it. This adds marginal meaning but insufficient for full understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'operationIdからparameters/requestBody/responsesを抜粋' (extract parameters/requestBody/responses from operationId) states a specific action (extract) and target (API components), but it's vague about what resource this operates on (API schemas? OpenAPI spec?) and doesn't distinguish from siblings like describe_api or describe_component. It provides a basic purpose but lacks specificity about scope.
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 like describe_api or describe_component. The description implies extraction of specific API components, but there's no explicit context about prerequisites, when-not scenarios, or comparison to sibling tools. Usage is left to inference from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns details but doesn't describe error handling, rate limits, authentication needs, or what happens if the operationId is invalid. This leaves significant gaps for a tool with no structured safety hints.
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 and appropriately sized for the tool's apparent complexity, 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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral traits needed for a tool that fetches API details, leaving the agent with insufficient context.
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 0%, so the description must compensate for undocumented parameters. It mentions 'operationId' but doesn't explain its format, source, or constraints beyond what's implied. This adds minimal semantic value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns details about an operationId, including paths, methods, summaries, and original text, which gives a vague purpose. It specifies the resource (operationId details) but lacks a clear verb beyond 'returns' and doesn't differentiate from siblings like 'describe_component' or 'list_apis'.
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. It doesn't mention prerequisites, context for selecting it over siblings like 'list_apis' or 'describe_component', or any exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions returning JSON Schema details but fails to describe error handling, rate limits, authentication needs, or what happens if the schema name is invalid. This leaves 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 is 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 tool has no annotations, no output schema, and low schema description coverage, the description is insufficient. It doesn't explain return values, error cases, or usage context relative to siblings, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description does not add any semantic details about the 'name' parameter. It doesn't explain what the name refers to, its format, or examples, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns detailed JSON Schema for a specified schema name, which clarifies the verb ('return') and resource ('detailed JSON Schema'). However, it doesn't differentiate from sibling tools like 'describe_api' or 'list_components', leaving ambiguity about when to use each. The purpose is clear but lacks sibling distinction.
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 'describe_api' or 'list_components'. There are no explicit instructions on context, prerequisites, or exclusions, leaving the agent to infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions generating templates but doesn't specify what the output looks like (e.g., format, structure), whether it's a read-only operation, or any constraints like rate limits. This leaves gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Japanese, which is efficient. However, it lacks front-loading of key details and could be more structured to highlight purpose and usage. While not verbose, it under-specifies, making it less helpful than it could be with slightly more 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 of generating API templates, no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the output format, error conditions, or how the tool interacts with siblings like 'list_apis.' For a tool that likely produces structured data, this leaves significant gaps in contextual understanding.
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?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It only mentions 'operationId' without explaining what it is, where to get it, or its expected format. This adds minimal meaning beyond the schema, failing to address the coverage gap adequately.
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 clear purpose: generating API request templates (path/query/body) from an operationId. It specifies the verb 'generate' and resource 'API request template,' though it doesn't explicitly differentiate from sibling tools like 'call_api' or 'describe_api.' The Japanese text is understandable but could be more precise about what '雛形' (template) entails.
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. It doesn't mention prerequisites, such as needing an operationId from another tool like 'list_apis' or 'describe_api,' or contrast with siblings like 'call_api' for actual execution. The description implies usage but offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a list but doesn't describe the format, pagination, rate limits, authentication needs, or potential errors. For a tool with zero annotation coverage, this is a significant gap in transparency about how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, though it could be slightly more structured for clarity (e.g., by adding context about usage).
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 (simple list operation) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned list contains (e.g., format, fields) or any behavioral aspects like error handling. For a tool with no structured data beyond the input schema, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it meets the baseline of 4 for tools with no parameters, as it doesn't have to compensate for any gaps.
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: 'acomoのAPIスキーマ（components.schemas）の一覧を返す' (returns a list of acomo API schema components). It specifies the verb ('returns a list') and resource ('acomo API schema components'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'describe_component' or 'list_apis', which would require 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 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 such as 'describe_component' (for detailed info on a single component) or 'list_apis' (for listing APIs), nor does it specify any prerequisites or exclusions. This leaves the agent without clear 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. It only states what the tool does ('returns a list of APIs') without detailing behavioral traits such as whether it's read-only, if it requires authentication, rate limits, pagination, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase in Japanese—and front-loaded with the core function. There's no wasted language, making it efficient for quick understanding. Every word earns its place by directly stating the tool's purpose.
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 for effective tool use. It doesn't explain what the returned list includes (e.g., API names, IDs, metadata), format (e.g., JSON array), or any behavioral context. For a tool with no structured data beyond the input schema, more detail is needed to ensure the agent can invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. A baseline of 4 is assigned since the schema fully handles parameters, and the description doesn't need to compensate for any gaps.
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: 'acomoのAPI一覧を返す' (returns a list of APIs for acomo). It specifies the verb ('returns') and resource ('API list'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'describe_api' or 'api_schemas', which prevents 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. With siblings such as 'describe_api' (likely for detailed API info) and 'api_schemas' (possibly for schema details), there's no indication of context, prerequisites, or exclusions for using 'list_apis'. This lack of comparative guidance limits its utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a health check with a 'fixed response', which implies it's a read-only operation that returns consistent output. However, it doesn't specify what the fixed response contains, rate limits, or authentication needs, leaving behavioral gaps.
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 extremely concise with a single, front-loaded sentence that directly states the tool's function and key behavioral trait ('fixed response'). There is no wasted verbiage, making it efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete. It identifies the tool as a health check but lacks details on the response format or error conditions, which could be helpful for an agent despite the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and its baseline score of 4 reflects this adequate coverage without redundancy.
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 a 'health check' for the MCP server, which is a specific verb+resource combination. However, it doesn't differentiate this from sibling tools like 'describe_api' or 'list_apis' that might also provide server status information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over other sibling tools or what context triggers its use, leaving the agent without usage direction.
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:

[![acomo-mcp-server MCP server](https://glama.ai/mcp/servers/progress-all/acomo-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/progress-all/acomo-mcp-server)

Score Badge

Copy to your README.md:

[![acomo-mcp-server MCP server](https://glama.ai/mcp/servers/progress-all/acomo-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/progress-all/acomo-mcp-server)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/progress-all/acomo-mcp-server'

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