Skip to main content
Glama
deenesjakoruzh
noditlabs

Nodit MCP Server

Official
by noditlabs
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Nodit MCP Server

A Model Context Protocol (MCP) server that connects AI agents and developers to structured, context-ready blockchain data across multiple networks through Nodit's Web3 infrastructure.

License Node.js TypeScript

Overview

Nodit MCP Server simplifies how AI models and applications interact with blockchain ecosystems.
Instead of handling complex node RPCs, raw event logs, or chain-specific data structures, developers can access normalized, multi-chain blockchain data in a format optimized for AI reasoning and decision-making.

With Nodit's MCP, you can:

  • Build AI agents that query, analyze, and act on real-time blockchain data across EVM-compatible and non-EVM networks.

  • Develope Web3-integrated applications without requiring specialized blockchain development expertise.

  • Leverage Nodit's reliable node infrastructure, Web3 Data APIs, and GraphQL indexing services through a unified access layer.

  • Easily develop with blockchain MCP in both local and remote integration, depending on your workflow needs.

Supported networks include Ethereum, Base, Optimism, Arbitrum, Polygon, Aptos, Bitcoin, Dogecoin, TRON, XRPL, GIWA(Sepolia) and more.

Related MCP server: Contextum EVM MCP Server

Table of Contents

List of Tools

Nodit MCP Server provides tools enabling AI agents to dynamically discover, understand, and interact with Nodit's Web3 APIs and data infrastructure. The tools minimize token consumption and maintain a lightweight context by modularizing API interactions into distinct steps:

  • Tools for Listing API Categories Retrieve a list of high-level API categories available.

    • list_nodit_api_categories

  • Tools for Listing API Operations
    Fetch available operations within a selected category (Node APIs, Data APIs, Aptos Indexer APIs, Webhook APIs). - list_nodit_node_apis - list_nodit_data_apis - list_nodit_aptos_indexer_api_query_root - list_nodit_webhook_apis

  • Tools for Getting API Specification
    Obtain detailed information for a specific API operation (parameters, request/response schema). - get_nodit_api_spec - get_nodit_aptos_indexer_api_spec

  • Tools for Calling API
    Execute an API call using the operationId and validated parameters. - call_nodit_api - call_nodit_aptos_indexer_api

Nodit MCP Server communicates using the standard JSON-RPC over stdio protocol, following the Model Context Protocol (MCP) conventions. Currently, only stdio-based communication is supported for server-client interactions.

Features

The following are the key features and supported blockchain networks provided through Nodit MCP Server for AI agents and LLMs.
For detailed API specifications and usage guidelines, please refer to the Nodit Developer Documentation.

  • RPC Node & Node APIs
    Access blockchain node endpoints through Nodit's professionally operated infrastructure.
    Supports real-time network queries, transaction submissions, smart contract interactions, and more.

  • Web3 Data APIs
    High-level APIs for accessing meticulously indexed blockchain data.
    Includes processed datasets such as block and transaction details, token transfer histories, account-level transaction summaries, and asset movement details — information that would be difficult to assemble directly through raw RPC calls.

  • GraphQL Indexer APIs (Aptos only)
    Query detailed Aptos blockchain activities through GraphQL endpoints.

  • Supported Networks

    • EVM-Compatible: Ethereum, Arbitrum, Avalanche, Base, Chiliz, Kaia, Optimism, Polygon, BNB Chain, GIWA(Sepolia)

    • Non-EVM: Aptos, Bitcoin, Dogecoin, TRON, XRPL, Sui, Solana

Prerequisites

  • Node.js 18+

  • Nodit API Key (Sign up and get an API key at Nodit Console)

Running Local Nodit MCP Server

Using npx (Recommended)

npx @noditlabs/nodit-mcp-server@latest

Using local build

# 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

Before starting, set your Nodit API key:

export NODIT_API_KEY=your-api-key

Then start the server:

node build/index.js

Communicating with the Local Server

Once the Nodit MCP Server is running locally, you can communicate with it using JSON-RPC over stdio.
Here’s how you can send a basic request to the server:

Example: List available tools

You can directly input the JSON-RPC payload:

{"method":"tools/list","params":{},"jsonrpc":"2.0","id":1}

