Nodit의 Web3 인프라를 통해 여러 네트워크에서 구조화되고 상황에 맞는 블록체인 데이터에 AI 에이전트와 개발자를 연결하는 MCP(Model Context Protocol) 서버입니다.
Nodit MCP 서버는 AI 모델과 애플리케이션이 블록체인 생태계와 상호 작용하는 방식을 간소화합니다.
복잡한 노드 RPC, 원시 이벤트 로그 또는 체인별 데이터 구조를 처리하는 대신, 개발자는 AI 추론 및 의사 결정에 최적화된 형식으로 정규화된 다중 체인 블록체인 데이터에 액세스할 수 있습니다.
Nodit의 MCP를 사용하면 다음을 수행할 수 있습니다.
EVM 호환 네트워크와 비 EVM 네트워크에서 실시간 블록체인 데이터를 쿼리하고 분석하며 조치를 취하는 AI 에이전트를 구축합니다.
전문적인 블록체인 개발 전문 지식 없이도 Web3 통합 애플리케이션을 만들어 보세요.
통합 액세스 계층을 통해 Nodit의 안정적인 노드 인프라, Web3 데이터 API, GraphQL 인덱싱 서비스를 활용하세요.
지원되는 네트워크로는 Ethereum, Base, Optimism, Arbitrum, Polygon, Aptos, Bitcoin, Dogecoin, TRON, XRPL 등이 있습니다.
Related MCP server: Contextum EVM MCP Server
Nodit MCP 서버는 AI 에이전트가 Nodit의 Web3 API 및 데이터 인프라를 동적으로 검색, 이해 및 상호 작용할 수 있도록 하는 도구를 제공합니다. 이 도구는 API 상호 작용을 개별 단계로 모듈화하여 토큰 소비를 최소화하고 가벼운 컨텍스트를 유지합니다.
API 카테고리 목록( list_nodit_api_categories )
사용 가능한 상위 수준 API 카테고리 목록을 검색합니다.
API 작업 목록( list_nodit_node_apis , list_nodit_data_apis , list_nodit_aptos_indexer_api_query_root )
선택한 카테고리(노드 API, 데이터 API, Aptos 인덱서 API) 내에서 사용 가능한 작업을 가져옵니다.
API 사양 가져오기( get_nodit_api_spec )
특정 API 작업(매개변수, 요청/응답 스키마)에 대한 자세한 정보를 얻습니다.
API 호출( call_nodit_api , call_nodit_aptos_indexer_api )
operationId와 검증된 매개변수를 사용하여 API 호출을 실행합니다.
Nodit MCP 서버는 모델 컨텍스트 프로토콜(MCP) 규칙을 준수하며 stdio 프로토콜을 통한 표준 JSON-RPC를 사용하여 통신합니다. 현재 서버-클라이언트 상호작용에는 stdio 기반 통신만 지원됩니다.
다음은 AI 에이전트와 LLM을 위해 Nodit MCP 서버가 제공하는 주요 기능과 지원되는 블록체인 네트워크입니다.
자세한 API 사양과 사용 지침은 Nodit 개발자 문서 를 참조하세요.
RPC 노드 및 노드 API
Nodit의 전문적으로 운영되는 인프라를 통해 블록체인 노드 엔드포인트에 액세스하세요.
실시간 네트워크 쿼리, 거래 제출, 스마트 계약 상호작용 등을 지원합니다.
Web3 데이터 API
꼼꼼하게 색인된 블록체인 데이터에 액세스하기 위한 고수준 API입니다.
블록 및 거래 세부 정보, 토큰 전송 내역, 계정 수준 거래 요약, 자산 이동 세부 정보와 같은 처리된 데이터 세트가 포함됩니다. 이러한 정보는 원시 RPC 호출을 통해 직접 조립하기 어렵습니다.
GraphQL 인덱서 API(Aptos 전용)
GraphQL 엔드포인트를 통해 Aptos 블록체인 활동에 대한 자세한 내용을 쿼리합니다.
지원되는 네트워크
EVM 호환: Ethereum, Arbitrum, Avalanche, Base, Kaia, Optimism, Polygon
비EVM: Aptos, Bitcoin, Dogecoin, TRON, XRPL
노드.js 18+
Nodit API 키 ( Nodit 콘솔 에 가입하고 API 키를 받으세요)
지엑스피1
# 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시작하기 전에 Nodit API 키를 설정하세요.
export NODIT_API_KEY=your-api-key그런 다음 서버를 시작합니다.
node build/index.jsNodit MCP 서버가 로컬에서 실행되면 stdio를 통한 JSON-RPC를 사용하여 해당 서버와 통신할 수 있습니다.
서버에 기본적인 요청을 보내는 방법은 다음과 같습니다.
예: 사용 가능한 도구 나열
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": "****"
}
}
}
}🔔 중요
****실제 Nodit API 키로 바꾸세요.
API 키가 올바르게 구성되지 않으면 인증 오류로 인해 API 요청이 실패합니다.
빠른 설정을 위해 Claude CLI와 함께 Nodit MCP 서버를 직접 사용할 수도 있습니다.
다음 명령을 사용하여 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 서버는 LLM 기반 에이전트가 Nodit API를 효과적으로 활용할 수 있도록 구조화된 컨텍스트를 제공합니다.
책임 내용은 다음과 같습니다.
LLM에서 사용 가능한 형식으로 Nodit API(Node API, Web3 데이터 API)를 구조화합니다.
엔드포인트 세부 정보, 입출력 스키마, 샘플 응답 및 오류 처리 지침을 공개합니다.
그러나 다음은 MCP의 통제 밖에 있습니다.
API 선택은 LLM 버전(예: GPT-4, Claude 3), 프롬프트 엔지니어링 또는 에이전트 디자인에 따라 달라질 수 있습니다.
API 응답이나 오류에 대한 해석은 소비하는 LLM의 추론 능력에 따라 달라집니다.
Nodit MCP 서버는 정확하고 체계적인 API 컨텍스트 제공에 중점을 둡니다.
하지만 외부 LLM의 최종 추론 결과나 동작을 보장하지는 않습니다 .
이 프로젝트는 Apache License 2.0 에 따라 라이선스가 부여되었습니다.
전체 라이센스 조건은 LICENSE 파일을 참조하세요.
관련 법적 고지 사항은 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
