该 MCP（模型上下文协议）服务器旨在与 Monad 测试网交互。它为开发者提供了一套工具和功能，用于与 Monad 区块链交互，包括检查 MON 代币余额、发送交易、部署智能合约以及监控区块链事件。
模型上下文协议 (MCP) 是一个标准化接口，使 AI 模型能够安全有效地与外部工具、服务和数据源交互。该服务器实现了 MCP，以便将 Monad 区块链功能暴露给兼容的 AI 代理或应用程序。
Related MCP server: Solana MCP Server
该项目组织如下：
monad-mcp-server/
├── .env.example # Example environment variables file
├── .gitignore # Specifies intentionally untracked files that Git should ignore
├── LICENSE # Project's software license
├── README.md # This file, providing an overview and instructions
├── package-lock.json # Records the exact versions of dependencies
├── package.json # Lists project dependencies and scripts
├── pnpm-lock.yaml # PNPM lockfile for dependency resolution
├── src/ # Source code directory
│ ├── config/ # Configuration files
│ │ └── server.ts # Server setup and Viem client initialization
│ ├── index.ts # Main entry point of the application
│ └── tools/ # MCP tools for interacting with Monad
│ ├── block/ # Tools related to blockchain blocks (e.g., get-latest-block)
│ ├── contract/ # Tools for smart contract interactions (e.g., deploy, watch events)
│ ├── nft/ # Tools for Non-Fungible Tokens (e.g., query-mon-nft)
│ └── wallet/ # Tools for wallet operations (e.g., get balance, send transactions)
└── tsconfig.json # TypeScript compiler configurationsrc/index.ts ：这是服务器的主入口。它初始化 MCP 服务器实例并注册所有可用工具（钱包、合约、NFT、区块）。
src/config/server.ts ：此文件处理核心服务器配置。它设置McpServer实例的名称、版本和功能列表。它还初始化Viem公共客户端以便与 Monad 测试网交互，并提供了一个函数，可以使用来自环境变量的私钥创建Viem钱包客户端。服务器使用StdioServerTransport进行通信。
src/tools/ ：此目录包含各种 MCP 工具的实现。每个子目录通常侧重于 Monad 交互的特定方面：
walletProvider ：管理 MON 代币余额和交易。
contractProvider ：处理智能合约部署和事件监视。
nftProvider ：提供在 Monad 网络上查询 NFT 的功能。
blockProvider ：提供检索块信息的工具。
开始之前，请确保已安装以下软件：
Node.js（版本 16 或更高版本）
Node.js 包管理器： npm 、 yarn或pnpm （本项目在其示例中使用pnpm ）
Claude Desktop（或任何与 MCP 兼容的客户端）与服务器交互。
该项目使用环境变量来管理敏感信息，主要是您的 Monad 帐户的私钥。
复制示例文件：创建.env.example的副本并将其重命名为.env 。
cp .env.example .env编辑.env ：在文本编辑器中打开新创建的.env文件。
设置PRIVATE_KEY ：将你的 Monad 帐户的私钥填入PRIVATE_KEY变量中。此密钥对于发送交易或部署合约等操作是必需的。
PRIVATE_KEY="0xyourprivatekeyhere"重要提示：确保您的私钥以0x开头。
安全性：切勿将.env文件提交到 Git 仓库。.gitignore .gitignore已配置为防止这种情况发生，但请务必注意保护您的私钥。
按照以下步骤设置并运行 Monad MCP 服务器：
克隆存储库：
如果还没有，请从 GitHub 克隆该项目：
git clone https://github.com/lispking/monad-mcp-server.git
cd monad-mcp-server安装依赖项：
使用pnpm （或您首选的包管理器）安装package.json中列出的项目依赖项：
pnpm install构建项目：
该服务器是用 TypeScript 编写的，需要编译成 JavaScript。运行构建脚本：
pnpm build此命令将使用package.json中定义的tsc （TypeScript 编译器）将src目录中的源文件编译到build目录中。
服务器现已构建并可供 MCP 客户端使用。
根据src/config/server.ts中的定义，服务器公开以下功能：
get-mon-balance ：检索帐户的 MON 代币余额。
send-mon-transaction ：将 MON 代币从一个账户发送到另一个账户。
deploy-mon-contract ：将智能合约部署到 Monad 测试网。
watch-contract-events ：监控并报告特定智能合约发出的事件。
query-mon-nft ：查询有关 Monad 网络上非同质化代币的信息。
get-latest-block ：获取 Monad 测试网上最新区块的详细信息。
get-block-by-number ：通过块编号检索特定块。
要将此服务器与兼容 MCP 的客户端（例如 Claude Desktop）一起使用，您需要将其配置添加到客户端的设置中。具体方法可能因客户端而异，但通常涉及指定如何运行服务器。
以下是示例配置片段：
{
"mcpServers": {
// ... other server configurations ...
"monad-mcp": {
"command": "node",
"args": [
"/absolute/path/to/your/project/monad-mcp-server/build/index.js"
],
"env": {
"PRIVATE_KEY": "<your_monad_private_key_if_not_using_dotenv_or_to_override>"
}
}
// ... other server configurations ...
}
}配置字段说明：
"monad-mcp" ：您在客户端中分配给此服务器配置的唯一名称。
"command": "node" ：指定服务器是 Node.js 应用程序。
"args" ：传递给node命令的参数数组。
第一个参数是服务器编译入口点的路径： /absolute/path/to/your/project/monad-mcp-server/build/index.js 。将/absolute/path/to/your/project/替换为您克隆monad-mcp-server仓库的实际绝对路径。
"env" ：为服务器进程设置环境变量的对象。
"PRIVATE_KEY" ：您可以在此处设置私钥。不过，为了提高安全性，通常建议使用.env文件。如果在此处设置，它可能会覆盖.env中的值，具体取决于客户端的行为和服务器的环境变量加载顺序。
注意：确保"args"中的路径正确并指向项目目录中的build/index.js文件。
有关所使用的技术和涉及的概念的更多详细信息，请参阅以下官方文档：
Viem 文档（Viem 是本项目使用的以太坊/Monad 客户端库）
这个全面的自述文件应该能帮助您深入了解 Monad MCP 服务器、其设置和用法。
Deploy a smart contract on Monad testnet
| Name | Required | Description | Default |
|---|---|---|---|
| abi | Yes | Contract ABI | |
| bytecode | Yes | Contract bytecode | |
| constructorArgs | No | Constructor arguments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'testnet' which implies non-production use, but doesn't disclose critical traits like whether deployment is irreversible, requires gas fees, has rate limits, or returns a contract address. For a deployment tool, this is a significant gap.
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 a single, focused sentence with zero wasted words. It's appropriately sized for a straightforward deployment tool and front-loads the essential action and target environment.
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?
For a contract deployment tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deployment (e.g., returns contract address, transaction hash), error conditions, or environmental constraints. Given the complexity of smart contract deployment, more context is needed.
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 description coverage is 100%, so the schema already documents all three parameters adequately. The description adds no additional parameter context beyond what's in the schema (e.g., format examples, relationship between parameters). This meets the baseline for high schema coverage.
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 action ('deploy') and resource ('smart contract on Monad testnet'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'send-mon-transaction' which might also involve contract interactions, so it doesn't reach the highest score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing ABI/bytecode), compare to other deployment methods, or specify use cases like testing vs production. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a block by number on Monad testnet
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The block number to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a block but omits critical details such as whether it's a read-only operation (implied by 'Get'), error handling for invalid block numbers, rate limits, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes essential information, earning its place with zero 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 the complexity of blockchain operations, no annotations, and no output schema, the description is incomplete. It lacks details on return values (e.g., block structure), error cases, network-specific behaviors, or how it fits within the sibling toolset. For a tool with such sparse structured data, more context is needed to be fully helpful.
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% description coverage, with the 'number' parameter documented as 'The block number to retrieve'. The description adds no additional meaning beyond this, such as format details (e.g., integer vs. hex) or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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 action ('Get') and resource ('a block by number'), specifying the target network ('on Monad testnet'). It distinguishes from siblings like 'get-latest-block' by focusing on specific block numbers rather than the latest. However, it doesn't explicitly contrast with all siblings, such as 'query-mon-nft' or 'watch-contract-events', which is why it's a 4 rather than a 5.
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 minimal guidance, implying usage when a specific block number is known on the Monad testnet. It lacks explicit when-to-use scenarios, alternatives (e.g., using 'get-latest-block' for recent blocks), or exclusions (e.g., not for querying NFTs). No context on prerequisites or limitations is given, making it basic but not entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest block on Monad testnet
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool does but provides no information about rate limits, authentication requirements, network behavior, error responses, or what 'latest' means in practical terms (e.g., is it cached, real-time, etc.). For a blockchain query tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple query tool and front-loads the essential information. Every word earns its place in this minimal description.
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 that this is a blockchain query tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the block data will be returned in, what fields to expect, or any behavioral characteristics. For a tool that presumably returns complex blockchain data, more context about the response would be helpful despite the lack of output schema.
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 tool has zero parameters, and schema description coverage is 100%. The description appropriately doesn't discuss parameters since none exist. It could theoretically mention that no parameters are required, but this is adequately covered by the structured schema. With 0 parameters, the baseline is appropriately high.
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 action ('Get') and resource ('latest block on Monad testnet'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get-block-by-number', but the focus on 'latest' provides some distinction. The description is specific enough to understand what the tool does without being tautological.
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 no guidance on when to use this tool versus alternatives like 'get-block-by-number'. It doesn't mention prerequisites, error conditions, or any context about when this specific tool is appropriate. The agent must infer usage from the tool name alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get MON balance for an address on Monad testnet
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Monad testnet address to check balance for |
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 what the tool does but lacks critical behavioral details: it doesn't specify if this is a read-only operation, mention rate limits, error conditions, or what format the balance returns (e.g., in wei or MON tokens).
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. However, it could be slightly more structured by explicitly stating it's a read operation or including key constraints, which would enhance clarity without sacrificing brevity.
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 low complexity (one parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but omits behavioral context (e.g., read-only nature, return format) that would help an agent use it correctly, especially with no annotations to fill 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?
The schema description coverage is 100%, with the single parameter 'address' well-documented in the schema as 'Monad testnet address to check balance for'. The description adds no additional parameter semantics beyond this, so it meets the baseline for high schema coverage.
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 action ('Get MON balance') and resource ('for an address on Monad testnet'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-block-by-number' or 'query-mon-nft', which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid testnet address) or compare it to sibling tools like 'send-mon-transaction' for balance changes, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query NFT information on Monad testnet
| Name | Required | Description | Default |
|---|---|---|---|
| contractAddress | Yes | NFT contract address | |
| tokenId | Yes | Token ID of the NFT |
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 but only states the action without details on permissions, rate limits, or response format. It doesn't mention if this is a read-only operation or potential side effects, which is inadequate for a tool with no annotation support.
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 a single, efficient sentence with no wasted words, clearly front-loading the core purpose. It's appropriately sized for a simple query tool, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what information is returned (e.g., metadata, owner), how errors are handled, or any behavioral traits, leaving gaps for the agent to understand the tool's full context.
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 schema description coverage is 100%, so the input schema already documents both parameters thoroughly. The description doesn't add any extra meaning about the parameters beyond what the schema provides, meeting the baseline for high schema coverage.
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 action ('Query') and resource ('NFT information on Monad testnet'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'get-mon-balance' or 'get-block-by-number' that also query blockchain data, which prevents a perfect score.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as needing a contract address and token ID, or comparisons to other query tools in the sibling list, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send MON transaction on Monad testnet
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount of MON to send | |
| to | Yes | Recipient address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but lacks critical details: it doesn't specify if this requires authentication, what the transaction cost or gas implications are, whether it's irreversible, or what the expected response format is. This is a significant gap for a transaction tool.
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 a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a transaction tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, error handling, or return values, leaving the agent with insufficient context to use the tool safely and effectively.
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% description coverage, clearly documenting both parameters ('amount' and 'to'). The description adds no additional parameter semantics beyond what the schema provides, such as format details (e.g., address format, unit for amount) or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Send MON transaction') and specifies the target environment ('on Monad testnet'), which distinguishes it from mainnet operations. However, it doesn't differentiate from potential sibling tools like 'deploy-mon-contract' that might also involve transactions, leaving room for improvement in sibling distinction.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a wallet or balance), exclusions, or comparisons to sibling tools like 'deploy-mon-contract' for contract deployments or 'get-mon-balance' for checking funds first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Watch for smart contract events on Monad testnet
| Name | Required | Description | Default |
|---|---|---|---|
| abi | Yes | Contract ABI | |
| address | Yes | Contract address to watch | |
| eventName | Yes | Name of the event to watch | |
| fromBlock | No | Start watching from this block number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'watch for' events, implying a monitoring or subscription-like behavior, but doesn't clarify if this is a one-time query, a continuous stream, or how results are returned (e.g., real-time updates, batch retrieval). It also omits details like rate limits, authentication needs, or whether it's read-only (likely, but not stated). For a tool with potential ongoing behavior, this is a significant gap.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action ('Watch for smart contract events') and specifies the context ('on Monad testnet'), making it easy to parse quickly. Every part of the sentence contributes essential 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 complexity of blockchain event monitoring (which often involves streaming or subscription behavior), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., event logs, real-time notifications), how to handle the watch operation (e.g., polling, WebSocket), or error conditions. For a tool with 4 parameters and potential behavioral nuances, this leaves critical gaps for an AI agent to use it effectively.
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% description coverage, with clear parameter definitions (e.g., 'Contract ABI', 'Contract address to watch'). The description adds no additional semantic context beyond what the schema provides, such as explaining ABI format requirements or eventName matching rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.
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 action ('Watch for') and resource ('smart contract events on Monad testnet'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'query-mon-nft' or 'get-block-by-number' which might also involve blockchain data retrieval, leaving room for ambiguity about when this specific event-watching capability is needed versus other querying methods.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a contract ABI), exclusions (e.g., not for historical data without 'fromBlock'), or comparisons to siblings like 'query-mon-nft' for NFT-specific queries. This lack of context makes it unclear when this tool is the appropriate choice.
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.
v1.0.0deploy-mon-contractget-block-by-numberget-latest-blockget-mon-balancequery-mon-nftsend-mon-transactionwatch-contract-eventsScored across 7 tools
Each tool has a clearly distinct purpose targeting specific blockchain operations on the Monad testnet. There is no overlap in functionality between tools like deploying contracts, querying blocks, checking balances, handling NFTs, sending transactions, and monitoring events.
All tool names follow a consistent verb-object pattern with hyphens (e.g., deploy-mon-contract, get-block-by-number). The naming is uniform across all seven tools, making them predictable and easy to understand.
With 7 tools, the server is well-scoped for blockchain interactions, covering essential operations like contract deployment, block queries, balance checks, NFT queries, transactions, and event monitoring. Each tool serves a clear and necessary function without redundancy.
The toolset provides comprehensive coverage for core blockchain operations on the Monad testnet, including deployment, queries, and transactions. A minor gap is the lack of tools for contract interaction (e.g., calling functions) or advanced querying (e.g., transaction history), but the existing tools support basic workflows effectively.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Tenderly MCP server for blockchain dev — simulate, debug, and test on 100+ networks.
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.
