Loading ToolBench
MCP server providing access to Nodit Blockchain Context APIs for querying blockchain data, calling node APIs, and managing webhooks across multiple blockchain networks
Server has 9 tools with basic structure but significant quality gaps. All tools have descriptions (good), but most descriptions are generic and lack actionable context. Input schemas are present but minimal, most tools accept empty objects or generic 'object' types without field-level constraints. No output schemas documented. Error handling exists but provides minimal recovery guidance. Tool names follow verb_noun convention (list_, get_, call_) which is correct. However, parameter descriptions are sparse, and there's no guidance on when to call discovery tools vs. API tools. The server exposes API keys via environment variables (correct), but lacks permission gates, audit logging, and rate limiting. Overall: functional but below production baseline.
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.
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.
Gets the fully resolved spec details for a Nodit Blockchain Context API operationId. Returns details as a JSON string.
Returns the GraphQL specification for a specific query root in the Nodit Aptos Indexer API.
Lists available Nodit API categories from Nodit Blockchain Context. To use the Nodit API tool, you must first call this tool.
call_nodit_api and call_nodit_aptos_indexer_api accept generic 'requestBody' as z.record(z.any()) with no field-level schema validation. LLMs cannot infer required fields, types, or constraints. Agents will hallucinate invalid payloads.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., operationId from list_nodit_api_categories). Responses are unstructured text, forcing LLM parsing.
Discovery tools (list_*) lack pagination support. No limit, offset, or cursor parameters. Large API catalogs will blow context windows. No guidance on result limits.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
Lists all query roots available in the Nodit Aptos Indexer GraphQL API.
Lists available Nodit Data API operations.
Lists available Nodit API operations.
Lists available Nodit Webhook API operations.
Error responses return generic text (e.g., 'Failed to load or parse the Aptos Indexer API schema'). No recovery guidance, no actionable next steps, no error classification (retryable vs. fatal).
No permission gates, audit logging, or rate limiting. Destructive operations (call_nodit_api, call_nodit_aptos_indexer_api) can be invoked without authorization checks. No trace of who called what or when.