The EVM Agent Toolkit MCP server provides autonomous agents with deterministic, schema-validated tools for EVM smart contract development, turning noisy CLI output into clean, reliable JSON.
Security Scanning (evm_scan_vulnerabilities): Run Slither static analysis to detect severity-rated vulnerabilities (High/Medium/Low/Informational) with code snippets, line numbers, and source file references. Supports filtering by severity.
Gas Profiling (evm_analyze_gas_profile): Run forge test --gas-report to get structured per-contract and per-function gas consumption data including min, max, average, median, and call counts.
Compiler Diagnostics (evm_compile_and_diagnose): Run forge build and receive structured diagnostics on failure — including file, line/column numbers, error messages, and code snippets.
Transaction Simulation (evm_simulate_transaction): Simulate read-only eth_call transactions against an EVM node using cast call, returning decoded return data or revert reasons without submitting a real transaction.
Storage Layout Inspection (evm_inspect_storage_layout): Inspect contract storage slot assignments (slot index, byte offset, type, size) — essential for proxy upgrade safety and storage collision checks.
Call Tracing (evm_trace_call): Execute a call with cast call --trace and get a full structured call tree with gas costs, call types (staticcall, delegatecall), emitted events, and revert frames.
Calldata Decoding (evm_decode_calldata): Decode hex calldata into function signatures and typed argument values — offline with a known signature, or via the 4byte selector database for unknown ones.
Test Running (evm_run_tests): Run forge test with optional filters and get per-suite, per-test results including fuzz run counts, gas usage, and exact counterexample calldata for failing fuzz/invariant tests.
Toolchain Version Check (evm_toolchain_versions): Report installed status and exact versions of slither, forge, and cast — useful for verifying prerequisites before an analysis session.
Skill Workflows (Prompts): Execute pre-defined workflows for contract auditing, gas optimization, and arbitrage analysis.
An MCP (Model Context Protocol) server that gives autonomous coding agents deterministic, schema-validated tools for EVM smart contract development — security scanning, gas profiling, compiler diagnostics, and transaction simulation.
Raw CLI output from tools like Slither and Foundry is noisy, non-deterministic, and often causes LLMs to hallucinate. This server intercepts the output, validates it through Zod schemas, and returns clean JSON that any agent can reliably parse.
Related MCP server: EVM Proxy MCP
Tool | Annotations | Description |
|
| Run Slither analysis. Returns severity-rated findings with extracted code snippets. Supports |
|
| Run |
|
| Run |
|
| Run |
|
| Run |
|
| Run |
|
| Decode hex calldata via |
|
| Run |
|
| Report installed/missing status and exact versions of |
URI | Description |
| Security vulnerability pattern library |
| Gas optimization pattern library |
| Arbitrage strategy reference |
Skill workflows exposed as MCP prompts for clients without native skill support. Each embeds the full SKILL.md workflow.
Prompt | Args | Description |
|
| Severity-rated security audit (vulnerability-scanning workflow) |
|
| Measured gas-optimization pass (gas-optimization workflow) |
|
| Opportunity ledger net of fees/gas/slippage (arbitrage-analysis workflow) |
evm-agent-toolkit/
├── src/
│ ├── mcp/ # MCP server entry point (stdio transport)
│ ├── tools/ # Zod-validated CLI output parsers
│ │ ├── slither.ts # Slither JSON → SanitizedFinding[]
│ │ ├── forge.ts # Forge gas tables → ContractGas[]
│ │ ├── compiler.ts # Forge build errors → CompilerDiagnostic[]
│ │ ├── simulator.ts# Cast call output → SimulatorDiagnostic
│ │ ├── storage.ts # Forge storage layout → StorageEntry[]
│ │ ├── trace.ts # Cast call traces → TraceEvent[]
│ │ ├── decoder.ts # Cast calldata decode → DecodedCalldata
│ │ ├── testrunner.ts # Forge test output → TestSuite[]
│ │ └── versions.ts # Toolchain --version output → ToolVersion
│ ├── rules/ # Agent system prompt injections
│ └── hooks/ # Lifecycle hooks (UserPromptSubmit, Statusline)
├── tests/ # Vitest unit tests for all parsers
├── bench/ # Performance benchmarks
├── evals/ # Agent evaluation framework (vulnerable contracts + eval XML)
├── skills/ # Markdown reference libraries
├── .claude-plugin/ # Claude Code plugin manifest
└── gemini-extension.json # Antigravity plugin manifestnpm install
npm run buildThis is a stdio MCP server. It is spawned by the MCP client, not started manually.
Claude Desktop / Cursor:
{
"mcpServers": {
"evm-agent-toolkit": {
"command": "npx",
"args": ["-y", "@0xendale/evm-agent-toolkit"]
}
}
}Prerequisites: slither, forge, and cast must be installed on the host machine.
npm run dev # Watch mode with tsx
npm run test # Run all unit tests
npm run bench # Run parser benchmarks
npm run build # Compile TypeScript → build/Parser throughput (measured on Apple Silicon):
Parser | Iterations | Time | Per-call |
Slither (100 detectors) | 1,000 | ~109ms | ~0.1ms |
Forge Gas Table | 10,000 | ~32ms | ~0.003ms |
MIT
Run forge test --gas-report and return structured gas consumption data per contract and function.
Args:
projectPath (string): Absolute path to a Foundry project (must contain foundry.toml)
Returns: JSON object: { "contracts": [ { "name": string, // e.g. "src/Token.sol:Token" "deploymentCost": number, // Gas used for deployment "deploymentSize": number, // Bytecode size in bytes "functions": [ { "name": string, // Function name "min": number, // Minimum gas "avg": number, // Average gas "median": number, // Median gas "max": number, // Maximum gas "calls": number // Number of calls in tests } ] } ] }
Examples:
"Show gas usage for my project" → projectPath = "/path/to/foundry-project"
Do NOT use for security auditing (use evm_scan_vulnerabilities instead)
Error Handling:
Returns isError=true if Foundry is not installed or tests fail to compile
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the Foundry project root |
| Name | Required | Description |
|---|---|---|
| contracts | Yes |
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.
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.
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.
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.
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.
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.
Run forge build and return structured compiler diagnostics.
If compilation succeeds, returns { "success": true, "diagnostics": [] }. If compilation fails, parses the error output into a JSON array of diagnostics.
Args:
projectPath (string): Absolute path to the Foundry project
Returns: { "success": boolean, // true if the project compiled cleanly "diagnostics": [ { "file": string, // e.g. "src/Token.sol" "line": number, // Line number (1-indexed) "column": number, // Column number (1-indexed) "message": string, // Compiler error message "snippet": string // Code snippet around the error } ] }
Examples:
"Check if my contracts compile" → projectPath = "/path/to/project"
"Fix the compilation error" → call this tool, read the diagnostics, fix the file
Error Handling:
Returns isError=true if forge is not installed
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the Foundry project root |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| diagnostics | Yes |
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.
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.
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.
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.
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.
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.
Decode hex calldata into a function signature and typed argument values using Foundry cast.
If you know the function signature, pass it for a fully offline, deterministic decode (cast calldata-decode). Without a signature, the 4-byte selector is resolved via the openchain.xyz signature database (cast 4byte-decode) — requires network access.
Args:
calldata (string): Hex-encoded calldata (0x-prefixed, at least the 4-byte selector)
signature (string, optional): Known function signature, e.g. "transfer(address,uint256)"
Returns: JSON object: { "success": boolean, "signature": string, // Resolved or provided function signature "values": string[] // Decoded argument values, one per parameter }
Examples:
"What does this pending tx do?" → calldata = "0xa9059cbb000...", no signature
"Decode this transfer call" → calldata + signature = "transfer(address,uint256)"
Error Handling:
Returns isError=true if cast is not installed, the calldata is malformed, or the selector is unknown
| Name | Required | Description | Default |
|---|---|---|---|
| calldata | Yes | Hex-encoded calldata (0x-prefixed) | |
| signature | No | Known function signature for offline decoding, e.g. 'transfer(address,uint256)' |
| Name | Required | Description |
|---|---|---|
| values | No | |
| success | Yes | |
| signature | No |
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.
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.
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.
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.
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.
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.
Run forge inspect storage-layout and return the resolved storage slot assignment for every state variable.
Essential for proxy-upgrade safety checks (storage-layout collisions) and storage-packing gas analysis.
Args:
projectPath (string): Absolute path to the Foundry project root
contractName (string): Contract name (e.g. "Token") or fully qualified name (e.g. "src/Token.sol:Token")
Returns: JSON object: { "entries": [ { "label": string, // State variable name "slot": number, // Storage slot index "offset": number, // Byte offset within the slot "type": string, // Human-readable type (e.g. "address", "mapping(address => uint256)") "bytes": number // Size of the variable in bytes } ] }
Examples:
"Check storage layout of my proxy implementation" → contractName = "TokenV2"
"Will upgrading V1 to V2 corrupt storage?" → call once per contract, compare entries
Error Handling:
Returns isError=true if forge is not installed, the project path is invalid, or the contract is not found
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Absolute path to the Foundry project root | |
| contractName | Yes | Contract name (e.g. 'Token') or fully qualified name (e.g. 'src/Token.sol:Token') |
| Name | Required | Description |
|---|---|---|
| entries | Yes |
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.
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.
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.
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.
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.
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.
Run forge test and return structured per-suite, per-test results — including fuzz runs and the exact counterexample calldata for failing fuzz/invariant tests.
Use this to verify behavior equivalence after a rewrite, run invariant suites, or drive a Generate-Repair-Execute proof-of-concept loop.
Args:
projectPath (string): Absolute path to the Foundry project root
matchTest (string, optional): Only run test functions matching this regex (forge --match-test)
matchPath (string, optional): Only run test files matching this glob (forge --match-path)
Returns: JSON object: { "allPassed": boolean, "totalPassed": number, "totalFailed": number, "totalSkipped": number, "suites": [ { "name": string, // e.g. "test/Vault.t.sol:VaultTest" "passed": number, "failed": number, "skipped": number, "tests": [ { "name": string, // e.g. "testFuzz_withdraw(uint256)" "status": string, // "pass" | "fail" | "skip" "reason": string, // Failure reason (on fail) "counterexample": string, // Fuzz counterexample calldata + args (on fuzz fail) "gas": number, // Gas for unit tests "fuzzRuns": number, // Runs for fuzz/invariant tests "medianGas": number // Median gas for fuzz tests } ] } ] }
Examples:
"Do my invariant tests still hold?" → matchTest = "invariant"
"Verify the refactor didn't break Vault" → matchPath = "test/Vault.t.sol"
Error Handling:
Returns isError=true if forge is not installed, the path is invalid, or compilation fails (use evm_compile_and_diagnose for compiler errors)
| Name | Required | Description | Default |
|---|---|---|---|
| matchPath | No | Only run test files matching this glob | |
| matchTest | No | Only run test functions matching this regex | |
| projectPath | Yes | Absolute path to the Foundry project root |
| Name | Required | Description |
|---|---|---|
| suites | Yes | |
| allPassed | Yes | |
| totalFailed | Yes | |
| totalPassed | Yes | |
| totalSkipped | Yes |
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.
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.
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.
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.
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.
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.
Run Slither static analysis on a Solidity contract and return schema-validated vulnerability findings.
Each finding includes the detector name, severity, description, source file, line numbers, and the actual code snippet extracted from the file system.
Args:
contractPath (string): Absolute path to the Solidity file or Foundry project root
severityFilter (string[], optional): Only return findings at these severities ("High" | "Medium" | "Low" | "Informational")
maxFindings (number, optional): Cap the number of findings returned (default: all)
detectors (string[], optional): Run only these Slither detector ids (e.g. ["reentrancy-eth", "arbitrary-send-eth"]) for a focused scan
Returns: JSON object: { "findings": [ { "check": string, // Slither detector id (e.g. "reentrancy-eth") "severity": string, // "High" | "Medium" | "Low" | "Informational" "description": string, // Human-readable explanation "file": string, // Relative path to the source file "lines": number[], // Affected line numbers (1-indexed) "code_snippet": string // Extracted source code from the file } ], "totalFindings": number, // Total before truncation/capping "truncated": boolean // true if findings were dropped to fit the response limit }
Examples:
"Audit src/Vault.sol for reentrancy" → contractPath = "/path/to/src/Vault.sol"
"Run security scan on my Foundry project" → contractPath = "/path/to/project"
"Only high-severity issues" → severityFilter = ["High"]
Do NOT use for gas analysis (use evm_analyze_gas_profile instead)
Error Handling:
Returns isError=true if the path does not exist or Slither is not installed/crashes
Returns empty findings array if no vulnerabilities found
| Name | Required | Description | Default |
|---|---|---|---|
| detectors | No | Run only these Slither detector ids | |
| maxFindings | No | Cap the number of findings returned | |
| contractPath | Yes | Absolute path to the Solidity file or Foundry project root | |
| severityFilter | No | Only return findings at these severities |
| Name | Required | Description |
|---|---|---|
| findings | Yes | |
| truncated | Yes | |
| totalFindings | Yes |
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.
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.
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.
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.
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.
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.
Execute a read-only call against an EVM node using Foundry cast and return decoded results or revert reasons.
This tool does NOT submit a real transaction; it simulates via eth_call.
Args:
target (string): Target contract address (0x-prefixed, 42 chars)
signature (string): Function signature, e.g. "balanceOf(address)"
args (string, optional): Space-separated arguments for the function call
rpcUrl (string): JSON-RPC endpoint URL (e.g. http://localhost:8545)
Returns: { "success": boolean, "returnData": string, // Hex-encoded return data (on success) "revertReason": string, // Decoded revert string (on failure) "error": string // Raw error message (on execution failure) }
Examples:
"Check the balance of 0xabc..." → target=contract, signature="balanceOf(address)", args="0xabc..."
"Call the owner() function" → target=contract, signature="owner()", rpcUrl="http://localhost:8545"
Error Handling:
Returns { success: false, revertReason } if the call reverts
Returns { success: false, error } if cast is not installed or RPC is unreachable
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Space-separated arguments for the function call | |
| rpcUrl | Yes | JSON-RPC endpoint URL | |
| target | Yes | Target contract address (0x-prefixed, 42 chars) | |
| signature | Yes | Function signature, e.g. 'balanceOf(address)' |
| Name | Required | Description |
|---|---|---|
| error | No | |
| success | Yes | |
| returnData | No | |
| revertReason | No |
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.
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.
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.
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.
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.
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.
Report which host toolchain binaries (slither, forge, cast) are installed and their exact versions.
Call this once before an analysis session to (a) verify prerequisites and (b) record versions so findings are reproducible — Slither detector sets and forge gas accounting change between releases.
Args: none
Returns: JSON object: { "tools": [ { "tool": string, // "slither" | "forge" | "cast" "installed": boolean, "version": string // First line of --version output (when installed) } ] }
Error Handling:
Never errors; missing binaries are reported as installed: false
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tools | Yes |
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.
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.
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.
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.
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.
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.
Execute a read-only call with cast call --trace and return the structured call tree: every internal call, its gas cost, call type, return values, emitted events, and revert frames.
Use this to verify exploit reachability, inspect cross-contract call flows, or debug unexpected reverts. This tool does NOT submit a real transaction.
Args:
target (string): Target contract address (0x-prefixed, 42 chars)
signature (string): Function signature, e.g. "withdraw(uint256)"
args (string, optional): Space-separated arguments for the function call
rpcUrl (string): JSON-RPC endpoint URL (e.g. http://localhost:8545)
Returns: JSON object: { "reverted": boolean, // true if any frame reverted "gasUsed": number, // Total gas used (when reported) "events": [ { "depth": number, // Nesting depth in the call tree (0 = top frame) "kind": string, // "call" | "return" | "stop" | "revert" | "emit" "gas": number, // Gas for call frames "target": string, // Callee address or label "call": string, // Function + arguments "callType": string, // "staticcall" | "delegatecall" | undefined (regular call) "value": string // Return data, revert reason, or event payload } ] }
Examples:
"Why does withdraw() revert?" → trace it, read the deepest revert frame
"Does transfer() call an external contract?" → look for depth > 0 call events
Error Handling:
Returns isError=true if cast is not installed, the RPC is unreachable, or no trace was produced
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Space-separated arguments for the function call | |
| rpcUrl | Yes | JSON-RPC endpoint URL | |
| target | Yes | Target contract address (0x-prefixed, 42 chars) | |
| signature | Yes | Function signature, e.g. 'withdraw(uint256)' |
| Name | Required | Description |
|---|---|---|
| events | Yes | |
| gasUsed | No | |
| reverted | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.0evm_analyze_gas_profileevm_compile_and_diagnoseevm_decode_calldataevm_inspect_storage_layoutevm_run_testsevm_scan_vulnerabilitiesevm_simulate_transactionevm_toolchain_versionsevm_trace_callAll 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
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