aidemd-mcp/server

by aidemd-mcp

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.9.0
Disambiguation4/5
Each tool has a distinct purpose: brain (brain state), discover (overview), info (boot-time), init (environment bootstrap), inspect (code symbol), read (spec content), scaffold (create spec), upgrade (update methodology), validate (health check). Some overlap between read/discover and init/scaffold, but descriptions clarify their different roles.
Naming Consistency5/5
All tools follow a consistent 'aide_verb' pattern (aide_brain, aide_discover, aide_info, etc.). The verbs are descriptive and the naming is predictable, making it easy for an agent to infer tool purpose from the name alone.
Tool Count5/5
9 tools is well-scoped for a server focused on AIDE methodology management. Each tool fills a specific role without redundancy, covering discovery, reading, creation, validation, upgrade, and boot-time reporting.
Completeness4/5
The tool surface covers the main lifecycle of AIDE methodology files: discover, read, create (init & scaffold), update (upgrade), and validate. Missing functionality includes deletion of specs or artifacts, and there is no tool to modify existing user specs beyond the upgrade tool. Minor gaps but core workflows are supported.
Average 4.5/5 across 9 of 9 tools scored. Lowest: 3.9/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
- Last stable release on May 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It lists the specific checks performed, which is good, but it omits details about the output format, side effects, or whether any changes are made. The description is somewhat transparent but incomplete.
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 sentence but front-loaded with the main purpose. It lists multiple items clearly separated by commas. Could be improved with bullet points, but it's reasonably concise and informative.
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 complexity of the tool (multiple checks) and the absence of an output schema, the description covers the input and the nature of the checks. However, it fails to describe what the tool produces (e.g., a report, exit code), which is important for an agent to invoke correctly.
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 parameter 'path' is documented in the schema. The description adds that it defaults to the entire project, which is a slight extension. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'health check' and resource '.aide spec files', and lists distinct detections like orphaned specs, missing specs, naming conflicts, etc. This clearly differentiates it from sibling tools like aide_init or aide_read.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. It simply states what it does.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool operates without opening the full file (lightweight), and searches across multiple file extensions (ts, tsx, js, jsx, mjs, cjs). It could mention return format or performance constraints, but overall it is transparent.
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 (two sentences plus one additional sentence on file types) and front-loaded with the core functionality. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the input and what is returned (JSDoc, signature, kind) adequately for a simple lookup tool. No output schema is needed; the description covers the return values. It fits well within the sibling tools context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds context beyond schema: it explains how to use the optional file parameter to narrow the search when location is known. This provides meaningful guidance beyond the schema's basic descriptions.
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 it returns JSDoc, signature, and kind for a named symbol without opening the full file, distinguishing it from siblings like aide_read which opens the full file. The verb 'inspect' and resource 'symbol' are specific.
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 explicitly advises when to use this tool: when an agent knows a function name from an import list or orchestrator file. It also explains the optional file parameter for narrowing search. However, it does not explicitly state when not to use it or mention alternative tools.
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 full burden. It details the output structure (content, type, related specs, links), which goes beyond a minimal description. However, it does not mention error handling or read-only status, though that is implied.
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: first defines functionality, second gives usage guidance. No unnecessary words, front-loaded with key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema). The description fully explains the return value and usage context, making it complete for the 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 coverage is 100%, so baseline is 3. The description adds no additional meaning for the 'path' parameter beyond the schema description.
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 'read', the resource '.aide spec file', and details the returned information (file content, type, related specs, links). It also explicitly distinguishes from sibling tool aide_discover.
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 instructs to use this tool after aide_discover, providing clear context on when to use it versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: naming rules, auto-renaming of existing .aide files when creating research.aide, and the specific purpose of each type. It could mention potential side effects like overwriting, but the information is sufficient.
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 well-structured, with a clear main sentence followed by bullet points for types. Every sentence contributes meaning without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description covers all necessary aspects: purpose, naming conventions, type meanings, and usage context. An agent can correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant value beyond the schema by detailing each type's purpose and naming interactions, which helps the agent decide values for the 'type' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates .aide spec files and enforces naming conventions. It explains the types and interactions, distinguishing it from sibling tools like aide_read or aide_validate, which are for different purposes.
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 each type (intent, research, etc.) and when to use them, but does not explicitly state when not to use this tool or suggest alternatives. The sibling tools cover other operations, making usage relatively clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: different responses based on path, ancestor chain with alignment status, summaries and warnings, and explains .aide file types. No contradictions.
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 longer but well-structured with clear sections. Front-loaded main purpose. Could be slightly more concise, but every sentence adds value for this complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description thoroughly explains the output structure (ancestor chain, subtree) and file types. Covers both modes comprehensively given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'path'. The description adds significant context beyond schema: different outcomes, ancestor chain structure, and usage scenarios, enhancing agent 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 verb 'Scan' and the resource '.aide spec files', returning a 'tree map'. It distinguishes between two modes (with/without path), which differentiates it from siblings like aide_read and aide_inspect.
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?
Explicit guidance on when to use without path (project-wide overview) and with path (drill into area). Does not explicitly state when not to use, but the progressive disclosure concept and file type explanations provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It thoroughly discloses all behaviors: no file system stats, silent collapse of missing files, remediation steps for each brain status, and the imperative to halt on non-ok status. No contradictions.
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 verbose but well-structured with headings and bullet points. It is front-loaded with purpose and then details. Some redundancy exists, but the organization aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description comprehensively covers all aspects: return fields, status meanings, remediation, and constraints. An agent can fully understand tool behavior and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and full schema coverage, the description adds meaning by detailing the output fields and their semantics. It explains the two top-level fields and the four brain statuses, which is essential given no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a boot-time reporter returning two specific fields: outdated (stale artifact keys) and brain (precondition state). It differentiates itself from sibling tools like aide_brain or aide_discover by focusing on startup reporting.
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 explicitly states it is called by the orchestrator at startup and provides branching logic for the two fields. While it doesn't mention when not to use it, the context is clear and no alternatives are suggested, which is acceptable for a unique boot-time reporter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels. It discloses the two-call progressive disclosure pattern, that the tool writes files on second call, that the agent never sees file content, and detailed per-category behavior (e.g., brain never writes, mcp needs merge, ide may need VS Code command). It also covers auto-detection and framework support.
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 lengthy but well-structured with clear sections (first call, second call, categories, upgrade surface). It front-loads the main purpose and then provides procedural details. While every sentence is useful, it could be slightly shorter without losing clarity. Still, it's appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two-call pattern, multiple categories, special cases for brain/mcp/ide, framework detection), the description is remarkably complete. It covers usage pattern, constraints (no editing user specs), return format for each call, and agent responsibilities. No output schema, but the description compensates by detailing the manifest structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds significant context beyond the schema. It explains the meaning of omitting category (summary mode), how framework override works, and the two-call usage pattern. This justifies a score above baseline 3, though the schema already describes the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: comparing AIDE methodology artifacts against canonical versions and returning structured JSON. It specifies what it is NOT for (editing user .aide specs), and outlines the two-call pattern with detailed steps. The verb 'upgrade' and resource 'AIDE methodology artifacts' are well-defined.
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 provides explicit when-to-use triggers (user asks to update/sync/refresh AIDE) and when-not-to-use (not for editing user specs). It gives a step-by-step wizard pattern with AskUserQuestion, one-at-a-time categories, and special handling for mcp/ide/brain categories. This clearly distinguishes from sibling tools like aide_init or aide_scaffold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries full burden. It fully discloses that the tool writes files itself, returns structured JSON (not prose), uses progressive disclosure, handles overwrites and skips, and never touches MCP config directly. It also explains the exceptions for brain, IDE, and MCP steps. There is no contradiction with structured data.
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 long but well-structured with bullet points and numbered steps. It front-loads the main purpose. While every sentence adds value, some sections (e.g., the detailed wizard pattern) could be slightly more compact without losing clarity. However, given the tool's complexity, this level of detail is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description comprehensively explains the return format (lightweight summary vs manifest), the two-call pattern, exceptions, and branch logic. It covers all four parameters and provides a step-by-step agent workflow. This is extremely complete for a tool with 4 parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical context beyond the schema: the purpose of the category parameter (first call omit, second call with category), the brainPath parameter (required when category=brain), and the framework parameter (force detection). It explains default behavior for path (server working directory) and clarifies the two-call pattern, which is not captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Bootstrap the AIDE development environment into a project.' This is a specific verb-resource combination that distinguishes it from sibling tools (e.g., aide_brain, aide_scaffold) by emphasizing the multi-step wizard pattern and progressive disclosure.
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 provides explicit when-to-use and when-not-to-use guidance, including the two-call pattern, branch logic for categories (pure-create vs overwrite-bearing vs inherent-decision), and instructions to avoid summary tables or asking multiple questions at once. It also names alternative tools indirectly by specifying when the agent should use AskUserQuestion versus calling the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It thoroughly details the response shape, four status states, instructions for each, and data integrity guarantees (no trimming, no substitution). Also notes that non-ok remediation is identical regardless of kind.
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?
Well-structured with headings and bullet points. Every sentence adds value, and the main purpose is front-loaded. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 1 optional param, no output schema, no annotations. Description fully covers purpose, usage, response, edge cases, and remediation. Nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant context: explains the two enum values, default behavior, and what each returns. Also details the response shape and status behavior beyond parameter meaning.
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?
Description clearly states it is an on-demand brain entry-point tool for mid-task use, and distinguishes from sibling tools like aide_info by warning not to call at boot. It specifies the two optional kinds and their purposes.
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?
Explicitly states when to use (mid-task) and when not to (boot), with an alternative given (aide_info.brain.status). Also explains the kind parameter choices and defaults.
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:

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

Score Badge

Copy to your README.md:

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

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