Which integrations are available for this server?

Fetch, analyze, and generate audit reports for smart contracts deployed on BNB Chain via Blockscout API. Fetch, analyze, and generate audit reports for smart contracts deployed on Ethereum via Blockscout API. Fetch, analyze, and generate audit reports for smart contracts deployed on Optimism via Blockscout API. Fetch, analyze, and generate audit reports for smart contracts deployed on Polygon via Blockscout API.

How do I use MCP Contract Auditor?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Contract Auditor audit 0x1234...abcd on Ethereum" 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.

MCP Contract Auditor

by Carlys17

Overview Schema Related Servers Score Discussions

TypeScript

Remote

🔒 MCP Contract Auditor

Smart Contract Security Audit MCP Server — Fetch, analyze, and generate audit reports for EVM smart contracts.

Built for CyOps Arena Hackathon by Carlys17.

Features

Tool	Description
`audit_contract`	🔒 Full audit — fetch source, scan vulns, analyze holders, generate report
`fetch_contract`	Fetch verified contract source code & ABI from Blockscout
`scan_vulns`	Scan Solidity source for 15+ vulnerability patterns
`check_holders`	Analyze token holder distribution & centralization risk
`list_chains`	List all supported EVM chains

Related MCP server: Token Info MCP Server

Supported Chains

Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, Gnosis, Avalanche, zkSync Era, Celo — all via Blockscout API (no API key required).

Vulnerability Detection

Category	Patterns Detected
🔴 Reentrancy	Classic reentrancy, cross-function reentrancy
🟠 Access Control	Missing modifiers, tx.origin auth
🟠 External Calls	Unchecked low-level calls, delegatecall, selfdestruct
🟡 Integer	Overflow/underflow (pre-0.8), unchecked arithmetic
🟡 Denial of Service	Unbounded loops, forced ether
🟡 ERC-20	Missing return values, approve race condition
🔵 Informational	Floating pragma, inline assembly, timestamp dependence

Installation

# Clone
git clone https://github.com/Carlys17/mcp-contract-auditor.git
cd mcp-contract-auditor

# Install dependencies
npm install

# Build
npm run build

# Run
npm start

Usage with Claude Desktop

Add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "contract-auditor": {
      "command": "node",
      "args": ["/path/to/mcp-contract-auditor/dist/index.js"]
    }
  }
}

Example Usage

Full Audit

audit_contract(
  address: "0x1234...abcd",
  chain: "ethereum",
  include_holder_analysis: true
)

Quick Vulnerability Scan

scan_vulns(
  source_code: "pragma solidity ^0.8.0; contract Foo { ... }",
  contract_name: "Foo"
)

Check Token Holders

check_holders(
  address: "0x1234...abcd",
  chain: "base"
)

Architecture

mcp-contract-auditor/
├── src/
│   ├── index.ts                    # MCP server entry (5 tools)
│   ├── types.ts                    # Type definitions
│   ├── tools/
│   │   ├── analyze-vulnerabilities.ts  # 15+ vuln detectors
│   │   ├── holder-analysis.ts      # Token holder analysis
│   │   └── generate-report.ts      # Markdown report generator
│   └── utils/
│       ├── blockscout.ts           # Blockscout API client
│       └── chains.ts               # EVM chain configs
├── package.json
└── tsconfig.json

How It Works

Fetch — Retrieves verified contract source code from Blockscout API
Analyze — Runs 15+ pattern-based vulnerability detectors on the source
Holder Check — Fetches token holder data and calculates Gini coefficient
Report — Generates a structured markdown audit report with severity ratings

Disclaimer

This is an automated static analysis tool. It uses pattern matching and heuristics — it is NOT a substitute for a professional manual security audit. Always conduct thorough manual review before deploying contracts with real funds.

License

MIT

Built with ❤️ for CyOps Arena × MiniMax M3 Hackathon

Available Tools

5 tools

audit_contractA

🔒 FULL AUDIT: Fetch contract source, scan for vulnerabilities, analyze holders, generate report. One-stop smart contract audit.

