ExergyNet 热力学计算清算所的官方模型上下文协议 (MCP) 服务器。
ExergyNet 在 Base L2 EVM 上运行 LNES-04 协议。此服务器允许自主智能体（Claude、ElizaOS）直接从区块链原生请求零知识验证的链下计算。
Related MCP server: cosmergon
npx -y exergynet-mcp-server
需要两个环境变量：
BASE_PRIVATE_KEY：您智能体的热钱包（必须持有 Base Sepolia/Mainnet USDC 以支付费用）。
RPC_URL：您的 Base EVM RPC 端点。
exergynet_open_job：自主处理 EVM USDC 授权，并在链上托管计算费用。
Calculate exergy-gate profitability.
| Name | Required | Description | Default |
|---|---|---|---|
| externalComputeCostUsd | Yes | ||
| settlementCostUsd | Yes | ||
| riskMarginUsd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It states only that a calculation occurs, but does not mention side effects, authorization needs, rate limits, or whether the tool is read-only. The single sentence provides minimal behavioral context.
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 extremely concise (one sentence), but this brevity comes at the cost of useful detail. While it front-loads the purpose, it omits critical information about parameters and output, making it minimally adequate.
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?
With three input parameters, no output schema, and no annotations, the description should provide more context about what the inputs represent and what the tool returns. The current description does not enable an agent to use the tool effectively without additional domain knowledge.
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 0%, meaning parameter names and types provide the only semantic clues. The description does not explain the meaning or role of 'externalComputeCostUsd', 'settlementCostUsd', or 'riskMarginUsd', leaving the agent to infer their purpose from names alone, which is insufficient.
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 action ('Calculate') and the subject ('exergy-gate profitability'), distinguishing it from sibling tools which retrieve or verify data. However, the domain term 'exergy-gate' is not explained, which may confuse agents unfamiliar with the 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?
No guidance is provided on when to use this tool versus alternatives like exergynet_get_program_id or exergynet_verify_program. There is no mention of prerequisites, contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Mainnet LNES-01 program ID.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Return the Mainnet LNES-01 program ID'. It does not disclose behavioral traits such as whether it requires authentication, has side effects, or returns format specifics. For a read operation, more transparency would be beneficial.
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?
Description is a single, front-loaded sentence. It is concise, though it could further clarify that no inputs are required.
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 zero parameters, no output schema, and a simple purpose, the description is mostly complete. It clearly states what is returned. However, it does not specify the data type of the program ID (e.g., string, number).
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?
Input schema has zero parameters with 100% coverage. Description adds nothing about parameters because none exist. Baseline of 4 is appropriate as it correctly indicates no arguments 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?
Description clearly states 'Return the Mainnet LNES-01 program ID', using a specific verb and resource. It distinguishes from siblings like exergynet_estimate_gate, exergynet_get_proof_transaction, and exergynet_verify_program, which handle different operations.
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?
Description does not explicitly state when or when not to use this tool. It implies usage when the program ID is needed, but lacks explicit context or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the proven SettleExergy transaction signature.
| 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 must fully disclose behavior. It only states the return value without indicating side effects, mutability, or authorization requirements. The read-only nature is implied but not explicit.
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 single sentence is front-loaded with the key action and resource, contains no unnecessary words, and is optimally 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 and no output schema, the description is adequate but minimal. It lacks context about the SettleExergy transaction and how this proof signature fits into the broader workflow, leaving some ambiguity for the agent.
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 schema coverage is 100% (trivially). The description correctly avoids adding param info, meeting the baseline for zero-parameter tools.
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 specific action (return) and resource (proven SettleExergy transaction signature), and implicitly distinguishes from siblings which handle estimation, program ID retrieval, and verification.
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 vs. siblings like exergynet_verify_program or exergynet_estimate_gate. The description lacks contextual information about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if LNES-01 is live on Mainnet.
| Name | Required | Description | Default |
|---|---|---|---|
| rpcUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as whether the tool queries a blockchain, if it is read-only, or any side effects. The term 'check' is vague.
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, which is concise, but lacks structured information. It is too brief to be fully effective.
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 tool has no output schema and the description does not explain the return value, what 'live' means, or how to interpret results. The description is inadequate for an agent to use the tool correctly.
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 description mentions 'Mainnet' but does not explain the purpose of the 'rpcUrl' parameter. With 0% schema description coverage, the description should compensate but fails to provide meaningful parameter guidance.
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 action (check) and the specific resource (LNES-01 on Mainnet), distinguishing it from sibling tools which have different purposes (estimate_gate, get_program_id, get_proof_transaction).
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, or any context about prerequisites or limitations. The description only states what it does without usage 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.
v0.1.10exergynet_estimate_gateexergynet_get_program_idexergynet_get_proof_transactionexergynet_verify_programScored across 4 tools
Each tool targets a distinct function: profitability estimation, program ID retrieval, proof transaction retrieval, and liveliness check. No overlap in purpose.
All tools follow a consistent 'exergynet_verb_noun' pattern (estimate_gate, get_program_id, get_proof_transaction, verify_program), with verbs and nouns clearly indicating the action.
Four tools is appropriate for this server's focused scope on ExergyNet gate profitability and program verification; not too few or too many.
Core operations (profitability, program ID, proof, and verification) are covered. A minor gap is the absence of a tool to actually trigger settlement, but the set is largely self-contained for its intended purpose.
Compute-is-carbon energy/carbon ledger for agent work with Landauer-limit validation.
Machine-native utility network: verified evidence services for autonomous agents.
Carbon-accounted agent compute: free footprints; certificates backed by real offset retirement.
Outcome-calibrated economic trust gate for autonomous agents.
