@4da/mcp-server

Server Quality Checklist

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

Latest release: v4.6.2
Disambiguation4/5
Most tools have clearly distinct purposes: vulnerability scanning, pre-task briefing, ecosystem news, user context, and decision memory. There is some overlap between 'what_should_i_know' and 'get_context' or 'ecosystem_pulse', but descriptions help differentiate.
Naming Consistency3/5
Naming is a mix of verb_noun (vulnerability_scan, get_context), noun_noun (ecosystem_pulse, decision_memory), and a full phrase (what_should_i_know). While all are snake_case, the pattern is inconsistent.
Tool Count5/5
Five tools is well-scoped for a personal developer assistant server. Each tool serves a distinct purpose without bloat.
Completeness4/5
The tool set covers core knowledge and context needs: scanning, context, decisions, news, and briefing. Minor gaps exist (e.g., note-taking or direct code manipulation) but are outside the apparent domain.
Average 4.2/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 390 commits in the last 12 weeks
- Last stable release on August 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety or behavioral hints (all false), so the description must convey behavior. It states that memory is persistent and cross-agent ('what one agent learns, any agent can recall'), which is useful. However, it doesn't describe side effects of storing (e.g., overwrite, conflict resolution, retention policy) or any auth/rate limits. The description is transparent about the core functionality but lacks deeper behavioral detail.
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 and front-loaded with the core concept ('Cross-agent persistent memory'). It efficiently conveys the purpose and provides a clear call to action with two examples. Every word earns its place, no fluff or repetition.
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 zero parameters, no output schema, and no annotation hints, the description must fully explain how the tool operates. It says 'store' and 'recall' but fails to specify how the agent provides the content or key for storage, what the return format is, or how memory is organized. The lack of operational detail makes the tool difficult to use correctly without further 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?
The tool has zero parameters, and the input schema is an empty object, so schema description coverage is effectively 100%. With no parameters to explain, the description doesn't need to add parameter semantics. Per the rubric, a baseline of 4 is appropriate for 0 parameters. The description makes no claims about parameters, which is fine.
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: it provides cross-agent persistent memory for storing and recalling information. It names specific content types (discovery, decision, warning) and a use case (recall prior context). However, it doesn't explicitly differentiate it from sibling tools like 'get_context' or 'decision_memory', which could 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some usage guidance: 'Call to store a discovery, decision, or warning, or to recall prior context before starting work.' This suggests when to use it, but it lacks explicit guidance on when NOT to use it or how it compares to alternatives like 'get_context' or 'decision_memory'. The guidance is implied rather than being definitive about selection criteria.
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?
Description lacks behavioral details beyond listing actions. No mention of idempotency, side effects, authentication, or return format. Annotations are all false, so description carries full burden but fails to disclose important traits.
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?
Extremely concise: two sentences with no wasted words. Front-loaded with actions, followed by usage trigger.
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 empty schema and no output schema, description is too brief for a multi-action tool. Does not explain how the tool determines which operation to perform (e.g., via user intent or hidden parameters). Missing crucial operational logic.
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?
No parameters exist (empty schema), so description adds no parameter info. Baseline for 0 parameters is 4, which is appropriate here.
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 the tool records, lists, updates, or supersedes architectural decisions. It explicitly names the resource (decisions) and actions, and distinguishes from siblings like vulnerability_scan and get_context.
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?
Provides clear guidance: 'Call when the user makes, changes, or asks about a settled decision or convention.' No explicit when-not or alternatives, but siblings are sufficiently different to infer appropriate usage.
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?
Annotations already declare 'readOnlyHint' true and 'openWorldHint' true, covering safety and openness. The description adds that the tool provides 'advisories, active decisions, signals, and ecosystem updates,' which offers some behavioral context but no additional details about side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no wasted words. It front-loads the purpose and usage guidance effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must clarify what the output contains. It only vaguely mentions 'advisories, active decisions, signals, and ecosystem updates' without specifying format or structure. This gap reduces completeness, though the description is adequate for a simple briefing 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?
The input schema is empty (zero parameters), and schema description coverage is 100% trivially. With no parameters, the description need not add parameter details. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a 'pre-task briefing' that provides 'advisories, active decisions, signals, and ecosystem updates.' It uses specific verbs and resources, and the instruction to call it 'BEFORE starting any non-trivial task' distinguishes it from sibling tools like 'ecosystem_pulse' or 'vulnerability_scan'.
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 when to use the tool ('Call BEFORE starting any non-trivial task'), providing clear context. While it does not mention when not to use or list alternatives, the guidance is sufficient for a typical use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'Check whether' aligns as a read-only operation. It adds a small behavioral detail by indicating the tool consults 'recorded decisions' as the data source, but it doesn't disclose error handling, return behavior, or what happens on misalignment, so it offers only marginal extra context beyond 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 two sentences, front-loaded with the core verb ('Check'), and immediately followed by a practical trigger condition. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, no-parameter tool, the description covers the essentials: purpose and when to call. It could elaborate on how to interpret the result or whether the check is blocking, but given the absent output schema and simple nature, it's largely complete.
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?
With 0 parameters and 100% schema description coverage, the rubric sets a baseline of 4. The description adds no parameter-specific meaning (none needed), but it does imply the tool operates on a global decision set without requiring arguments, which is consistent with a 0-param interface.
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 checks whether a technology/pattern aligns with recorded decisions, using a specific verb+resource construction ('Check whether... aligns with the developer's recorded decisions'). It also differentiates from siblings like decision_memory and agent_memory by specifying its exact role in the workflow, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context ('Call BEFORE suggesting a major tech change, new library, or architecture shift'), which effectively guides the agent on appropriate invocation timing. However, it does not name alternative tools or mention when *not* to use it, so it stops short of full 5-level guidance.
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?
Annotations already declare readOnlyHint and openWorldHint. The description adds that it is 'Live' and 'filtered to the user's tech stack', providing behavioral context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the key action, no superfluous words. Every sentence adds value.
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 no output schema and no parameters, the description covers the tool's function sufficiently for an AI agent to understand its purpose and usage. Could benefit from mentioning the output format, but not essential.
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?
No parameters, so baseline is 4. The description implies implicit filtering (user's tech stack) but does not need to document parameters since schema coverage is 100%.
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?
Clearly states it provides 'Live Hacker News discussions filtered to the user's tech stack', distinguishing it from siblings like vulnerability_scan and what_should_i_know. The verb 'filtered' specifies the action precisely.
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?
Explicitly says 'Call when the user asks what is new or trending in their ecosystem', providing clear invocation context. Lacks guidance on when not to use or alternatives, but the strong positive directive earns a high score.
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?
Annotations indicate readOnlyHint and openWorldHint. The description adds context by specifying the scanning source (OSV.dev) and supported ecosystems, and implies no side effects. No contradictions with 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 two sentences, front-loaded with the core purpose, and includes usage guidance without any redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers the key aspects: what it does, when to use it, and the ecosystems involved. It could detail output format but isn't critical.
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?
No parameters exist; schema coverage is 100%. The description correctly does not need to explain parameters, and the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scan', the resource 'dependencies', and specifies the target CVEs across multiple ecosystems (npm, Rust, Python, Go). It distinguishes itself from sibling tools like 'ecosystem_pulse' or 'get_context' by focusing on security scanning.
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?
Explicitly tells when to call: 'when the user asks about security, vulnerabilities, or CVEs, or before you recommend a dependency.' This provides clear context for usage, though it does not mention when not to use.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable context by specifying the ecosystems (npm/Rust/Python/Go) and the types of data (freshness, deprecation, CVE counts), implying external lookups. It does not contradict annotations and enriches the agent's understanding of 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 two sentences: the first states what the tool does, the second gives the usage trigger. It is front-loaded, contains no filler, and every sentence earns its place.
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 (no parameters, read-only, no output schema), the description is complete. It covers the core purpose, the types of information it provides, and a clear use case. The agent has enough to select and 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 tool has zero parameters, so schema coverage is trivially complete. The description does not need to explain parameters. The baseline for 0 params is 4, and the description wisely focuses on usage context rather than parameter details.
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 states a clear function: it provides dependency version freshness, deprecation, and CVE counts across specific ecosystems. It also includes an explicit usage trigger ('Call when the user asks whether their dependencies are outdated, stale, or need updating'), which distinguishes it from sibling tools like vulnerability_scan or upgrade_planner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-to-use scenario ('Call when the user asks whether their dependencies are outdated, stale, or need updating'). However, it does not explicitly mention alternatives or when not to use it, though the sibling tool names provide implicit context for comparison.
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?
The description aligns with the readOnlyHint annotation, indicating a safe read operation. It adds value by detailing the specific data returned (role, tech stack, interests, affinities), which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: the first explains the output, the second gives usage guidance. Extremely efficient.
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 (no parameters, no output schema), the description fully explains the tool's purpose and when to use it. The listed outputs are sufficient for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not add parameter-level detail, but the baseline of 3 is appropriate as the schema already covers the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves user context including role, tech stack, interests, and learned affinities. It distinguishes itself from siblings like vulnerability_scan and decision_memory by focusing on user profile information.
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?
Explicitly says 'Call FIRST when you need to know what the user works on before answering or recommending,' providing clear when-to-use guidance. However, it does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral context about what the plan covers (CVE severity, deprecation, version distance, quick wins vs breaking changes). It does not contradict the annotations and provides useful detail beyond the structured 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 two sentences, front-loaded with the core value proposition, and every phrase adds information. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description is complete: it states the output type, key content dimensions, and when to invoke it. The sibling context further clarifies its niche relative to dependency_health and vulnerability_scan.
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 zero parameters, so the schema carries no burden. The description explains what the tool produces rather than parameter details, which is appropriate for a parameterless tool. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: providing a prioritized upgrade plan with specific dimensions (CVE severity, deprecation, version distance, quick wins vs breaking changes). It distinguishes itself from siblings like vulnerability_scan and dependency_health by focusing on the planning/prioritization output rather than the scan or health check itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage triggers: 'when the user asks what to upgrade, or after dependency_health surfaces problems.' This is clear contextual guidance, though it does not mention when not to use the tool or name alternatives beyond dependency_health.
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:

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

Score Badge

Copy to your README.md:

[![4DA MCP server](https://glama.ai/mcp/servers/4DA-Systems/4DA/badges/score.svg)](https://glama.ai/mcp/servers/4DA-Systems/4DA)

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/4DA-Systems/4DA'

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