Skip to main content
Glama
Sign In
Nodit MCP Server

Nodit MCP Server

Official
by noditlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Call Nodit API

call_nodit_api

Invoke Nodit Node or Data API operations for a chosen chain and network by operation ID and parameters, enabling retrieval of normalized blockchain data. Verify specs first; calls consume API quota.

Instructions

Calls an operation from the Nodit Node API or Nodit Data API categories — the operations listed by 'list_nodit_node_apis' and 'list_nodit_data_apis', whose target chain and network go in the URL. Nodit Webhook API operations cannot be invoked with this tool. Before making the call, it's recommended to verify the detailed API specifications using the 'get_nodit_api_spec' tool. API reference: https://developer.nodit.io/api/api-overview. Please note that using this tool will consume your API quota.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "chain": "<chain>",
      "network": "<network>",
      "operationId": "<operationId>"
    },
    "name": "call_nodit_api"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainYesNodit chain to call. e.g. 'ethereum' or 'polygon'.
networkYesNodit network to call. e.g. 'mainnet' or 'amoy'.
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.
operationIdYesNodit API operationId to call. Must include the chain prefix (e.g., 'ethereum-eth_blocknumber', 'polygon-eth_blocknumber', 'aptos-getAccount').
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.1
    • changedInput schema / properties / pathParams / description
      Previous value: -"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."New value: +"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."
    • changedInput schema / properties / queryParams / description
      Previous value: -"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."New value: +"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."
  2. Changed5 schema fields changedv1.2.0
    • 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"
+]
  3. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / requestBody / propertyNames
      Added value: +{
+  "type": "string"
+}
  4. Changed3 schema fields changedv1.0.0
    • 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"
+]
  5. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description adds genuinely new context beyond them: the call consumes API quota, chain and network are embedded in the request URL, and spec verification is advisable first. Error handling and rate-limit specifics are unstated, but the quota warning is the key non-obvious cost signal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the scope statement and the key exclusion in the first sentence, with procedural guidance and the quota warning following. It is tight overall, though the bare API reference URL contributes little beyond what the spec tool provides.

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?

For a six-parameter, nested-object, open-world invocation tool with no output schema, the description covers scope, discovery path, exclusion, and quota cost. It omits what a response looks like (error shapes, JSON-RPC vs REST differences) and defers entirely to get_nodit_api_spec, which is acceptable but leaves the agent dependent on a second call.

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% and the schema already explains pathParams, queryParams, requestBody routing, and the operationId chain-prefix rule. The description only adds that chain/network 'go in the URL', which is marginal beyond what the schema says. Baseline 3 applies since the schema does the heavy lifting.

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?

States a specific verb ('Calls an operation') and precisely bounds the resource: Nodit Node API or Nodit Data API categories, tied to the operations returned by list_nodit_node_apis and list_nodit_data_apis. It also explicitly excludes Webhook API operations, so an agent can distinguish this from webhook-related siblings without reading schemas.

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?

Gives a clear workflow: discover operations via the list_* tools, then verify details with get_nodit_api_spec before calling, plus an explicit exclusion for Webhook operations. It stops short of routing between the other invoke-style siblings (call_nodit_aptos_indexer_api, call_nodit_multichain_api), leaving the agent to infer which caller applies to which API category.

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

Deploy Server

Other Tools