Varrd

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: autonomous_varrd_ai explores broadly, varrd_ai tests specific ideas, varrd_edges provides live edges, search finds saved hypotheses, get_hypothesis gives details, get_briefed creates news briefs, buy_credits/check_balance handle credits, and reset_session manages sessions. No ambiguity.
Naming Consistency3/5
Most tools follow verb_noun snake_case (get_briefed, buy_credits, check_balance, reset_session, search), but some are noun phrases (varrd_edges, varrd_ai) or longer (autonomous_varrd_ai). The pattern is not fully consistent, though still readable.
Tool Count5/5
9 tools is well-scoped for a trading research server. Each tool serves a specific function without redundancy, covering exploration, testing, live data, search, credit management, and session control. No bloat or missing essentials.
Completeness4/5
The tool surface covers exploration, hypothesis testing, live edges, search, details, briefing, session management, and payments. Minor gaps: no explicit tool to manually create or delete saved hypotheses, but the AI-driven flow handles creation. Core workflows are supported.
Average 4.6/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 4, 2026
- 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.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, read-only behavior. The description adds value by detailing return content (performance metrics, version history, etc.), providing insight beyond the annotation 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?
Two sentences, front-loaded with purpose, bullet-like list of return fields, and a closing emphasis on utility. 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?
With a single parameter and output schema present, the description adequately covers what the tool does and returns. Missing error handling details, but acceptable for a simple read operation.
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% with a clear description for the only parameter. The tool description adds no further param details, so baseline 3 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 returns full details for a hypothesis/strategy, listing specific elements (formula, rules, metrics, etc.). It distinguishes from siblings by its specific retrieval function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent has a hypothesis_id, and the schema parameter description specifies the ID comes from search or scan results. No explicit exclusions or alternatives, but context is clear.
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, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds value by stating that results are ranked and include key stats, which are helpful behavioral details beyond the 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-loading the action and output, then providing usage guidance. Every sentence earns its place with zero 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?
Given the tool's simplicity, annotations, and output schema existence, the description covers purpose, usage, and key behavioral aspects. It does not explain ranking details or stats precisely, but these may be unnecessary for a search tool.
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 the schema already documents all three parameters. The description provides an example for the 'query' parameter and mentions the 'market' filter is optional, adding marginal value but not significantly beyond 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 the verb 'search', the resource 'saved hypotheses', and the output 'matching strategies ranked by relevance with key stats'. It distinguishes from siblings like 'get_hypothesis' which likely returns a single hypothesis.
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 says 'Use this to find strategies you've already validated', providing clear context for when to use it. It does not mention when not to use or provide alternatives, but the context signals with sibling tool names imply differentiation.
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 provide destructiveHint=true and idempotentHint=true, but the description adds useful behavioral context: 'Free — no credits consumed' and the post-reset step. There is no contradiction 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 concise with three sentences, front-loaded with the primary action, and each sentence adds value without 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?
Given the tool's simplicity (one required parameter, good schema coverage, output schema exists, and annotations provide behavioral hints), the description covers when to use, what it does, and follow-up actions, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, session_id, is fully covered by the schema description ('The session_id to reset'). The description does not add additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Kill' and resource 'broken research session', clearly distinguishing it from sibling tools like 'search' and 'varrd_ai' which have 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 explicitly states when to use the tool ('when a session gets stuck, produces errors, or enters a bad state') and provides post-action guidance ('call research without a session_id to start a new clean session'). It does not mention when not to use it, but the context is clear.
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?
Disclosures such as free at depth=0, always safe, and statistical validation (Bonferroni correction) add value beyond annotations. No contradiction with readOnlyHint, idempotentHint, and destructiveHint.
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?
Well-structured with clear sections (THREE TIERS) and front-loaded with the primary purpose. Slightly verbose but each sentence adds value.
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?
Covers all aspects: purpose, tiers, pricing, filters, statistical rigor, and output scope. With an output schema present, the description is thorough and leaves no major gaps.
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?
Input schema has 100% coverage with detailed descriptions. The description enhances this by explaining the tiered pricing and the meaning of depth levels, which goes beyond the enum values.
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 is a live feed of statistically validated trading edges with three tiers. The description immediately establishes it as 'THE PRIMARY TOOL', distinguishing it from sibling tools like get_hypothesis, search, and varrd_ai.
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 to start with depth=0 (free), outlines when to use different depths, and notes it is always safe to call. However, it does not explicitly exclude use cases or compare to 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?
Adds context beyond annotations: free, no credits consumed, auto-detects payments, response includes recovered_cents. 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?
Two brief sentences, front-loaded with core purpose, no extraneous words. Highly 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?
Simple tool with no params and output schema present. Description covers purpose, free nature, and payment confirmation use case. Complete for a read-only check.
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, schema coverage 100%. Baseline 4 applies; description adds no parameter info but none needed.
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 checks credit balance and available packs, and also auto-detects completed payments. Specific verb 'check' and resource 'balance', distinguishes from sibling 'buy_credits'.
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 usage guidance: free, no credits consumed, suggest calling after payment to confirm credits. Implies when to use, but lacks explicit when-not or alternatives.
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?
Annotations already declare readOnlyHint=true, idempotentHint=false, and destructiveHint=false. The description adds behavioral details beyond annotations: it profiles strategies, searches today's news, writes a digest with connections to positions and edges, and notes credit costs. No contradiction with annotations; the description enriches the behavioral model.
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 short paragraphs with the first sentence immediately stating the purpose. Every sentence adds relevant information (profiling, searching, writing, format, requirements, cost). No fluff, well-structured for quick comprehension.
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 parameters but an output schema (existence noted), the description covers input requirements (5 edges, credits), processing steps, and output format features. It fully prepares the agent to invoke the tool correctly, without needing to see the output schema.
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?
There are zero parameters and 100% schema description coverage. The description adds context about what the briefing includes (e.g., '↳ line tying it to your actual positions and edges'), which goes beyond the empty schema. Since no parameters exist, the baseline is 4, and the description provides additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a personalized market news briefing based on your validated edge library.' It distinguishes from sibling tools like 'search' and 'varrd_ai' by specializing in personalized briefing generation. The verb 'Get' combined with specific resource 'personalized market news briefing' makes the action 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 prerequisites ('Requires at least 5 strong edges in your library') and a cost constraint ('Costs credits'), guiding the agent on when to use this tool. It implies use when the user has sufficient edges and wants a briefing, but does not explicitly state when not to use or list alternatives, though sibling names offer some 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?
The description adds behavioral context beyond annotations: it mentions the tool draws from knowledge graphs, generates novel hypotheses, returns complete results (edge or not, stats, trade setup), and costs ~$0.25 per call. Annotations already indicate non-readOnly and openWorld, and the description aligns with these without 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?
The description is concise (about 150 words), well-structured with a clear opening, a 'BEST FOR' highlight, and a direct comparison with the sibling tool. Every sentence adds value; no fluff or repetition.
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 (6 parameters, 1 required, 2 enums) and the presence of an output schema, the description is complete. It covers purpose, usage, output, cost, and alternatives. The output schema handles return value details, so the description need not repeat them.
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%, so baseline is 3. The description adds value by providing concrete examples (e.g., 'momentum on grains') and explaining how parameters like test_type and search_mode affect behavior. This contextualizes the parameters beyond their schema 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 the tool's purpose: 'Point VARRD's autonomous AI in a direction and let it discover edges for you.' It specifies the action (exploring), resource (VARRD knowledge graph), and outcome (novel hypotheses). It also distinguishes from the sibling tool 'varrd_ai' by explicitly stating when to use each.
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 guidance: 'BEST FOR: Exploring a space broadly.' It also tells when not to use it and what alternative to use: 'Use varrd_ai instead when YOU have a specific idea to test and want full control over each step.' This is clear and actionable.
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?
Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds behavioral details: returns Stripe Checkout link for card or deposit address+payment_intent_id for crypto, explains two-step crypto confirmation, and states the call consumes no credits. 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 well-structured: opens with purpose and free note, then bullet points for two payment methods with clear steps. Every sentence adds meaningful information. It is appropriately sized for the complexity and front-loads the key action.
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 complexity (payment flows, multiple methods), the description is complete. It covers both methods end-to-end, including return values, follow-up actions (check_balance, second buy_credits call), and the free nature. No gaps remain for agent understanding.
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?
Input schema has 100% coverage, so baseline is 3. The description adds valuable context beyond schema: explains the workflow for each parameter (e.g., payment_intent_id used to confirm crypto payment), defaults, minimum amount, and the two payment method flows. This extra guidance raises it above baseline.
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 buys credits for the edge library and AI research, with specific verb 'buy' and resource 'credits'. It distinguishes two payment methods (card and crypto) and mentions the default minimum of $5. This fully defines the tool's purpose and differentiates it from siblings.
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 guidance by detailing two payment methods with step-by-step instructions. It suggests crypto for autonomous scenarios and card for human-in-loop, and references check_balance as a follow-up. The 'Free — no credits consumed' note further clarifies usage context. This is thorough guidance.
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?
Beyond annotations (readOnlyHint false, openWorldHint true), the description discloses cost (~$0.25/turn), session creation, terminal states (edge verdicts, context.has_edge), and the requirement to follow context.next_actions. 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 well-structured with clear sections (MULTI-TURN, HYPOTHESIS INTEGRITY, KEY CAPABILITIES, etc.), front-loads the core purpose, and every sentence adds necessary detail without 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?
Given the tool's complexity (multi-turn, stateful, cost, hypothesis testing), the description covers all essential aspects: how to start/continue, rules, edge verdicts, terminal states, and key capabilities. It is fully self-contained for an agent to use correctly.
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%, and the description adds significant value: examples for 'message' (e.g., 'test it', 'show trade setup') and explicit instructions for 'session_id' ('Omit to start a new research session'). It also explains how to use parameters within the multi-turn workflow.
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: 'Talk to VARRD AI...Describe any trading idea...handles everything'. It distinguishes from siblings like 'autonomous_varrd_ai' by emphasizing multi-turn user interaction and specific workflow steps.
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 multi-turn session management, hypothesis integrity rules ('Never combine multiple setups'), and allowed/not-allowed actions like testing same setup across markets but not different formulas simultaneously.
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:

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

Score Badge

Copy to your README.md:

[![varrd MCP server](https://glama.ai/mcp/servers/augiemazza/varrd/badges/score.svg)](https://glama.ai/mcp/servers/augiemazza/varrd)

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/augiemazza/varrd'

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