Nodit の Web3 インフラストラクチャを通じて、AI エージェントと開発者を複数のネットワークにわたる構造化されたコンテキスト対応のブロックチェーン データに接続するモデル コンテキスト プロトコル (MCP) サーバー。
Nodit MCP Server は、AI モデルとアプリケーションがブロックチェーン エコシステムと対話する方法を簡素化します。
開発者は、複雑なノード RPC、生のイベント ログ、またはチェーン固有のデータ構造を処理する代わりに、AI の推論と意思決定に最適化された形式で、正規化されたマルチチェーン ブロックチェーン データにアクセスできます。
Nodit の MCP を使用すると、次のことが可能になります。
EVM 対応ネットワークと非 EVM ネットワーク全体でリアルタイムのブロックチェーン データを照会、分析、操作する AI エージェントを構築します。
専門的なブロックチェーン開発の専門知識を必要とせずに、Web3 統合アプリケーションを作成します。
統合アクセス レイヤーを通じて、Nodit の信頼性の高いノード インフラストラクチャ、Web3 データ API、GraphQL インデックス サービスを活用します。
サポートされているネットワークには、Ethereum、Base、Optimism、Arbitrum、Polygon、Aptos、Bitcoin、Dogecoin、TRON、XRPL などがあります。
Related MCP server: Contextum EVM MCP Server
Nodit MCP Serverは、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 Indexer API) 内で利用可能な操作を取得します。
API 仕様を取得する ( get_nodit_api_spec )
特定の API 操作の詳細情報 (パラメーター、要求/応答スキーマ) を取得します。
呼び出し API ( call_nodit_api 、 call_nodit_aptos_indexer_api )
OperationId と検証済みパラメータを使用して API 呼び出しを実行します。
Nodit MCPサーバーは、モデルコンテキストプロトコル（MCP）規約に従い、標準JSON-RPC over stdioプロトコルを使用して通信します。現在、サーバーとクライアント間の通信はstdioベースの通信のみをサポートしています。
以下は、AI エージェントおよび LLM 向けの Nodit MCP サーバーを通じて提供される主な機能とサポートされているブロックチェーン ネットワークです。
詳細な API 仕様と使用ガイドラインについては、 Nodit 開発者ドキュメントを参照してください。
RPC ノードとノード API
Nodit の専門的に運営されるインフラストラクチャを通じてブロックチェーン ノードのエンドポイントにアクセスします。
リアルタイムのネットワーク クエリ、トランザクションの送信、スマート コントラクトのやり取りなどをサポートします。
Web3データAPI
綿密にインデックスされたブロックチェーン データにアクセスするための高レベル API。
ブロックとトランザクションの詳細、トークンの転送履歴、アカウントレベルのトランザクションの概要、資産の移動の詳細などの処理済みデータセットが含まれます。これらの情報は、生の RPC 呼び出しを通じて直接収集することは困難です。
GraphQL インデクサー API (Aptos のみ)
GraphQL エンドポイントを通じて詳細な Aptos ブロックチェーン アクティビティをクエリします。
サポートされているネットワーク
EVM互換性: Ethereum、Arbitrum、Avalanche、Base、Kaia、Optimism、Polygon
非EVM: アプトス、ビットコイン、ドージコイン、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.jsNodit MCP サーバーがローカルで実行されると、 stdio 経由の JSON-RPCを使用して通信できるようになります。
基本的なリクエストをサーバーに送信する方法は次のとおりです。
例: 利用可能なツールの一覧
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 リクエストは失敗します。
迅速なセットアップのために、Claude CLI で Nodit MCP Server を直接使用することもできます。
次のコマンドで 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 を効果的に利用できるように、構造化されたコンテキストを提供します。
その責任には以下が含まれます。
Nodit API (Node API、Web3 Data API) を LLM で使用可能な形式で構造化します。
エンドポイントの詳細、入力/出力スキーマ、サンプル応答、およびエラー処理のガイドラインを公開します。
ただし、以下は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
