FabTally Safe

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The four core domains (token safety, signature decode, approvals, simulate) are distinct, but each has a paid and free pair with overlapping purpose. The descriptions clarify that free versions are teasers, but agents may still struggle to pick between them based on the level of detail needed.
Naming Consistency3/5
All names use snake_case and the _free suffix is consistent, but base names mix grammatical patterns: token_safety (noun_noun), decode_signature (verb_noun), approvals (plural noun), and simulate (bare verb). No uniform verb_noun convention is present.
Tool Count4/5
Eight tools is within the well-scoped 3-15 range, but since the set is really four features each with a paid and free variant, the count feels slightly inflated. Still, the free teasers provide a useful way to test functionality without payment.
Completeness4/5
The server covers token risk, signature decoding, approval scanning, and transaction simulation, forming a solid wallet-safety toolkit. Minor gaps exist (e.g., no address profiling or historical trend analysis), but core workflows are covered.
Average 4.2/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that it produces a 'real result' and requires 'no wallet', which is useful, but it does not state whether the operation is read-only, what 'risk level' means, or any limitations like rate limits or API key requirements. It adds some context but leaves notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with 'FREE', and immediately states the core outputs. It avoids redundancy, clearly separates the free vs. full offerings, and every phrase adds value. It is a model of conciseness.
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 5 parameters and no output schema, and the description mentions the output categories but not their structure or possible values. It is adequate for a simple free simulation tool, yet leaves the agent uncertain about the exact response format and edge cases. Given the complexity, a bit more detail would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific detail beyond what is already in the schema, but it does contextualize the parameters by listing the output types they influence (method, revert, risk level, effect types). No meaningful enhancement is provided.
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 as a simulation service that returns method, revert flag, risk level, and predicted effect types for a transaction. It distinguishes itself from the sibling 'simulate' tool by explicitly framing this as the free tier and naming the upgrade path.
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 by contrasting with the paid 'simulate' tool: the free version provides method, revert, risk level, and predicted effect types, while the full version adds 'predicted deltas + all risk flags'. This gives an explicit alternative, though it does not detail when to choose one over the other beyond feature comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool is free, returns a real result, and requires no wallet, which partly conveys its non-destructive nature. However, it does not explain limitations such as data freshness, error behaviors, or why a wallet is not needed. This is basic but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences, with the 'FREE' tag front-loaded. Each sentence serves a purpose: stating the output, clarifying the no-wallet behavior, and offering an upgrade path. 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 the tool's simplicity and lack of output schema, the description provides adequate context: what the tool returns (counts and top-3 risks), the fact it is free, and the upgrade option. It does not specify the exact result structure, but for a quick-risk tool this is sufficient. It could be slightly more detailed about the output shape.
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 input schema already covers both parameters fully (address and chain). The description merely references {address, chain} without adding any additional meaning, format details, or usage nuances beyond the schema. Thus, it meets the baseline but adds no extra 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 function: providing approval counts and top-3 riskiest spenders for a given address and chain. It distinguishes itself from the sibling 'approvals' tool by explicitly noting the free tier offers limited data (top-3 risks) versus the full ranking and revoke calldata.
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 when to use this tool: for a free, quick risk overview without wallet connection. It also points to the upgrade path to 'approvals' for more detailed results. However, it does not contrast with other free sibling tools like 'token_safety_free', so the guidance is not fully explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses the paid nature ($0.02, x402 on Base), the challenge-and-settle behavior, the output type (normalized risk score with reasons), and a caveat that it is descriptive only, not a signal. It does not cover failure modes or rate limits, but given the complexity, this is solid disclosure.
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 dense but every sentence earns its place: cost/payment, functionality, output details, caveat, and free alternative are all covered. It is front-loaded with the most important fact (PAID $0.02) and uses a structured list of risk factors. Slightly long but appropriately so for a multi-feature paid tool.
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 complexity (paid, multi-chain, aggregated data source, no output schema), the description covers the key aspects: what it does, what it costs, how payment works, what it returns, and its limitations. It does not specify the exact response format, but that is not required since no output schema is provided and the risk score description gives adequate expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning to the parameters themselves (address/chain are obvious), though it does contextualize x_payment by explaining the 402 challenge behavior. This does not significantly raise the score.
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: a multi-chain token honeypot/rug check aggregating GoPlus and honeypot.is into a 0-100 risk score with explainable reasons. It uses a specific verb ('check') and resource, and distinguishes from the sibling 'token_safety_free' by noting it is the paid version.
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 usage context: it is a paid tool, notes the free teaser alternative, and explains the payment flow ('Without payment returns the x402 challenge; pass x_payment to settle'). It also warns that it is not a buy/sell signal. However, it does not explicitly exclude other sibling tools (e.g., simulate, approvals) or provide comparison-based guidance.
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?
Since no annotations are provided, the description must carry the full burden. It states 'Real result, no wallet' which implies a live decode without side effects, and mentions it's a free version with limited scope. However, it does not disclose output format, error behavior, or any API key/auth requirements, so it only partially covers behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each earning its place: 'FREE' states the cost, the core function is front-loaded, 'Real result, no wallet' adds behavioral context, and the upgrade path is clearly indicated. No fluff or repetition.
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 a simple input schema (one required object, one optional string) and no output schema, the description explains the key return elements (type, summary, risk level) and the distinction from the full version. It is sufficient for an agent to understand the tool's purpose and invocation, though it stops short of describing the output structure in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'chain' and 'typed_data' have descriptions in the schema). The description itself adds no parameter-level detail beyond what the schema already states, so it meets the baseline for high schema coverage without providing extra 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 function: 'Type + plain-English summary + risk level for an EIP-712 typed_data.' It uses a specific resource (EIP-712 typed data) and distinguishes itself from the sibling tool decode_signature by being the free, summary-only version. The title also reinforces this.
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?
Explicit usage guidance is provided: it's FREE, produces a real result without a wallet, and the description directly recommends 'Upgrade to decode_signature' when full field-by-field decoding is needed. This tells the agent when to use this tool versus the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description states that this tool returns a real result without requiring a wallet, which sets expectations about side-effect-free usage. It describes the output as a score band plus honeypot/tax/privilege flags, giving a clear behavioral picture. It doesn't disclose rate limits or data freshness, but for a simple read-only query this is adequate.
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 compact sentences, front-loaded with 'FREE' and immediately conveying purpose, key result fields, and the upgrade path. Every clause adds value, and there is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two required parameters and no output schema, so the description carries the burden of explaining the return value. It does so at a high level (score band plus three flag categories) and directs users to token_safety for more detail, which is sufficient for a free-tier preview. It could be more precise about the exact flag values or limitations, but for the tool's simple scope it is complete.
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?
Both parameters (address, chain) are fully described in the schema with examples and enum-like chain list, so schema coverage is 100%. The description references {address, chain} but adds no additional parameter-specific semantics beyond what the schema already documents. Therefore a baseline score of 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?
Description clearly identifies the tool as a free token safety check that returns a score band and top-line flags for honeypot/tax/privilege risks, specifying the required inputs. It distinguishes itself from the sibling token_safety by explicitly stating it is the free tier, with the full version offering a numeric breakdown.
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 indicates this is the free tier for quick safety flags, and explicitly points to token_safety for the full numeric breakdown, providing a clear upgrade path. It also states 'Real result, no wallet,' which clarifies that no wallet connection is needed. However, it doesn't enumerate specific scenarios where free vs paid should be chosen beyond the breakdown detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it is paid, keyless (with the limitation 'no full fork trace'), uses public RPC, performs static decode, flags risks, and returns a 402 challenge without payment. This is highly transparent.
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 moderately sized but extraordinarily dense, covering cost, function, limitations, payment flow, and free alternative in about four sentences. It could be better structured with bullets, but every sentence earns its place.
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 complexity (paid, with payment flow and keyless limitation) and lack of output schema/annotations, the description covers the critical points: payment behavior, what the tool checks, and its limitation. It omits error handling or rate limits, but those are not essential for basic selection and invocation.
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 descriptions for all 6 parameters. The description lists the parameter set ({chain, from?, to, data, value?}) and mentions x_payment, but generally repeats schema information without adding new meaning beyond the overall purpose.
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: 'Keyless pre-sign analysis' with revert check, calldata decode, and risk flags. It also distinguishes itself from the sibling tool simulate_free by pointing to it as a free teaser, clarifying the paid nature.
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 practical usage guidance: it tells users that without payment they get an x402 challenge, and to pass x_payment for real results. It also mentions simulate_free for a free alternative, though it does not explicitly exclude other sibling tools for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so well: it discloses payment requirements (x402, USDC on Base), the 402 challenge response when unpaid, the fact that it never broadcasts calldata, and security caveats like 'fake-approval revoke bait'. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet compact—three sentences covering payment, functionality, flags, return value, and security. Each sentence adds distinct value, front-loaded with the paid cost and x402 context. No wasted 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 no output schema and no annotations, the description is thorough: it covers what the tool scans, what it flags, what it returns (revoke calldata), execution responsibility, payment flow, and free alternative. It's sufficiently complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal new parameter semantics beyond the schema—'pass x_payment' restates what the schema already explains. No additional insight on address/chain formats is provided.
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 scans wallet ERC-20/721 approvals, ranks them by exposure, flags risky spenders, and returns revoke calldata. It explicitly names the free sibling 'approvals_free' for comparison, distinguishing the paid version.
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?
It provides clear payment context ('PAID $0.01', x402 mechanics) and points to 'approvals_free' as an alternative. It doesn't explicitly exclude other sibling tools like token_safety/simulate, but the paid/free distinction and execution guidance ('execute YOURSELF') give solid contextual usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it excels. It discloses that this is a PAID tool ($0.01, x402/USDC on Base), explains the payment/response flow, and explicitly states 'Pure offline decode — never signs/broadcasts', which is critical safety information. It also indicates what happens without payment (returns challenge), giving the agent a clear 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 dense but each sentence provides distinct value: payment notice, decode functionality with risk flags, context on wallet-drainers, safety guarantee, payment flow, and free alternative. It is front-loaded with the most critical pricing/payment information and avoids fluff.
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?
Despite lacking an output schema, the description adequately covers the return behavior (plain English with risk flags, challenge vs real result). It provides enough context for an agent to understand the tool's role in wallet-drainer defense, its offline nature, and the payment mechanism, making the description self-sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the payment workflow (x_payment forwarded as X-PAYMENT header, omitted to get price challenge) and how chain relates to domain.chainId (override semantics). It clarifies why typed_data is required and how it is used, exceeding the schema's bare property 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 uses a specific verb ('Decode') and clearly specifies the resource (off-chain EIP-712 typed-data signatures) and the output (plain English with risk flags). It lists concrete signature types (Permit, Permit2, Seaport, generic) and enumerates the risk flags, making the tool's function unmistakable and distinct from sibling tools like decode_signature_free.
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 operational guidance: it explains the payment flow (without payment returns an x402 challenge; pass x_payment to get the real result) and points to decode_signature_free as a free alternative. It implies the tool is for paid/production use and the free version for teasers, but it does not explicitly contrast with siblings like approvals or simulate beyond stating its offline nature.
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:

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

Score Badge

Copy to your README.md:

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

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