info_get_network_id
Get the numeric ID of the Avalanche network this node is participating in.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | The Avalanche network to query (default: mainnet) |
Avalanche AVAX MCP
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates a read operation ('Get') and specifies the scope ('this node is participating in'), which is helpful. However, it does not disclose return format, potential error conditions, or the effect of the optional network parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It contains no unnecessary words or repetition, earning a top score.
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?
For a simple tool with one optional parameter and no output schema, the description is sufficiently complete: it states what is returned (numeric ID) and the context (the node's network). It could mention the default network, but the schema already covers that parameter.
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%, and the only parameter (network) is fully documented in the schema with an enum and default. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
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?
The description clearly states the verb 'Get' and the resource 'numeric ID of the Avalanche network', which is specific and distinct from sibling tools like info_get_network_name (which gets the name) and info_get_blockchain_id (which gets a blockchain ID). This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (getting the network ID) but provides no explicit guidance on when to use this tool versus alternatives such as info_get_network_name or info_get_blockchain_id. There are no exclusions or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
B3.1/5.0
Disambiguation2/5
Many tools are redundant due to compatibility aliases (avalanche_docs_* vs docs_*, blockchain_get_* vs onchain_lookup) and overlapping functionality (chain_stats vs onchain_query, onchain_activity vs onchain_query ops, acp_list vs info_acps). Agents may struggle to select the correct tool when multiple appear to serve the same purpose, despite descriptions clarifying aliases.
Naming Consistency2/5
Naming patterns are inconsistent: some tools use noun_verb (acp_list, docs_fetch), some use verb_noun (build_plan), and others use prefixes like platform_get_, info_get_, and onchain_. The mix of styles (snake_case, noun phrases, verb phrases) makes it hard to predict tool names.
Tool Count2/5
With 48 tools, the count is high and inflated by compatibility aliases and granular platform_get_* wrappers. The scope spans multiple domains (docs, on-chain, platform API, ACPs, console), which could be better modularized. Many tools are trivial variants (e.g., platform_get_block vs platform_get_block_by_height) adding unnecessary bulk.
Completeness4/5
The server provides thorough read-only coverage for Avalanche: docs search, ACP management, on-chain lookups, indexed stats, platform API getters, and console flow guidance. While there is no transaction submission (likely intentional), the surface covers most queries a developer would need, with minor gaps like detailed token transfer history.