Сервер протокола контекста модели (MCP), который подключает агентов и разработчиков ИИ к структурированным, контекстно-готовым данным блокчейна в нескольких сетях через инфраструктуру Web3 Nodit.
Nodit MCP Server упрощает взаимодействие моделей и приложений ИИ с экосистемами блокчейнов.
Вместо обработки сложных RPC-вызовов узлов, необработанных журналов событий или структур данных, специфичных для цепочек, разработчики могут получить доступ к нормализованным данным многоцепочечного блокчейна в формате, оптимизированном для рассуждений и принятия решений ИИ.
С помощью MCP от Nodit вы можете:
Создавайте ИИ-агенты, которые запрашивают, анализируют и действуют на основе данных блокчейна в реальном времени в сетях, совместимых и несовместимых с EVM.
Создавайте приложения, интегрированные с Web3, без необходимости специальных знаний в области разработки блокчейнов.
Используйте надежную инфраструктуру узлов Nodit, API-интерфейсы Web3 Data и службы индексации GraphQL через унифицированный уровень доступа.
Поддерживаемые сети включают Ethereum, Base, Optimism, Arbitrum, Polygon, Aptos, Bitcoin, Dogecoin, TRON, XRPL и другие.
Related MCP server: Contextum EVM MCP Server
Nodit MCP Server предоставляет инструменты, позволяющие агентам ИИ динамически обнаруживать, понимать и взаимодействовать с API Nodit Web3 и инфраструктурой данных. Инструменты минимизируют потребление токенов и поддерживают легкий контекст, разделяя взаимодействия API на отдельные этапы:
Список категорий API ( list_nodit_api_categories )
Получить список доступных категорий API высокого уровня.
Список операций API ( list_nodit_node_apis , list_nodit_data_apis , list_nodit_aptos_indexer_api_query_root )
Извлечение доступных операций в выбранной категории (Node API, Data API, Aptos Indexer API).
Получить спецификацию API ( get_nodit_api_spec )
Получите подробную информацию о конкретной операции API (параметры, схема запроса/ответа).
API вызова ( call_nodit_api , call_nodit_aptos_indexer_api )
Выполнить вызов API, используя operationId и проверенные параметры.
Nodit MCP Server взаимодействует с использованием стандартного протокола JSON-RPC через stdio, следуя соглашениям Model Context Protocol (MCP). В настоящее время для взаимодействия сервера и клиента поддерживается только связь на основе stdio.
Ниже приведены основные функции и поддерживаемые сети блокчейнов, предоставляемые через сервер Nodit MCP для агентов ИИ и LLM.
Подробные спецификации API и рекомендации по использованию см. в документации для разработчиков Nodit .
Узел RPC и API узлов
Получите доступ к конечным точкам узлов блокчейна через профессионально управляемую инфраструктуру Nodit.
Поддерживает сетевые запросы в реальном времени, отправку транзакций, взаимодействие со смарт-контрактами и многое другое.
API данных Web3
Высокоуровневые API для доступа к тщательно проиндексированным данным блокчейна.
Включает обработанные наборы данных, такие как сведения о блоках и транзакциях, истории передачи токенов, сводки транзакций на уровне счетов и сведения о перемещении активов — информацию, которую было бы сложно собрать напрямую с помощью необработанных вызовов RPC.
API индексатора GraphQL (только Aptos)
Запросите подробную информацию о действиях блокчейна Aptos через конечные точки GraphQL.
Поддерживаемые сети
Совместимость с EVM: Ethereum, Arbitrum, Avalanche, Base, Kaia, Optimism, Polygon.
Не-EVM: Aptos, Bitcoin, Dogecoin, TRON, XRPL.
Node.js 18+
Ключ API Nodit (зарегистрируйтесь и получите ключ API в консоли Nodit )
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Перед началом установите ключ API Nodit:
export NODIT_API_KEY=your-api-keyЗатем запустите сервер:
node build/index.jsПосле того, как сервер Nodit MCP запущен локально, вы можете взаимодействовать с ним, используя JSON-RPC через stdio .
Вот как можно отправить базовый запрос на сервер:
Пример: список доступных инструментов
Вы можете напрямую ввести полезную нагрузку 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": "****"
}
}
}
}🔔 Важно
Замените****на ваш фактический ключ API Nodit.
Если ключ API настроен неправильно, запросы API будут отклонены из-за ошибок аутентификации.
Вы также можете использовать Nodit MCP Server напрямую с Claude CLI для быстрой настройки.
Добавьте сервер 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 Server предоставляет структурированный контекст, помогающий агентам на базе LLM эффективно использовать API Nodit.
В его обязанности входит:
Структурирование API Nodit (API Node, API данных Web3) в формате, пригодном для использования LLM.
Предоставление сведений о конечных точках, схем ввода/вывода, примеров ответов и рекомендаций по обработке ошибок.
Однако нижеследующие вопросы находятся вне контроля МКП :
Выбор API может различаться в зависимости от версии LLM (например, GPT-4, Claude 3), быстрой разработки или дизайна агента.
Интерпретация ответов или ошибок API зависит от возможностей логического мышления потребляющего LLM.
Nodit MCP Server фокусируется на предоставлении точного и структурированного контекста API,
но не гарантирует окончательные результаты рассуждений или поведение внешних LLM.
Данный проект лицензирован по лицензии Apache License 2.0 .
Полные условия лицензии см. в файле ЛИЦЕНЗИЯ.
Соответствующие юридические уведомления приведены в файле 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
