ProofYield MCP

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
Each tool targets a distinct financial action: plan creation, system status, receipt retrieval, portfolio snapshot, opportunity scanning, plan simulation, unsigned transaction preparation, execution verification, and post-execution monitoring. No two tools overlap in purpose.
Naming Consistency5/5
All tools follow a consistent noun_verb pattern (e.g., strategy_createPlan, portfolio_getSnapshot, execution_prepare). The verb portion is uniformly a verb or verb phrase, and the noun prefix clearly identifies the domain area.
Tool Count5/5
With 9 tools, the server covers the entire lifecycle of a yield strategy—from opportunity scanning and planning to simulation, preparation, verification, and monitoring—without unnecessary redundancy.
Completeness5/5
The tool set provides a complete workflow for testnet yield management: scanning opportunities, creating plans, simulating, preparing unsigned transactions, verifying on-chain execution, and monitoring outcomes. No obvious gaps exist for the intended domain.
Average 3.8/5 across 9 of 9 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
Discloses conditional logic (allowance insufficient vs. sufficient) but leaves ambiguity about actual state changes: 'simulate' may imply no mutation, yet readOnlyHint=false suggests otherwise. Key behavioral details are unclear.
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 main action and conditional logic. No redundant or extraneous content.
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?
Does not explain output format, what 'exact approval transaction' entails, or how to use the result. With output schema present, some context is still needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No description for the single parameter planHash despite 0% schema description coverage. The description adds no meaning beyond the schema's pattern constraint.
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 uses specific verbs ('revalidate', 'simulate') and identifies the resource ('plan', 'adapter'), clearly distinguishing it from sibling tools like strategy_createPlan or system_getStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Does not compare to siblings or provide context for selection, leaving the agent to infer usage from behavior alone.
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?
The description adds behavioral context: it reads on-chain data, requires on-chain evidence before reporting success, and never reports success without evidence. This complements annotations (idempotent, non-destructive). However, the readOnlyHint=false annotation suggests potential state modification, which the description doesn't clarify, causing a minor inconsistency.
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?
Single sentence, no wasted words, front-loaded with action and constraints.
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?
Adequate for a verification tool with an output schema, but lacks mention of prerequisites or error conditions. Does not reference sibling tools or context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the three parameters (chainId, planHash, transactionHash) beyond vague mentions of 'chain', 'plan', and 'transaction'. With 0% schema coverage, the description fails to add meaning to the 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 the tool verifies a signed transaction against a plan using on-chain data, with specific details on what is proven (sender, target, etc.). It distinguishes itself from sibling tools like 'execution_prepare' and 'plan_simulate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., existing plan, signed transaction) or when not to use it.
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?
The description adds valuable behavioral details beyond annotations: it explains that live Aave rates are read on-chain, controlled vault rates are explicitly labeled simulated, and DO_NOTHING is always included. This complements the readOnlyHint and openWorldHint annotations 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences, but the second sentence is dense and could be better structured for readability. It front-loads the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with no schema descriptions and an output schema, the description fails to explain the role of inputs like walletAddress and amount. Without parameter guidance, agents cannot use the tool correctly, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides no explanation for any of the four parameters (amount, assetId, walletAddress, allowedChainIds). Agents cannot infer what these inputs represent or how they affect the scan, leaving a critical gap.
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 queries allowlisted adapters for test-USDC opportunities, and the title 'Research approved yield opportunities' accurately reflects the purpose. It effectively distinguishes from sibling tools like strategy_createPlan or plan_simulate by focusing on research rather than planning or execution.
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 provides context on scope (test-USDC, adapters) and mentions DO_NOTHING inclusion, but lacks explicit guidance on when to use versus alternatives. It does not state prerequisites or when not to use, leaving agents to infer from context.
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 (readOnlyHint=false) indicate this is a write operation, and the description confirms 'create' implying mutation. The description adds a safety note: 'Caller-provided addresses never become trusted execution targets.' However, it does not disclose other behavioral traits like side effects on the system, rate limits, or authentication requirements. The description neither contradicts nor significantly extends beyond what annotations already imply.
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 two sentences long, front-loading the core process in the first sentence. The second sentence adds a security constraint without extraneous detail. It is concise but could be slightly tighter by removing the phrase 'server-produced' as it is implied.
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 (4 parameters with deep nesting, output schema exists), the description provides a high-level process but lacks important context such as the role of the 'policy' parameter, prerequisites (e.g., that the snapshot must be server-produced), and what happens on validation failure. The output schema is present so return values are not needed, but the description still feels incomplete for an agent to fully understand the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description fails to compensate by explaining the meaning or usage of any parameters. For example, 'policy' is not mentioned at all, and 'snapshot' and 'opportunities' are only referenced generically. This leaves agents with insufficient understanding of how to construct valid inputs.
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 action: 'Validate a server-produced wallet snapshot and opportunity set, apply deterministic hard gates before ranking, include the liquid baseline, and create a short-lived typed plan.' It specifies the resource (snapshot and opportunities) and the outcome (typed plan). This distinguishes it from sibling tools like 'plan_simulate' or 'execution_prepare' which handle simulation or execution, not plan creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('create a short-lived typed plan' after validation) but does not explicitly state when to use this tool instead of alternatives like 'plan_simulate' or 'execution_prepare'. No when-not-to-use or prerequisite conditions are provided.
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?
Description adds context beyond annotations: 'never moves funds automatically' clarifies readOnlyHint. It explains the tool can recommend proposals but does not execute trades. This is valuable behavioral insight not fully covered by 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 sentences, no fluff. First sentence states the core action; second adds a critical safety guarantee. Information is front-loaded and each sentence adds value.
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?
Description covers core purpose and safety, but lacks prerequisite context (e.g., need a planHash from strategy_createPlan or opportunities from opportunities_scan). Output schema exists, so return format is not required. Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description implicitly maps planHash to stored decision and currentOpportunities to fresh scan, but provides no details on formats, constraints, or how to obtain these inputs. Parameter names are somewhat descriptive but insufficient for correct invocation.
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 function: compare a stored decision with a fresh opportunity scan, and optionally recommend a proposal. The verb 'compare' and resource 'stored executed/planned decision' are specific. It distinguishes from siblings like opportunities_scan or plan_simulate.
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: use after a stored plan and fresh scan. It states what the tool does not do ('never moves funds'), which guides safe usage. However, it does not explicitly mention when not to use it or list 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?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond annotations by explaining the architecture: the LLM is the reasoning brain and deterministic code authorizes every financial action. This clarifies the tool's non-destructive, informational nature.
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 primary function and adding an architectural note in the second sentence. Every sentence contributes value with 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?
Given no parameters, existing annotations, and an output schema, the description sufficiently covers the tool's purpose. The architectural context adds completeness. However, what 'public configuration' includes could be slightly more explicit.
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 zero parameters, schema coverage is 100%, so the description does not need to explain parameter semantics. The baseline for 0 parameters is 4, and the description adds no irrelevant parameter information.
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 opens the ProofYield treasury dashboard and reports public configuration. This specific verb-resource combination distinguishes it from sibling tools focused on strategy creation, receipts, snapshots, scanning, simulation, and execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It does not mention prerequisites, context for invocation, or scenarios where this tool is preferred over others like monitor_check or receipt_get.
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, idempotentHint, and destructiveHint. The description adds a non-obvious behavioral trait: receipts only persist across restarts when the optional local hackathon store is configured. This is valuable 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?
Two concise sentences with no extraneous content. The first sentence states the core function, the second adds a critical condition. Every sentence earns its place.
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?
An output schema exists, so return values are not needed. However, the description lacks context on what a 'Decision Receipt' entails or how to obtain the ID/hash. The persistence caveat is helpful, but the tool concept remains somewhat vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single 'idOrHash' parameter. The description explains it can be either a receipt ID or a plan hash, adding meaning beyond the schema's type and length constraints. However, it does not specify format or example.
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 'Retrieve' and the resource 'complete validated Decision Receipt' with two identifier types (receipt ID or plan hash). It is specific and distinct from sibling tools which cover strategy, portfolio, opportunities, etc.
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?
No explicit guidance on when to use this tool versus alternatives is provided. The usage is implied (when needing a receipt), but no context about selection criteria or exclusions is given.
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 (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by detailing that the server does not sign/submit and rejects caller-provided data. 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?
Two concise sentences, front-loaded with the primary action, no unnecessary words.
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 low complexity (1 param, no nested objects) and the presence of an output schema, the description fully covers the tool's behavior for an AI agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter is planHash, but the description does not explain its purpose or format beyond the schema pattern. With 0% schema description coverage, the description should provide meaning, but it only says 'latest non-expired simulation' without linking to the 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?
Clearly states the tool returns the exact unsigned transaction from the latest non-expired simulation. Distinguishes from sibling tools like plan_simulate by specifying output nature and constraints.
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 the server does not sign or submit the transaction and never accepts caller-provided targets or calldata, implying it is for retrieval only after simulation. Could be more explicit about alternatives, but the context from sibling tools makes it 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?
The description adds behavioral context beyond annotations: it states 'Returns per-chain failures without fabricating balances', which is a key trait. This complements the readOnlyHint and openWorldHint annotations effectively.
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 verb and purpose, and contains no extraneous 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 the simple parameters, existing annotations, and available output schema, the description covers the essential behavior and return characteristics. A minor gap is the lack of output schema details, but since the schema exists, this is acceptable.
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 50% (walletAddress has description, chainIds does not). The description does not add meaning to parameters beyond the schema, merely referencing 'validated wallet' and 'supported testnets'. 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 specifies the verb 'Read', the resource 'live native and configured test-USDC balances for a validated wallet on supported testnets', and distinguishes the tool's scope from siblings by focusing on testnet portfolio snapshots. It's specific and 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 implies usage when checking testnet wallet balances, but does not explicitly contrast with sibling tools or specify when not to use it. The context, however, is clear enough to avoid misuse.
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:

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

Score Badge

Copy to your README.md:

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

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/AshutoshVatsg/proofyield-mcp'

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