Skip to main content
Glama
RockYuan

MCP Smart Contract Analyst

by RockYuan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

MCP Smart Contract Analyst / 智能合约分析器

@author Ry @RockRockDay

Implements a Model Context Protocol (MCP) server to interact with the Monad blockchain for smart contract source code analysis, including functionality and security evaluation.

实现了一个 Model Context Protocol (MCP) 服务器，用于与 Monad 区块链交互，进行智能合约源代码的功能性与安全性分析。

For unverified contracts, decompilation is used to assist in source code recovery and review.

对于未验证的合约，将尝试进行反编译以辅助恢复和审查源代码。

What is MCP? / 什么是 MCP？

The Model Context Protocol (MCP) is a standard that allows AI models to interact with external tools and services.

Model Context Protocol（模型上下文协议，简称 MCP）是一种标准，允许 AI 模型与外部工具和服务进行交互。

Related MCP server: Web3 Assistant MCP

Prerequisites

  • Node.js (v16 or later)

  • npm or yarn

  • Claude Desktop / Cursor ide / more...

Getting Started

  1. Clone this repository

git clone https://github.com/rockyuan/mcp-contract-analyst.git

  1. Install dependencies:

npm install

  1. Build the project

npm run build

The server is now ready to use!

Adding the MCP server to Cursor

  1. Open "Cursor".

  2. Open Settings.

Cursor > Settings > Cursor Settings > MCP

  1. Click "Add a new global MCP server".

  2. Add details about the MCP server and save the file.

{
  "mcpServers": {
    "mcp-contract-analyst": {
      "command": "node",
      "args": ["/<path-to-project>/build/index.js"],
      "env": {
        "API_URL": "https://api.blockvision.org/v2/monad/contract/source/code?address=",
        "API_KEY": "xxxxxxxxxxx",
        "DECOMPILE_URL": "https://www.ethervm.io/decompile"
      }
    }
  }
}

  1. Refresh Cursor.

Using the MCP server

Adding the MCP server to Claude Desktop

  1. Open "Claude Desktop"

  2. Open Settings

Claude > Settings > Developer

  1. Open claude_desktop_config.json

  2. Add details about the MCP server and save the file.

{
  "mcpServers": {
    "mcp-contract-analyst": {
      "command": "node",
      "args": ["/<path-to-project>/build/index.js"],
      "env": {
        "API_URL": "https://api.blockvision.org/v2/monad/contract/source/code?address=",
        "API_KEY": "xxxxxxxxxxx",
        "DECOMPILE_URL": "https://www.ethervm.io/decompile"
      }
    }
  }
}

  1. Restart "Claude Desktop"

Further Resources

Thanks

Available Tools

2 tools
analyze-unverified-contractC

Analyze a unverified contract from an address on the Monad testnet.

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesMonad testnet address to analyze unverified contract for

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('analyze') but doesn't describe what analysis entails, whether it's read-only or has side effects, what permissions or authentication might be needed, or any rate limits. For a tool with zero annotation coverage, this is a significant gap in 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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted text, making it easy for an agent to parse quickly.

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 contract analysis, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'analyze' means in practice, what information is returned, or how to interpret results. For a tool that likely involves technical blockchain operations, this leaves critical gaps for an agent.

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

Parameters3/5

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

The description adds no parameter-specific information beyond what's already in the schema (which has 100% coverage). It mentions 'address' generally but doesn't elaborate on format, validation, or semantic meaning. With high schema coverage, the baseline is 3, and the description doesn't compensate with additional insights.

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 clearly states the action ('analyze') and target resource ('unverified contract from an address on the Monad testnet'), providing specific verb+resource pairing. However, it doesn't explicitly differentiate from its sibling 'analyze-verified-contract' beyond the 'unverified' qualifier, which is implied but not stated as a distinguishing factor.

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. The description mentions 'unverified contract' but doesn't explain what constitutes unverified vs. verified, when to choose this over 'analyze-verified-contract', or any prerequisites for usage. This leaves the agent without contextual decision-making criteria.

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

analyze-verified-contractC

Analyze a verified contract from an address on the Monad testnet.

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesMonad testnet address to analyze verified contract for

TDQS

C2.9/5.0
Behavior2/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 of behavioral disclosure. It states the action ('analyze') but doesn't explain what analysis entails (e.g., returns contract code, metadata, or insights), potential errors (e.g., invalid addresses), or side effects. This leaves significant gaps in understanding the tool's behavior.

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 directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the analysis returns (e.g., contract details, vulnerabilities) or handle complexities like error cases, which are crucial for a tool interacting with blockchain data. This falls short of providing enough context for effective use.

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

Parameters3/5

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

The schema description coverage is 100%, with the single parameter 'address' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., format constraints or examples), so it meets the baseline of 3 where the schema does the heavy lifting.

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 clearly states the action ('analyze') and resource ('verified contract from an address on the Monad testnet'), making the purpose understandable. However, it doesn't explicitly differentiate from its sibling tool 'analyze-unverified-contract' beyond the 'verified' qualifier, which is implied but not contrasted directly.

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, such as its sibling 'analyze-unverified-contract'. It lacks context about prerequisites (e.g., what constitutes a 'verified' contract) or exclusions, leaving usage decisions ambiguous.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • First observedanalyze-unverified-contract
    • First observedanalyze-verified-contract
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one analyzes unverified contracts and the other analyzes verified contracts on the Monad testnet. There is no overlap or ambiguity between them, as the verification status is a binary distinction that cleanly separates their use cases.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with 'analyze' as the verb and descriptive adjectives ('unverified', 'verified') modifying the noun 'contract'. The naming is perfectly uniform and predictable across the set.

Tool Count2/5

With only 2 tools, the server feels thin for a 'Smart Contract Analyst' domain. While the tools cover analysis of both verified and unverified contracts, the scope suggests potential for more analytical operations (e.g., security checks, gas estimation, function analysis), making the current count insufficient for comprehensive analysis.

Completeness2/5

The server is severely incomplete for smart contract analysis. It only provides basic analysis based on verification status, missing essential operations like vulnerability scanning, gas optimization suggestions, code complexity metrics, or interaction with contract functions. This limited surface will likely cause agent failures when deeper analysis is required.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Web3 Assistant MCP

    LaplaceMan
    F
    license
    B
    quality
    D
    maintenance
    Enables secure interaction with blockchain smart contracts across multiple chains, including ABI analysis, contract method invocation (view/nonpayable/payable), and local wallet management for Ethereum and Base networks.
    3
    1
    -

  • Onchain MCP Server

    0xGval
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides tools for querying onchain data across 12+ blockchain networks, including token balances, transaction analysis, and smart contract security auditing. It enables users to interact with multiple EVM-compatible chains and perform deep contract evaluations through natural language interfaces.
    1
    -

Appeared in Searches