The Elytra Security MCP Server provides AI coding agents with security scanning tools for code and smart contracts, exploit pattern testing, and agent identity verification.
Scan code snippets for vulnerabilities (elytra_scan): Analyze source code in Solidity, Vyper, JS/TS, Python, Go, Rust, Java, Ruby, PHP, or IaC formats (Terraform, Kubernetes, Dockerfile, GitHub Actions) for security issues. Returns findings with severity ratings, fix suggestions, and a 0–100 security score.
Scan deployed smart contracts by address (elytra_scan_address): Fetch and analyze the verified source code of a live onchain contract using its 0x... address across Ethereum, Base, Arbitrum, Optimism, and Polygon.
Replay famous exploit patterns (elytra_replay_hacks): Test code against 12 historically significant exploit patterns representing $3.04B+ in combined losses (Bybit, Ronin, Euler, Beanstalk, Multichain, Curve, Radiant, zkSync, Cream, Wormhole, Nomad, Mango) to check if your code is vulnerable to similar mistakes.
Retrieve Elytra's agent identity (elytra_agent_identity): Access Elytra's onchain ERC-8004 agent card, including capabilities, pricing on Base and Solana, attestation count, and discovery endpoints — useful for programmatic integration or agent verification.
Allows scanning deployed contracts on Ethereum by address, using Elytra's security tools to detect vulnerabilities and check exploit patterns.
Allows scanning deployed contracts on Optimism by address, using Elytra's security tools to detect vulnerabilities and check exploit patterns.
Allows scanning deployed contracts on Polygon by address, using Elytra's security tools to detect vulnerabilities and check exploit patterns.
Allows scanning deployed contracts on Solana by address, using Elytra's security tools to detect vulnerabilities and check exploit patterns.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Elytra Security MCP Server Scan this Solidity contract for vulnerabilities"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Elytra Security as a Model Context Protocol server. Give your AI coding agent (Claude Desktop, Cursor, Cline, Zed) the ability to scan smart contracts and code, check 12 famous-hack patterns, and return public Elytra security receipts — without leaving the IDE.
173 detection rules. ERC-8004 verified agent. x402 pay-per-call in USDC on Base + Solana.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"elytra": {
"command": "npx",
"args": ["-y", "@elytrasec/mcp@latest"]
}
}
}Restart Claude Desktop. The 4 Elytra tools appear in the MCP indicator.
Settings → MCP → Add server:
{ "command": "npx", "args": ["-y", "@elytrasec/mcp@latest"] }Same one-liner — install as a stdio server with the npx command above.
Related MCP server: Cybrium MCP Server
Tool | What it does |
| Scan a code snippet for security vulnerabilities |
| Scan a deployed contract by 0x address (Ethereum / Base / Arbitrum / Optimism / Polygon) |
| Test code against 12 famous-exploit patterns ($3.04B combined losses): Bybit, Ronin, Euler, Beanstalk, Multichain, Curve, Radiant, zkSync, Cream, Wormhole, Nomad, Mango |
| Return Elytra's onchain agent card (ERC-8004, pricing, capabilities) |
This MCP server is a thin, read-only client over Elytra's public HTTP API. Specifically:
No shell execution. The server never spawns child processes or executes shell commands.
No file writes. The server reads nothing from disk and writes nothing to disk.
No private keys. The server never reads, requests, generates, or stores private keys.
No wallet signing. The server never signs transactions or messages. Any onchain payments (x402) are settled by Elytra's facilitators, not by this server.
Sends only what you ask it to. Each tool call forwards exactly the code, address, or query the AI agent passed in — nothing more. No telemetry, no ambient file reads, no background uploads.
May return public receipt URLs. Depending on Elytra's API mode, a scan can produce a public receipt page at https://elytrasec.io/r/<id>. The URL is returned to you; you decide whether to share it.
ELYTRA_API_KEY — Bearer key for the paid /api/v1/scan endpoint (bypasses x402 micropayment for higher throughput). Contact hello@elytrasec.io.
ELYTRA_BASE_URL — Override the default https://elytrasec.io (for self-hosting).
All tools above hit Elytra's free public endpoints. For higher rate limits or AI-powered deep review, the underlying API supports x402 pay-per-call in USDC on Base or Solana (1¢ per scan, 2¢ per review).
@elytrasec/cli — same detectors, command-line. npx -y @elytrasec/cli scan .
ElytraSec/elytra-action — drop into a GitHub Actions workflow.
@elytrasec/engine — the underlying analysis library.
Website: https://elytrasec.io
Playground (interactive): https://elytrasec.io/playground
Hack Replay Library: https://elytrasec.io/hacks
Agent card: https://elytrasec.io/.well-known/agent-card.json
MIT
Return Elytra's onchain agent identity card — ERC-8004 registry data, capabilities, pricing on Base and Solana, attestation count, and discovery endpoints. Use this when the user wants to verify or learn about the Elytra agent itself, integrate it programmatically, or compare it to other agents.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses what data is returned (registry, capabilities, pricing, etc.) but does not mention any potential limitations, authentication needs, or side effects. For a simple read-only tool, it adequately describes the output but could be more transparent about any prerequisites or rate limits.
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?
Two sentences: first defines the action and data, second provides usage context. No redundant information. Highly efficient and front-loaded.
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 no output schema, the description lists key return elements (registry data, capabilities, pricing, attestation count, discovery endpoints). This covers most essential information an agent would need to understand the tool's output. It could be more explicit about the format, but it is sufficient for a zero-parameter tool.
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?
There are zero parameters, so the baseline is 4. The description adds meaning by specifying the output content types, which compensates for the lack of parameter details. It provides context beyond the empty 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?
Description clearly states it returns Elytra's onchain agent identity card with specific data like ERC-8004 registry, capabilities, pricing, attestation count, and discovery endpoints. The verb 'Return' and resource 'onchain agent identity card' are precise. Sibling tools (replay, scan) operate on different objects, so this tool is well-distinguished.
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?
Explicitly says when to use: when the user wants to verify/learn about the Elytra agent, integrate it, or compare to others. It does not explicitly mention when not to use or alternatives, but the usage guidance is clear and contextually appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the 12 famous-exploit pattern detectors against submitted source code. Encodes patterns from $3.04B in losses: Bybit ($1.46B), Ronin ($625M), Wormhole ($325M), Euler ($197M), Nomad ($190M), Beanstalk ($182M), Cream ($130M), Multichain ($126M), Mango ($114M), Curve ($73M), Radiant ($53M), zkSync ($5M). Returns only matches against these specific historic attack vectors. Use this when you want to check 'have I made any of the famous mistakes?'
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The source code to test against hack-replay patterns | |
| language | No | Language hint | solidity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool returns only matches against specific historic attack vectors, implying it is read-only and has no side effects. No destructive behavior is mentioned, nor is authorization required. This is adequate transparency for a scanner.
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 informative but slightly verbose with dollar amounts and many examples. It front-loads the core purpose and gives a usage hint. Every sentence is relevant, though the examples could be shortened. Still, it is well-structured and easy to parse.
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 moderate complexity, the description is complete. It explains what the tool does, what it returns (only matches against specific attack vectors), and has no output schema, so the description covers the return behavior. No gaps are apparent.
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?
The input schema has 100% coverage with descriptions for both parameters (`code` and `language`). The description does not add further parameter-specific details beyond the schema, though it enriches the overall context. Baseline 3 is appropriate as schema already clarifies the parameters.
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 runs 12 famous-exploit pattern detectors against source code, listing specific examples like Bybit and Ronin. It clearly identifies the verb ('run detectors') and resource ('submitted source code'), distinguishing it as a specialized security scanner.
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 a clear usage scenario: 'Use this when you want to check have I made any of the famous mistakes?' It implies a specific context but does not explicitly exclude other uses or compare with sibling tools (elytra_scan, elytra_scan_address). Still, the guidance is practical and direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a code snippet for security vulnerabilities. Supports Solidity, Vyper, JS/TS, Python, Go, Rust, Java, Ruby, PHP, plus IaC (Terraform, Kubernetes, Dockerfile, GitHub Actions). Returns findings with severity, fix suggestions, and a 0-100 score. Use this for security-focused code review.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The source code to scan | |
| language | No | Language hint: javascript | typescript | python | go | java | ruby | php | solidity | rust | javascript |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as scanning code and returning results, implying read-only behavior, but lacks details on side effects, authorization, or resource limits. The description is adequate but could be richer.
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 reasonably concise, front-loading the purpose and listing supported languages and outputs. A few extraneous details could be trimmed, but no significant waste.
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 no output schema, the description explains return values (severity, fix suggestions, score). It covers supported languages and intended use. Missing aspects like file size limits or error handling, but overall sufficient for a scanning tool.
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?
The input schema covers both parameters with 100% description coverage, but the description adds value by expanding the list of supported languages beyond the schema's enum, including Vyper and IaC. This helps the agent understand additional valid values.
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 scans code for security vulnerabilities, lists supported languages, and mentions outputs (findings with severity, fix suggestions, score). It effectively distinguishes from siblings like elytra_agent_identity (identity info) and elytra_scan_address (address scanning).
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 states 'Use this for security-focused code review,' providing clear context for when to use it. However, it does not mention when not to use or provide alternatives, missing some exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a DEPLOYED smart contract by its onchain address. Elytra fetches the verified source from the block explorer (Etherscan / Basescan / etc.) and scans every source file. Use this when the user gives you a 0x... address and asks about its security.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Contract address (0x... 40 hex chars) | |
| chain | No | ethereum | base | arbitrum | optimism | polygon | ethereum |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It explains the behavior of fetching and scanning source, but omits potential edge cases like unverified contracts, error responses, or output format.
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?
Three concise sentences front-load the purpose, describe the mechanism, and provide a usage cue. No unnecessary 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 two simple parameters and no output schema, the description covers the core function and usage. Minor gaps like verification requirement or output details prevent a 5.
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 covers 100% of parameters with descriptions, so the description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate.
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 'Scan a DEPLOYED smart contract by its onchain address' and explains the process with Elytra, clearly distinguishing it from sibling tools like elytra_replay_hacks and elytra_scan.
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 usage guideline: 'Use this when the user gives you a 0x... address and asks about its security.' It does not mention when not to use or alternatives, but the context is sufficient for the specific tool.
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.
v0.2.0elytra_agent_identityelytra_replay_hackselytra_scanelytra_scan_addressScored across 4 tools
elytra_scan and elytra_scan_address both perform vulnerability scanning, differing mainly by input type, while elytra_replay_hacks also scans source code but for a narrower set of known exploits. The descriptions help clarify boundary cases, but some selection ambiguity remains between general scanning and exploit-pattern replay.
All tools share the consistent 'elytra_' prefix and most use a verb_noun style, such as elytra_scan and elytra_replay_hacks. elytra_agent_identity deviates from the verb-led pattern, making it slightly inconsistent but still readable and predictable.
Four tools is a well-scoped count for a specialized security-scanning server. Each tool covers a distinct workflow: snippet scanning, deployed-contract scanning, exploit-pattern replay, and agent identity.
The tool surface covers the core security scanning workflows well, including source snippets, deployed contracts, and known historical exploits. Minor gaps exist, such as scanning repositories or pull requests directly, but agents can work around these with the snippet scanner.
Read-only smart-contract security intelligence for autonomous agents.
Pay-per-call cybersecurity for AI agents: vuln scans, threat intel, compliance, code security.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
AI security scanner for Solidity + free CC0 dataset of Sherlock audit-competition acceptance rates.