ParametersJSON Schema

Name	Required	Description
`address`	Yes	Contract address (0x...)
`chain`	Yes	Chain: "ethereum", "base", "arbitrum", "bsc", "polygon", etc.
`include_holder_analysis`	No	Include token holder analysis (default: true)

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It lists the steps but does not disclose behavioral traits like time requirements, destructive actions, authentication needs, or rate limits. For a 'full audit', more transparency is needed.

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 a single concise sentence with emoji, efficiently conveying the tool's purpose. It is front-loaded and brief, though it could benefit from structured bullet points for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema or annotations, the description should detail what the report contains. It only mentions 'generate report' without specifying format or how results are presented, leaving gaps for a complex multi-step tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions (address, chain list, include_holder_analysis default). The description adds context but not new parameter-level info beyond schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it's a full smart contract audit combining multiple sub-tasks (fetch source, scan vulnerabilities, analyze holders, generate report). It distinguishes from siblings like check_holders, fetch_contract, scan_vulns by being the one-stop solution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for a comprehensive audit, with sibling tools for individual steps. However, it doesn't explicitly state when to use alternatives or provide exclusions, leaving some inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_holdersB

Analyze token holder distribution for centralization and rug-pull risk

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Token contract address (0x...)
`chain`	Yes	Chain name: "ethereum", "base", "bsc", etc.

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It only states 'analyze', which implies read-only, but does not confirm whether it is a safe read operation, whether it makes external calls, or any potential side effects. No mention of data freshness, auth needs, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that conveys the core purpose without any extraneous words. It is front-loaded and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of analyzing token holder distribution for risk, the description lacks details about what constitutes a risk signal, how the analysis is performed, or the output format. With no output schema, the agent is left guessing about return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already provides clear descriptions for both parameters ('Token contract address (0x...)' and 'Chain name: "ethereum", "base", "bsc", etc.'). The tool description adds no further meaning beyond the schema, so baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Analyze' and clearly identifies the resource 'token holder distribution' with the explicit purpose of assessing 'centralization and rug-pull risk'. This distinguishes it from sibling tools like 'audit_contract' (security audit) and 'scan_vulns' (vulnerability scanning).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor are prerequisites or exclusions mentioned. The description merely states the tool's function without contextualizing its use relative to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_contractA

Fetch verified smart contract source code and ABI from Blockscout

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Contract address (0x...)
`chain`	Yes	Chain name or ID: "ethereum", "base", "arbitrum", "bsc", "polygon", etc.

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description only says 'fetch', implying a read operation. It lacks disclosure of potential rate limits, authentication needs, or whether the data is always up-to-date. Minimal behavioral context.

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?

A single sentence that efficiently communicates the core purpose. No filler or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description states the output (source code and ABI) but does not specify the format (e.g., JSON) or potential error conditions. For a simple fetch tool, it is mostly adequate but could include a hint about the response structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters have clear descriptions in the input schema (address and chain). The description does not add any extra meaning beyond what the schema already provides, such as format or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'fetch', the resource 'verified smart contract source code and ABI', and the data source 'Blockscout', distinguishing it from sibling tools like audit_contract.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving smart contract code and ABI, but does not explicitly state when to use this tool versus alternatives (e.g., for audits use audit_contract). No when-not-to-use advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_chainsA

List all supported EVM chains for contract auditing

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description discloses that the tool lists chains, which is a safe read operation, but does not mention any potential behaviors like authentication needs or limitations. Given the simplicity, it is adequate but minimal.

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 a single, clear 7-word sentence with no superfluous information. It is optimally concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description sufficiently explains its purpose. It could hint that listing chains is a prerequisite for other chain-specific tools, but this is not essential.

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?

There are zero parameters, and schema coverage is 100%. The description does not need to add parameter details, meeting the baseline for no-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list', the resource 'all supported EVM chains', and the context 'for contract auditing'. It effectively distinguishes from sibling tools like audit_contract or scan_vulns, which operate on specific chains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. Usage is implied but not clarified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scan_vulnsC

