模型上下文协议 (MCP) 服务器通过 Nodit 的 Web3 基础设施将 AI 代理和开发人员连接到跨多个网络的结构化、上下文就绪的区块链数据。
Nodit MCP Server 简化了 AI 模型和应用程序与区块链生态系统的交互方式。
开发人员无需处理复杂的节点 RPC、原始事件日志或特定于链的数据结构，而是可以以针对 AI 推理和决策优化的格式访问规范化的多链区块链数据。
使用 Nodit 的 MCP，您可以：
构建 AI 代理，用于跨 EVM 兼容网络和非 EVM 网络查询、分析和处理实时区块链数据。
无需专门的区块链开发专业知识即可创建 Web3 集成应用程序。
通过统一访问层利用 Nodit 可靠的节点基础设施、Web3 数据 API 和 GraphQL 索引服务。
支持的网络包括以太坊、Base、Optimism、Arbitrum、Polygon、Aptos、比特币、狗狗币、TRON、XRPL 等。
Related MCP server: Contextum EVM MCP Server
Nodit MCP 服务器提供的工具使 AI 代理能够动态地发现、理解并与 Nodit 的 Web3 API 和数据基础架构进行交互。这些工具通过将 API 交互模块化为不同的步骤，最大限度地减少了令牌消耗并维护了轻量级的上下文：
列出 API 类别（ list_nodit_api_categories ）
检索可用的高级 API 类别列表。
列出 API 操作（ list_nodit_node_apis 、 list_nodit_data_apis 、 list_nodit_aptos_indexer_api_query_root ）
获取选定类别中的可用操作（节点 API、数据 API、Aptos 索引器 API）。
获取 API 规范（ get_nodit_api_spec ）
获取特定 API 操作的详细信息（参数、请求/响应模式）。
调用 API（ call_nodit_api ， call_nodit_aptos_indexer_api ）
使用 operationId 和验证的参数执行 API 调用。
Nodit MCP 服务器使用基于 stdio 协议的标准 JSON-RPC 进行通信，遵循模型上下文协议 (MCP) 规范。目前，服务器与客户端之间的交互仅支持基于 stdio 的通信。
以下是通过 Nodit MCP Server 为 AI 代理和 LLM 提供的主要功能和支持的区块链网络。
详细的API规范和使用指南请参考Nodit开发者文档。
RPC 节点和节点 API
通过 Nodit 专业运营的基础设施访问区块链节点端点。
支持实时网络查询、交易提交、智能合约交互等。
Web3 数据 API
用于访问精心索引的区块链数据的高级 API。
包括已处理的数据集，例如区块和交易详细信息、代币转移历史记录、账户级交易摘要和资产流动详细信息——这些信息很难通过原始 RPC 调用直接收集。
GraphQL 索引器 API（仅限 Aptos）
通过 GraphQL 端点查询详细的 Aptos 区块链活动。
支持的网络
EVM 兼容：Ethereum、Arbitrum、Avalanche、Base、Kaia、Optimism、Polygon
非 EVM：Aptos、比特币、狗狗币、TRON、XRPL
Node.js 18+
Nodit API 密钥（在Nodit 控制台注册并获取 API 密钥）
npx @noditlabs/nodit-mcp-server@latest# Clone the repository
git clone --recurse-submodules https://github.com/noditlabs/nodit-mcp-server.git
# Move into the project directory
cd nodit-mcp-server
# Install dependencies
npm install
# Build the project
npm run build开始之前，请设置您的 Nodit API 密钥：
export NODIT_API_KEY=your-api-key然后启动服务器：
node build/index.js一旦 Nodit MCP 服务器在本地运行，您就可以使用JSON-RPC 通过 stdio与其通信。
以下是向服务器发送基本请求的方法：
示例：列出可用的工具
您可以直接输入 JSON-RPC 有效负载：
{"method":"tools/list","params":{},"jsonrpc":"2.0","id":1}或者，您可以使用echo命令来传输请求：
echo '{"method":"tools/list","params":{},"jsonrpc":"2.0","id":1}' | node build/index.js示例：调用特定工具（list_nodit_api_categories）
echo '{"method":"tools/call","params":{"name":"list_nodit_api_categories","arguments":{}},"jsonrpc":"2.0","id":1}' | node build/index.js将以下配置添加到您的.cursor/mcp.json或claude_desktop_config.json ：
光标
MacOS： ~/.cursor/mcp.json
Windows： C:\Users\<Username>\.cursor\mcp.json
克劳德桌面
MacOS： ~/Library/Application Support/Claude/claude_desktop_config.json
Windows： C:\Users\<Username>\AppData\Roaming\Claude\claude_desktop_config.json
{
"mcpServers": {
"nodit": {
"command": "npx",
"args": ["@noditlabs/nodit-mcp-server@latest"],
"env": {
"NODIT_API_KEY": "****"
}
}
}
}🔔重要
将****替换为您的实际 Nodit API 密钥。
如果 API 密钥配置不正确，API 请求将因身份验证错误而失败。
您还可以直接使用 Nodit MCP Server 和 Claude CLI 进行快速设置。
使用以下命令添加 Nodit MCP 服务器：
# Add the Nodit MCP server
claude mcp add nodit-mcp-server npx @noditlabs/nodit-mcp-server
# Set API Key
export NODIT_API_KEY=your-api-key
# Start Claude with the Nodit MCP server enabled
claudeNodit MCP 服务器提供结构化上下文，帮助基于 LLM 的代理有效地利用 Nodit 的 API。
其职责包括：
以 LLM 可使用的格式构建 Nodit API（节点 API、Web3 数据 API）。
公开端点详细信息、输入/输出模式、示例响应和错误处理指南。
然而，以下情况不在 MCP 的控制范围内：
API 选择可能因 LLM 版本（例如 GPT-4、Claude 3）、提示工程或代理设计而异。
API 响应或错误的解释取决于使用 LLM 的推理能力。
Nodit MCP Server 专注于提供准确且结构化的 API 上下文，
但不保证外部 LLM 的最终推理结果或行为。
该项目采用Apache License 2.0许可。
请参阅 LICENSE 文件以了解完整的许可条款。
相关法律声明在NOTICE文件中提供。
“Nodit”和Nodit标志是Lambda256的商标。
未经事先书面许可，禁止使用该名称或徽标。
© Lambda256. 保留所有权利。
This function calls a specific Nodit Blockchain Context API using its operationId. Before making the call, it's recommended to verify the detailed API specifications using the 'get_nodit_api_spec' tool. Please note that using this tool will consume your API quota.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Nodit chain to call. e.g. 'ethereum' or 'polygon'. | |
| network | Yes | Nodit network to call. e.g. 'mainnet' or 'amoy'. | |
| operationId | Yes | Nodit API operationId to call. Must include the chain prefix (e.g., 'ethereum-eth_blocknumber', 'polygon-eth_blocknumber', 'aptos-getAccount'). | |
| pathParams | No | Path parameters that fill {placeholders} in the request URL (e.g. { address: '0x...' }). Map each 'path' parameter from get_nodit_api_spec to a key here. | |
| queryParams | No | Query string parameters appended to the request URL (e.g. { 'pagination.limit': 10 }). Map each 'query' parameter from get_nodit_api_spec to a key here. | |
| requestBody | No | JSON request body for POST/PUT endpoints (JSON-RPC, etc.). Not for path/query parameters — use pathParams/queryParams for those. |
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 discloses a key behavioral trait: API quota consumption. However, it does not mention potential side effects, rate limits, or whether the tool is read-only or modifies state. More detail would improve transparency.
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 two sentences: the first states the purpose clearly, the second adds a usage recommendation and warning. There is no fluff or redundancy. Every sentence earns its place.
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 (6 parameters, 3 required, nested objects) and the absence of an output schema, the description is minimal. It covers purpose, a prerequisite step, and quota consumption, but lacks information on return values, error handling, or behavior for different operation types. It is adequate but not complete.
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 coverage is 100% with detailed parameter descriptions. The description adds minimal extra meaning beyond the schema, such as the recommendation to use 'get_nodit_api_spec' and the quota warning. According to the rubric, baseline 3 is appropriate when schema coverage is 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 tool calls a Nodit Blockchain Context API using an operationId. The verb 'calls' and resource are specific. While it doesn't explicitly distinguish from sibling tools like 'call_nodit_aptos_indexer_api', the name and context provide adequate differentiation.
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 recommends verifying API specifications using 'get_nodit_api_spec' before calling, which is a clear usage guideline. It also warns that using the tool consumes API quota. However, it does not specify when not to use this tool or when alternatives like the Aptos indexer tool are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls a Nodit Aptos Indexer API. Returns the API response. Before making the call, it's recommended to verify the detailed API specifications using the 'get_nodit_aptos_indexer_api_spec' tool. Please note that using this tool will consume your API quota.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | Nodit network to call. e.g. 'mainnet' or 'testnet'. | |
| requestBody | Yes | Graphql request body matching the API's spec. |
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 discloses that the tool consumes API quota and returns the API response, but does not clarify whether it performs mutations, rate limits, or other behavioral traits. The recommendation to check specs adds some context but leaves significant 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 concise with three short sentences, each providing essential information. It is front-loaded with the core purpose and efficiently includes a prerequisite and a caveat without unnecessary detail.
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?
The description only states that the tool returns the API response, without specifying response format or error handling. However, it compensates by recommending the spec tool for details. Given the absence of an output schema and the generic nature of the tool, the description is adequate but not comprehensive.
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 both parameters described in the schema. The description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not enhance understanding.
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 calls a Nodit Aptos Indexer API and returns the response. It distinguishes itself from the generic call_nodit_api sibling by specifying 'Aptos Indexer API', making the purpose specific and unambiguous.
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 recommends verifying API specifications using get_nodit_aptos_indexer_api_spec before calling, providing a clear best practice. It also warns about API quota consumption. However, it does not explicitly contrast with alternatives like call_nodit_api or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the fully resolved spec details for a Nodit Blockchain Context API operationId. Returns details as a JSON string.
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes | The operationId to get the resolved specification for. Must include the chain prefix in `{chain}-{methodName}` format (e.g., 'ethereum-eth_blocknumber', 'aptos-getAccount', 'ethereum-createWebhook'). Method-name-only input (e.g., 'eth_blocknumber') is rejected with guidance on the available chains. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states it gets and returns JSON, omitting behavioral traits such as idempotency, side effects, authentication needs, or rate limits. For a read-only spec retrieval, more detail would be helpful.
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 concise, front-loaded sentences with no unnecessary information. Every word 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?
For a simple one-parameter tool with a well-described input schema, the description is largely complete. It states the purpose and return type. However, it could elaborate on what 'fully resolved spec details' means or how to use the output, but overall sufficient.
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% with a detailed explanation of the operationId parameter (format, examples, rejection). The tool description does not add parameter semantics beyond the schema, so 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?
Clearly states it gets the fully resolved spec details for a Nodit Blockchain Context API operationId. Distinguishes from siblings like call_nodit_api (which executes the API) and get_nodit_aptos_indexer_api_spec (specific to aptos indexer).
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 explicit guidance on when to use this tool versus alternatives. The parameter description hints at proper input format but does not explain use cases or exclusion criteria. Implied that it is for retrieving specification details before calling the API, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the GraphQL specification for a specific query root in the Nodit Aptos Indexer API.
| Name | Required | Description | Default |
|---|---|---|---|
| queryRoot | Yes | The name of the query root to get the specification for. Use list_nodit_aptos_indexer_api_query_root to see available query roots. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes the tool returning a specification but does not mention that it is read-only, any authentication requirements, or potential limitations. This omission leaves the agent uninformed about side effects or constraints.
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, concise sentence that immediately states the tool's purpose. No unnecessary words or 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?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description is minimally complete. It explains what the tool returns but does not describe the format of the output or any constraints. Additional context about the nature of 'specification' or potential errors would improve completeness.
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% (one parameter with a clear description). The tool description does not add further parameter details beyond what the schema already provides, which is adequate but not extra value. The hint to use list_nodit_aptos_indexer_api_query_root is already in the schema parameter 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 identifies the action ('Returns the GraphQL specification') and the resource (a specific query root in the Nodit Aptos Indexer API). It distinguishes from sibling tools like get_nodit_api_spec (general) and list_nodit_aptos_indexer_api_query_root (lists roots, not spec).
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 implies usage context by referencing list_nodit_aptos_indexer_api_query_root in the parameter description, suggesting a sequence of steps. However, it does not explicitly state when to use this tool versus alternatives like get_nodit_api_spec or call_nodit_aptos_indexer_api.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists available Nodit API categories from Nodit Blockchain Context. To use the Nodit API tool, you must first call this tool.
| 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 it lists categories and is a prerequisite, but does not mention return format, access requirements, or any side effects. Minimal but not contradictory.
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, front-loaded with the action, no wasted words. Every word earns its place.
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 simplicity (no parameters, no output schema), the description is reasonably complete. It states the purpose and the prerequisite role. Could be more explicit about the output, but not necessary.
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 no parameters, and the schema coverage is 100% (empty object). According to the guidelines, 0 parameters baseline is 4. The description adds nothing extra, which is fine.
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 lists available Nodit API categories. It distinguishes from sibling list tools by specifying 'categories' rather than APIs or data, and mentions the context 'Nodit Blockchain Context'.
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 instructs to call this tool before using the Nodit API tool, providing clear usage context. While it doesn't mention when not to use, the instruction is direct and sufficient for a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all query roots available in the Nodit Aptos Indexer GraphQL API.
| 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 implies a read-only operation by using 'lists', but does not explicitly state the tool is safe, non-destructive, or free of side effects. This minimal transparency meets basic expectations but lacks detail.
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 sentence of 11 words, perfectly front-loaded with the verb 'Lists'. Every word adds value, no 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?
Given the tool has no parameters, no output schema, and no nested objects, the description adequately conveys what the tool does and what it returns (query roots). It is complete enough for this simple scope.
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, so the input schema is fully covered. According to guidelines, baseline is 4 for no parameters. The description adds no parameter information, but none is needed.
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 lists all query roots for the Nodit Aptos Indexer GraphQL API. The verb 'list' and specific resource 'query roots' make the purpose unambiguous and distinguish it from sibling tools like list_nodit_api_categories.
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 on when to use this tool versus alternatives such as get_nodit_api_spec or list_nodit_node_apis. The description does not mention prerequisites, limitations, or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists available Nodit Data API operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not mention read-only nature, side effects, or any behavioral traits beyond the basic function.
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?
One sentence, exactly as long as needed—no redundant words or structural issues.
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?
No output schema; description does not specify return format or structure, which could be clarified for agent decision-making.
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?
Zero parameters, so baseline is 4. The description adds no parameter info, but none is needed.
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 lists available Nodit Data API operations, distinguishing it from siblings like list_nodit_node_apis or list_nodit_webhook_apis.
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 on when to use this tool versus alternatives (e.g., list_nodit_api_categories or get_nodit_api_spec). The agent needs to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists available Nodit API operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states a read-like action ('Lists') without detailing traits such as rate limits, pagination, or side effects. It is not misleading but provides minimal information.
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, concise sentence with no unnecessary words. It is appropriately front-loaded and efficient.
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 tool with no parameters and no output schema, the description adequately conveys the tool's purpose. However, it lacks detail about the return value format or any constraints, which would be 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 zero parameters, so the description adds no parameter information. The rubric specifies a baseline of 4 for 0 parameters, and the description does not detract from that.
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 lists available Nodit API operations, but it does not differentiate this tool from sibling list tools like list_nodit_data_apis or list_nodit_webhook_apis, which also list API operations of different scopes.
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 simply states its function without any context about prerequisites, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists available Nodit Webhook API operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only listing operation, but lacks details on authentication, rate limits, or other behavioral traits. With no annotations, the description carries the full burden and does not provide sufficient transparency.
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?
One clear sentence with no unnecessary words; perfectly concise for the tool's simplicity.
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 parameters, no output schema, and no annotations, the description is sufficient to understand the tool's basic function, though it could mention the output format for completeness.
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 no parameters, and the schema coverage is trivially 100%. The description does not add parameter meaning, but baseline per guidelines is 4 for zero 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 clearly states the tool lists available Nodit Webhook API operations, distinguishing it from sibling tools like list_nodit_data_apis or list_nodit_node_apis.
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 on when to use this tool versus alternatives such as call_nodit_api or get_nodit_api_spec. It does not specify prerequisites or context.
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.2.0call_nodit_api5 fields changedInput schema / properties / operationId / descriptionPrevious value: -"Nodit API operationId to call."New value: +"Nodit API operationId to call. Must include the chain prefix (e.g., 'ethereum-eth_blocknumber', 'polygon-eth_blocknumber', 'aptos-getAccount')."Input schema / properties / pathParamsAdded value: +{
+ "additionalProperties": {},
+ "description": "Path parameters that fill {placeholders} in the request URL (e.g. { address: '0x...' }). Map each 'path' parameter from get_nodit_api_spec to a key here.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Input schema / properties / queryParamsAdded value: +{
+ "additionalProperties": {},
+ "description": "Query string parameters appended to the request URL (e.g. { 'pagination.limit': 10 }). Map each 'query' parameter from get_nodit_api_spec to a key here.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Input schema / properties / requestBody / descriptionPrevious value: -"JSON request body matching the API's spec."New value: +"JSON request body for POST/PUT endpoints (JSON-RPC, etc.). Not for path/query parameters — use pathParams/queryParams for those."Input schema / requiredPrevious value: -[
- "chain",
- "network",
- "operationId",
- "requestBody"
-]New value: +[
+ "chain",
+ "network",
+ "operationId"
+]get_nodit_api_spec1 field changedInput schema / properties / operationId / descriptionPrevious value: -"The operationId to get the resolved specification for."New value: +"The operationId to get the resolved specification for. Must include the chain prefix in `{chain}-{methodName}` format (e.g., 'ethereum-eth_blocknumber', 'aptos-getAccount', 'ethereum-createWebhook'). Method-name-only input (e.g., 'eth_blocknumber') is rejected with guidance on the available chains."call_nodit_api2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / requestBody / propertyNamesAdded value: +{
+ "type": "string"
+}call_nodit_aptos_indexer_api2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / requestBody / propertyNamesAdded value: +{
+ "type": "string"
+}get_nodit_api_spec1 field changedInput schema / additionalPropertiesRemoved value: -falseget_nodit_aptos_indexer_api_spec1 field changedInput schema / additionalPropertiesRemoved value: -falselist_nodit_api_categories1 field changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"list_nodit_aptos_indexer_api_query_root1 field changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"list_nodit_data_apis1 field changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"list_nodit_node_apis1 field changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"list_nodit_webhook_apis1 field changedInput schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"v1.0.0call_nodit_api3 fields changedInput schema / properties / chainAdded value: +{
+ "description": "Nodit chain to call. e.g. 'ethereum' or 'polygon'.",
+ "type": "string"
+}Input schema / properties / protocolRemoved value: -{
- "description": "Nodit protocol to call. e.g. 'ethereum' or 'polygon'.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "protocol",
- "network",
- "operationId",
- "requestBody"
-]New value: +[
+ "chain",
+ "network",
+ "operationId",
+ "requestBody"
+]list_nodit_api_categories1 field changedInput schema / additionalPropertiesRemoved value: -falselist_nodit_aptos_indexer_api_query_root1 field changedInput schema / additionalPropertiesRemoved value: -falselist_nodit_data_apis1 field changedInput schema / additionalPropertiesRemoved value: -falselist_nodit_node_apis1 field changedInput schema / additionalPropertiesRemoved value: -falselist_nodit_webhook_apis1 field changedInput schema / additionalPropertiesRemoved value: -falsecall_nodit_apicall_nodit_aptos_indexer_apiget_nodit_api_specget_nodit_aptos_indexer_api_speclist_nodit_api_categorieslist_nodit_aptos_indexer_api_query_rootlist_nodit_data_apislist_nodit_node_apislist_nodit_webhook_apisEach tool has a clearly distinct purpose: two call tools target different APIs, two spec tools provide details for those APIs, and five listing tools enumerate different categories of API operations. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case, with verbs like call, get, and list, and nouns specifying the API type (e.g., nodit_api, nodit_aptos_indexer_api). No mixing of conventions.
With 9 tools, the set is well-scoped for a server that provides access to multiple Nodit APIs and their metadata. Each tool earns its place, covering both discovery and execution.
The tool surface covers the full workflow: listing available APIs, getting specifications, and making calls. There are no obvious gaps for the stated domain of interacting with Nodit blockchain APIs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Manage your blockchain infrastructure across 80+ chains with your agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/noditlabs/nodit-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
