Skip to main content
Glama
Sign In
Nodit MCP Server

Nodit MCP Server

Official
by noditlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Call Nodit Aptos Indexer API

call_nodit_aptos_indexer_api

Executes a GraphQL query against the Nodit Aptos Indexer API to retrieve normalized blockchain data. Verify API specifications before calling; each request consumes API quota.

Instructions

Calls a GraphQL query from the Nodit Aptos Indexer API category — the query roots listed by 'list_nodit_aptos_indexer_api_query_root'. 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. 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": {
      "network": "<network>",
      "requestBody": "<requestBody>"
    },
    "name": "call_nodit_aptos_indexer_api"
  }
}

Input Schema

NameRequiredDescriptionDefault
networkYesNodit network to call. Only 'mainnet' is supported.
requestBodyYesGraphql request body matching the API's spec.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.1
    • changedInput schema / properties / network / description
      Previous value: -"Nodit network to call. e.g. 'mainnet' or 'testnet'."New value: +"Nodit network to call. Only 'mainnet' is supported."
    • addedInput schema / properties / network / enum
      Added value: +[
+  "mainnet"
+]
  2. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / requestBody / propertyNames
      Added value: +{
+  "type": "string"
+}
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), so the description only needs to add what they don't say. It does add a real cost signal ('will consume your API quota') and notes the call returns the API response. It omits error semantics and the fact that a GraphQL requestBody can carry mutations despite the non-readOnly hint, which would be useful given the free-form body.

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?

The call is described first, the discovery/spec guidance second, and the quota warning last, so the important parts are front-loaded. All four sentences carry information, though the bare reference URL adds little for an agent and could be trimmed.

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?

There is no output schema, and 'Returns the API response' is a thin but acceptable answer given the response shape is defined by the per-query GraphQL spec the description points to. The free-form nested requestBody is the main complexity, and the description compensates by directing the agent to get_nodit_aptos_indexer_api_spec first. Quota consumption and network restriction are both surfaced.

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%, so both 'network' (enum mainnet) and 'requestBody' are documented in the schema itself. The description adds the framing that requestBody must match the API's spec, reinforcing the spec-lookup step, but supplies no syntax, shape, or field-level detail beyond that. Baseline 3 applies when the schema carries the weight.

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 gives a specific verb and resource ('Calls a GraphQL query from the Nodit Aptos Indexer API category') and anchors the category to the sibling that enumerates its query roots. That scope distinguishes it from call_nodit_api and call_nodit_multichain_api without naming them. It stops short of an explicit contrast statement, so a 4 rather than a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

It lays out a concrete prerequisite workflow: discover query roots with 'list_nodit_aptos_indexer_api_query_root', then verify specifications with 'get_nodit_aptos_indexer_api_spec' before calling. That is clear when-to-use ordering. It does not state any when-not conditions or failure/retry situations where another tool would be preferred.

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