Scan Solidity source code for common security vulnerabilities (reentrancy, overflow, access control, etc.)

ParametersJSON Schema

Name	Required	Description	Default
`source_code`	Yes	Solidity source code to analyze
`contract_name`	No	Contract name (for report context)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It only states basic scanning capability without disclosing accuracy, output format, or whether it modifies state. Minimal behavioral context is provided.

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 a single well-formed sentence, front-loaded with the main action. It is concise, though could benefit from additional details without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool scans for vulnerabilities but the description does not explain return values, output structure, or limitations. Without an output schema, more context is needed for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds a list of vulnerability types but does not enhance parameter understanding beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Scan' and specifies the resource 'Solidity source code', listing example vulnerabilities (reentrancy, overflow, access control). It is clear but does not explicitly distinguish from sibling 'audit_contract', which may perform broader analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., audit_contract). It lacks exclusions or context about prerequisites or limitations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Tools are largely distinct with clear purposes. However, `audit_contract` is a composite that includes functionality of `scan_vulns` and `check_holders`, which could cause some confusion, but descriptions clarify the difference.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case (e.g., audit_contract, list_chains), making it easy for an agent to predict tool names.

Tool Count5/5

Five tools is well-scoped for a contract auditor server, covering the essential operations without being overwhelming or insufficient.

Completeness4/5

The tool set covers fetching, scanning, holder analysis, and full auditing with chain listing. Missing features like audit history or detailed chain info are minor gaps.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

yultrace-audit A
com.trycloudflare.urgent-clean-occupied-catalogs
EVM audit (Slither + source + security.txt + MCP-probe + wallet-exposure). 6 tools + /trace.
Code Analysis Blockchain Security
2
token-safety A
ai.tachyo
Instant rug-check for any EVM or Solana token, distilled to one clear 0-10 risk verdict.
Blockchain Cryptocurrency
12
DeFade — Multi-Chain Memecoin Analyzer A
org.defade
Rug pull risk and on-chain forensics for tokens on Solana, Ethereum, Base and Robinhood.
Blockchain Cryptocurrency Web3 & Decentralized Tech
151
hostdefi-x402 A
io.github.verixiaapps
Free token-safety scans + paid x402 verdicts, signals, radar & EVM swap quotes for AI agents.
Blockchain Cryptocurrency Finance
151

Related MCP Servers

Contract Inspector MCP
Blockchain Code Execution Web3 & Decentralized Tech
ACaiSec
F
license
B
quality
D
maintenance
A local Ethereum contract analysis tool that retrieves on-chain information, integrates Etherscan and RPC data, and automatically executes view functions to provide comprehensive contract insights.
Updated a year ago (2025-06-30 09:55 UTC)
2
3
Token Info MCP Server
Blockchain Web3 & Decentralized Tech Security
0xwuchuan
F
license
Not graded
quality
D
maintenance
Provides comprehensive smart contract analysis for EVM tokens, including proxy contract detection, ownership chain discovery, and OpenZeppelin AccessControl role management across multiple blockchain networks.
Updated a year ago (2025-07-03 09:52 UTC)
contract-auditor
Blockchain Security Cryptocurrency
Baneado98
A
license
A
quality
B
maintenance
Quick-scan a smart contract for rug, honeypot, or centralization risk before sending funds. It combines verified source, live on-chain state, and heuristic Solidity analysis to return a SAFE/CAUTION/HIGH-RISK verdict.
Updated 2 months ago (2026-06-22 16:43 UTC)
1
MIT
solidity-sentinel
Code Analysis Blockchain
Baneado98
A
license
A
quality
C
maintenance
Enables static security audit of Solidity smart contracts by analyzing source code or deployed bytecode for vulnerabilities, providing risk scores and detailed findings.
Updated 2 months ago (2026-06-23 20:33 UTC)
1
MIT

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/Carlys17/mcp-contract-auditor'

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