Or, you can pipe the request using the echo command:

echo '{"method":"tools/list","params":{},"jsonrpc":"2.0","id":1}' | node build/index.js

Example: Call a specific tool (list_nodit_api_categories)

echo '{"method":"tools/call","params":{"name":"list_nodit_api_categories","arguments":{}},"jsonrpc":"2.0","id":1}' | node build/index.js

Connecting to Cursor IDE or Claude Desktop

Add the following configuration to your .cursor/mcp.json or claude_desktop_config.json:

  • Cursor

    • MacOS: ~/.cursor/mcp.json

    • Windows: C:\Users\<Username>\.cursor\mcp.json

  • Claude Desktop

    • 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": "****"
      }
    }
  }
}

🔔 Important
Replace **** with your actual Nodit API key.
If the API key is not configured properly, API requests will fail due to authentication errors.

Connecting to Claude CLI

You can also use Nodit MCP Server directly with Claude CLI for a quick setup.

Add Nodit MCP Server with the following commands:

# 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
claude

Integrating Nodit Remote MCP Server

If you’re using an AI tool that supports Remote MCP integration, you can connect to Nodit’s Remote MCP Server without running a local MCP server. This allows you to use Nodit MCP features directly within your AI environment.

Endpoint

Use the following endpoint to connect to the Nodit Remote MCP Server. Make sure to replace INSERT_YOUR_API_KEY with your actual Nodit API Key.

https://mcp.nodit.io/sse?apiKey=INSERT_YOUR_API_KEY

Connecting to Claude (Web)

If you’re on the Claude Enterprise, Pro, or Max plan, you can integrate the Remote MCP Server.

  1. Go to Settings > Integrations, click the [Add custom integration] button.

  2. Click the [Add more] button to integrate the new Remote MCP.

  3. Insert the endpoint provided above to complete the setup.

Once the integration is complete, you’ll see that Nodit MCP has been added under the Search and Tools section on the Claude main screen.

Connecting to Cursor IDE

To connect Nodit MCP to Cursor IDE: 1. Open Preferences > Cursor Settings > MCP Tools. 2. Click [+ New MCP Server] to open the mcp.json configuration file.

You can also open and edit the mcp.json file directly at the following path:

  • MacOS: ~/.cursor/mcp.json

  • Windows: C:\Users\<Username>\.cursor\mcp.json

Add the following configuration to the mcpServers object. If you already have other MCP servers configured, separate each entry with a comma.

{
  "mcpServers": {
    "nodit": {
      "url": "https://mcp.nodit.io/sse?apiKey=INSERT_YOUR_API_KEY"
    }
  }
}

Once added, go back to MCP Tools in the Cursor interface and enable the nodit MCP by toggling it on. When the status shows “9 tools enabled” in green, the connection is complete.

Troubleshooting

Trouble running MCP via npx on Claude Desktop

If you are running the MCP server in combination with Claude Desktop or other tools that rely on a local Node.js installation, you may encounter issues due to:

  • Multiple versions of Node.js installed (e.g., via Homebrew and package installer)

  • Conflicting PATH environments

  • Claude Desktop not recognizing the correct Node.js runtime

Follow the steps below to verify that Node.js 18+ is properly installed and recognized on your system.

1. Check your currently active Node.js version

Run the following command in your terminal to check the version:

node --version

You should see a version number starting with v18 or higher (e.g., v18.19.0).

If not, you may need to install a compatible version or switch to it.

TIP

Claude Desktop may not use the same Node.js version as your terminal. If you have multiple installations (e.g., via Homebrew, nvm, or direct installer), it may default to an unexpected version. To list all common installation paths:

# Homebrew installation
ls /usr/local/bin/node
ls /opt/homebrew/bin/node

# nvm installations
ls ~/.nvm/versions/node/

# System installation
ls /usr/bin/node

2. Install or switch to Node.js 18+ if needed

If you don’t have a compatible version, install Node.js using one of the following methods:

  • Using Node.js official installer: Download from nodejs.org

  • Using Homebrew (macOS):

bashbrew install node@20

  • Using nvm (recommended for version management):

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
nvm install 20
nvm use 20
nvm alias default 20

3. Check which Node.js version Claude Desktop uses

