evm-agent-toolkit

by 0xendale

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
All 9 tools have clearly distinct purposes: gas analysis, compilation, calldata decoding, storage layout, testing, vulnerability scanning, simulation, toolchain versions, and tracing. No two tools overlap in functionality.
Naming Consistency5/5
All tools follow a consistent 'evm_verb_noun' pattern (e.g., evm_analyze_gas_profile, evm_compile_and_diagnose). The naming is uniform and predictable, with no mixing of conventions.
Tool Count5/5
With 9 tools, the set is well-scoped for an EVM development and security toolkit. Each tool addresses a specific, essential task without being too few or too many.
Completeness5/5
The tool set covers the full lifecycle of EVM contract analysis: compilation, testing, gas profiling, security scanning, simulation, tracing, calldata decoding, storage inspection, and version checking. No obvious gaps for its intended purpose.
Average 4.6/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 20 commits in the last 12 weeks
- Last stable release on July 10, 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.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, etc. Description adds behavioral details: uses Foundry cast, returns revert reasons and error handling. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections: brief purpose, arguments, returns, examples, error handling. Every sentence is informative, no 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?
Explains return format and error handling. Context signals indicate an output schema exists (though not shown), so description complements it well. Could be 5 if output schema were explicitly provided.
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 has 100% coverage, but description adds examples and format hints (e.g., target must be 0x-prefixed, args space-separated). This provides practical guidance 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?
Clearly states it simulates a read-only call via eth_call, returns decoded results or revert reasons, and explicitly says it does NOT submit a real transaction. Differentiates from sibling tools like evm_trace_call by focusing on simulation.
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 context: simulates via eth_call, no real transaction. Includes examples for common use cases. Could be improved by explicitly stating when not to use (e.g., for write operations), but siblings are distinct enough.
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 (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are fully supported and augmented by the description. The description adds specific behavioral details: it uses 'cast call --trace', returns structured call tree including internal calls, gas cost, events, revert frames, and explicitly states it is read-only. Error handling (cast not installed, RPC unreachable) is also disclosed, providing comprehensive transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: summary, use cases, explicit Args/Returns/Examples/Error Handling sections. It is appropriately sized for the tool's complexity and front-loads the key information. Minor redundancy (e.g., repeating schema descriptions) prevents a perfect 5, but overall it is concise and easy to scan.
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 presence of a full output schema (embedded in description), comprehensive annotations, and 100% schema coverage for parameters, the description is complete. It covers return structure, error handling, usage examples, and behavioral constraints. No gaps remain for an agent to invoke this tool 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?
Input schema coverage is 100% with clear descriptions for all 4 parameters. The description's 'Args' section repeats this information without adding significant new semantics. For example, 'args' is described as 'optional' and 'Space-separated arguments' which matches the schema. Since the schema already provides adequate meaning, the description adds minimal 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 executes a read-only call with 'cast call --trace' and returns a structured call tree. It explicitly distinguishes from mutable tools by stating 'This tool does NOT submit a real transaction.' Use cases like verifying exploit reachability further clarify its purpose and differentiate it from siblings like 'evm_simulate_transaction'.
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 guidance: 'Use this to verify exploit reachability, inspect cross-contract call flows, or debug unexpected reverts.' It also explicitly states when not to use for real transactions. However, it does not directly name alternative sibling tools for related tasks (e.g., gas profiling via 'evm_analyze_gas_profile'), which would elevate it to a 5.
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, destructiveHint=false, idempotentHint=true. The description adds that it runs forge test, which may imply compilation and execution, and includes error handling (returns isError=true if Foundry missing or compilation fails). No contradiction to 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?
Description is well-organized with clear sections (Args, Returns, Examples, Error Handling). It is concise, front-loads the main 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?
With one parameter, a detailed output schema, comprehensive annotations, and error handling documented, the description covers all necessary aspects for an agent to correctly invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description 'Absolute path to the Foundry project root'. The description adds extra context: 'must contain foundry.toml' and provides an example value, enriching understanding beyond the schema alone.
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 explicitly states 'Run forge test --gas-report and return structured gas consumption data per contract and function.' This clearly differentiates from sibling tools like evm_scan_vulnerabilities, which is for security auditing.
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 a clear example ('Show gas usage for my project') and explicitly states 'Do NOT use for security auditing (use evm_scan_vulnerabilities instead).' Also mentions prerequisites (must contain foundry.toml), but does not elaborate on when to use other siblings beyond the security one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing the structured return format, including fuzz counterexample calldata, and specifying error conditions (isError for missing forge, invalid path, compilation failure). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, usage, arguments, returns, examples, and error handling. Every sentence adds value, no fluff, and it is front-loaded with the core 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's complexity (nested return object with failures, fuzz data), the description fully explains the output schema, error cases, and provides concrete examples. No gaps for an agent to understand invocation and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds context by explaining matchTest as regex and matchPath as glob, and includes usage examples that clarify parameter semantics. Slight duplication but beneficial elaboration.
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 explicitly states it runs forge test and returns structured per-suite, per-test results. It distinguishes from siblings by mentioning 'use evm_compile_and_diagnose for compiler errors' and the unique output includes fuzz counterexample data.
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 use cases: verify behavior equivalence, run invariant suites, or drive a Generate-Repair-Execute loop. It includes examples and error handling notes, but lacks an explicit 'when not to use' statement for sibling 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it never errors and missing binaries are reported as installed: false, which provides useful error-handling behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, usage, arguments, return format, and error handling. It is concise and every 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?
Given zero parameters, no nested objects, and a defined output schema, the description is completely adequate. It explains the return JSON structure and error handling, leaving no functional 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?
No parameters exist, so baseline is 4. The description correctly states 'Args: none', which is appropriate given the tool's 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 explicitly states the tool reports installed versions of slither, forge, and cast, using a specific verb ('Report') and resource ('host toolchain binaries'). It clearly distinguishes from sibling tools that perform analysis, compilation, or simulation.
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: 'Call this once before an analysis session to (a) verify prerequisites and (b) record versions so findings are reproducible.' It does not explicitly state when not to use it or compare with alternatives, but the context is sufficient.
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, idempotentHint=true, destructiveHint=false. The description adds context like 'schema-validated' and details on error handling, but does not contradict annotations.
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 sections for args, returns, examples, and error handling. Every sentence adds value, though slightly lengthy; could be trimmed slightly without losing information.
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 output schema exists, the description fully explains return values and error behavior. It covers all necessary aspects for a tool with 4 parameters and moderate 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% with descriptions for all 4 parameters. The description adds extra context beyond the schema (e.g., 'for a focused scan' for detectors, example usages), enhancing clarity without redundancy.
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 runs Slither static analysis on Solidity contracts, returning vulnerability findings. It uses specific verbs and resource, and distinguishes from siblings like evm_analyze_gas_profile.
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 guidance on when to use (e.g., 'Audit src/Vault.sol for reentrancy') and when not to ('Do NOT use for gas analysis (use evm_analyze_gas_profile instead)'). Includes examples and error handling.
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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context: error handling (returns isError=true if forge not installed), details on return format, and that output is structured diagnostics. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections: purpose, args, returns, examples, error handling. Front-loaded with the main action. Every sentence adds value; no 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?
Given one parameter, full return type described, good annotations, and examples covering common cases, the description is complete for an agent to understand usage and outcomes.
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 already documents 'projectPath' as absolute path. Description adds example values and clarifies it is the 'Foundry project root'. Schema coverage is 100%, so marginal added value but enough to be helpful.
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 'Run forge build and return structured compiler diagnostics.' The verb 'compile' and resource 'Solidity project' are specific. It distinguishes from siblings like evm_run_tests and evm_scan_vulnerabilities by its focus on compilation diagnostics.
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 examples like 'Check if my contracts compile' and 'Fix the compilation error', indicating when to use. However, it does not explicitly state when not to use or compare with sibling tools, leaving some room for ambiguity.
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 (readOnly, idempotent, non-destructive), the description explains the underlying forge command, return structure, and error conditions (forge not installed, invalid path, contract not found). 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 (purpose, args, returns, examples, error handling). Every sentence is informative and front-loaded with the main purpose. 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 the tool's complexity and the presence of annotations, output schema, and 100% parameter coverage, the description is fully complete. It explains the command, return format, use cases, and error handling, leaving no gaps for an agent.
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 with examples (e.g., fully qualified name format 'src/Token.sol:Token') and clarifies the contractName pattern, which goes beyond the schema's pattern description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects storage layout via forge inspect, listing state variables per slot. It distinguishes from sibling tools (e.g., gas profiling, testing) by mentioning specific use cases: proxy-upgrade safety and storage-packing gas analysis.
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 examples and error handling, indicating when to use (e.g., upgrade safety). However, it lacks an explicit 'when not to use' or direct comparison to sibling tools, though the use cases imply differentiation.
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 it as read-only, idempotent, non-destructive. The description adds deep behavioral context: the backend (Foundry cast), the two modes of operation, and error handling (isError for missing cast, malformed calldata, unknown selector). 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 (purpose, args, returns, examples, error handling). Each sentence adds value, no fluff. Appropriate length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, clear annotations, output schema), the description covers all necessary aspects: how it works, error handling, return format, and examples. The output schema is included, so no gap there.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description significantly enhances semantics by explaining the offline vs online modes, the requirement for 0x-prefixed calldata with at least 4 bytes, and providing examples. The description adds meaning 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 tool's purpose: decode hex calldata into a function signature and typed argument values using Foundry cast. It specifies the verb, resource, and output, and clearly distinguishes from sibling tools which focus on gas analysis, compilation, storage, etc.
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 explains when to use each mode: with a known signature for offline decoding, or without for online lookup via the signature database. It provides examples and notes network requirements. However, it does not explicitly mention when not to use this tool, though the sibling tools are sufficiently different to avoid confusion.
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:

[![evm-agent-toolkit MCP server](https://glama.ai/mcp/servers/0xendale/evm-agent-toolkit/badges/card.svg)](https://glama.ai/mcp/servers/0xendale/evm-agent-toolkit)

Score Badge

Copy to your README.md:

[![evm-agent-toolkit MCP server](https://glama.ai/mcp/servers/0xendale/evm-agent-toolkit/badges/score.svg)](https://glama.ai/mcp/servers/0xendale/evm-agent-toolkit)

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/0xendale/evm-agent-toolkit'

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