Claude Desktop inherits the PATH from your system environment. In your terminal, run:

which node

This displays the path of the Node.js binary currently active in your terminal. This is the path that Claude is likely to use when launched from that terminal.

4. Force Claude Desktop to use the correct Node.js version

  • If you’re using nvm:

nvm use 18  # Set proper version 
nvm alias default 18

  • If you’re using Homebrew, ensure it’s prioritized in your PATH:

export PATH="/opt/homebrew/bin:$PATH"  # for Apple Silicon
# or
export PATH="/usr/local/bin:$PATH"     # for Intel Macs

We recommend sticking to a single installation method (e.g., either nvm or Homebrew) to avoid version conflicts.

5. Restart Claude Desktop

After making changes, restart Claude Desktop to ensure it picks up the correct environment variables and Node.js version.

Example Prompts with Nodit MCP

Once Nodit MCP is connected, you can use natural language to directly query blockchain data from multiple networks. The examples below illustrate just a few of the many possibilities — feel free to go beyond them and explore your own use cases.

📊 On-chain Activity Monitoring

Summarize the recent activity of 0xabc…def across Ethereum and Arbitrum. Include major transactions, token transfers, and NFT interactions over the past 7 days.
What fungible and non-fungible tokens does this wallet hold across Ethereum and Polygon? Include balances and token names.
Analyze the risk profile of wallet 0xabc… based on its recent on-chain behavior.

🧾 Smart Contract & Transaction Analysis

Analyze how users interacted with the contract at 0xcontract… on Ethereum over the last week.
Analyze the last 10 blocks on Arbitrum.

🧠 AI Agent Use Cases

Based on wallet 0xabc…’s holdings, recommend optimal DeFi strategies across Ethereum and Arbitrum.
Create a daily summary report for 0xdao… including token balances, inflow/outflow, and governance activity.

⚙️ Web3 DApp Development

Write TypeScript code using fetch to retrieve all ERC-20 transfers for 0xabc… from Ethereum using Nodit’s Node API.
Build a simple dashboard to visualize how assets have moved in recent XRPL transactions.
Build a dashboard that aggregates blockchain data across multiple chains using Nodit.

Scope & Limitations

Nodit MCP Server provides structured context to help LLM-based agents utilize Nodit's APIs effectively.
Its responsibilities include:

  • Structuring Nodit APIs (Node APIs, Web3 Data APIs) in an LLM-consumable format.

  • Exposing endpoint details, input/output schemas, sample responses, and error handling guidelines.

However, the following are outside the MCP's control:

  • API selection may vary depending on the LLM version (e.g., GPT-4, Claude 3), prompt engineering, or agent design.

  • Interpretation of API responses or errors depends on the consuming LLM's reasoning capabilities.

Nodit MCP Server focuses on delivering accurate and structured API context,
but does not guarantee the final reasoning outcomes or behavior of external LLMs.

License

This project is licensed under the Apache License 2.0.
Refer to the LICENSE file for full license terms.
Relevant legal notices are provided in the NOTICE file.

"Nodit" and the Nodit logo are trademarks of Lambda256.
Use of the name or logo without prior written permission is prohibited.

© Lambda256. All rights reserved.

Available Tools

9 tools
call_nodit_apiA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
chainYesNodit chain to call. e.g. 'ethereum' or 'polygon'.
networkYesNodit network to call. e.g. 'mainnet' or 'amoy'.
operationIdYesNodit API operationId to call. Must include the chain prefix (e.g., 'ethereum-eth_blocknumber', 'polygon-eth_blocknumber', 'aptos-getAccount').
pathParamsNoPath 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.
queryParamsNoQuery 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.
requestBodyNoJSON request body for POST/PUT endpoints (JSON-RPC, etc.). Not for path/query parameters — use pathParams/queryParams for those.

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It 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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

call_nodit_aptos_indexer_apiA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
networkYesNodit network to call. e.g. 'mainnet' or 'testnet'.
requestBodyYesGraphql request body matching the API's spec.

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It 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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

get_nodit_api_specA

Gets the fully resolved spec details for a Nodit Blockchain Context API operationId. Returns details as a JSON string.

ParametersJSON Schema
NameRequiredDescriptionDefault
operationIdYesThe 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.

TDQS

A3.6/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

get_nodit_aptos_indexer_api_specA

Returns the GraphQL specification for a specific query root in the Nodit Aptos Indexer API.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryRootYesThe name of the query root to get the specification for. Use list_nodit_aptos_indexer_api_query_root to see available query roots.

TDQS

A3.5/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

list_nodit_api_categoriesA

Lists available Nodit API categories from Nodit Blockchain Context. To use the Nodit API tool, you must first call this tool.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

list_nodit_aptos_indexer_api_query_rootA

Lists all query roots available in the Nodit Aptos Indexer GraphQL API.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

list_nodit_data_apisA

Lists available Nodit Data API operations.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

list_nodit_node_apisB

Lists available Nodit API operations.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives; the description 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.

list_nodit_webhook_apisA

Lists available Nodit Webhook API operations.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv1.2.0
    • Changedcall_nodit_api5 fields changed
      • changedInput schema / properties / operationId / description
        Previous 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')."
      • addedInput schema / properties / pathParams
        Added 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"
+}
      • addedInput schema / properties / queryParams
        Added 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"
+}
      • changedInput schema / properties / requestBody / description
        Previous 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."
      • changedInput schema / required
        Previous value: -[
-  "chain",
-  "network",
-  "operationId",
-  "requestBody"
-]New value: +[
+  "chain",
+  "network",
+  "operationId"
+]
    • Changedget_nodit_api_spec1 field changed
      • changedInput schema / properties / operationId / description
        Previous 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."
  2. 9 tool updates
    • Changedcall_nodit_api2 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / requestBody / propertyNames
        Added value: +{
+  "type": "string"
+}
    • Changedcall_nodit_aptos_indexer_api2 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / requestBody / propertyNames
        Added value: +{
+  "type": "string"
+}
    • Changedget_nodit_api_spec1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedget_nodit_aptos_indexer_api_spec1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedlist_nodit_api_categories1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
    • Changedlist_nodit_aptos_indexer_api_query_root1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
    • Changedlist_nodit_data_apis1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
    • Changedlist_nodit_node_apis1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
    • Changedlist_nodit_webhook_apis1 field changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
  3. 6 tool updatesv1.0.0
    • Changedcall_nodit_api3 fields changed
      • addedInput schema / properties / chain
        Added value: +{
+  "description": "Nodit chain to call. e.g. 'ethereum' or 'polygon'.",
+  "type": "string"
+}
      • removedInput schema / properties / protocol
        Removed value: -{
-  "description": "Nodit protocol to call. e.g. 'ethereum' or 'polygon'.",
-  "type": "string"
-}
      • changedInput schema / required
        Previous value: -[
-  "protocol",
-  "network",
-  "operationId",
-  "requestBody"
-]New value: +[
+  "chain",
+  "network",
+  "operationId",
+  "requestBody"
+]
    • Changedlist_nodit_api_categories1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedlist_nodit_aptos_indexer_api_query_root1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedlist_nodit_data_apis1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedlist_nodit_node_apis1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedlist_nodit_webhook_apis1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
  4. 9 tool updates
    • First observedcall_nodit_api
    • First observedcall_nodit_aptos_indexer_api
    • First observedget_nodit_api_spec
    • First observedget_nodit_aptos_indexer_api_spec
    • First observedlist_nodit_api_categories
    • First observedlist_nodit_aptos_indexer_api_query_root
    • First observedlist_nodit_data_apis
    • First observedlist_nodit_node_apis
    • First observedlist_nodit_webhook_apis
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each 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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Kirha MCP Gateway

    kirha-ai
    A
    license
    Not graded
    quality
    C
    maintenance
    A unified interface that provides AI agents with access to premium data sources and crypto market intelligence through a single authentication endpoint. It handles multi-API composition and planning to aggregate real-time blockchain analytics and financial data into conversational workflows.
    20
    3
    ISC

  • chain-data

    Baneado98
    A
    license
    A
    quality
    C
    maintenance
    Enables AI agents to fetch live multi-chain portfolio, token info, gas prices, and token prices across Ethereum, Base, Polygon, Arbitrum, and Optimism with a single call. No API key required.
    4
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/noditlabs/nodit-mcp-server'

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