The ExergyNet server provides tools for autonomous agents to interact with the ExergyNet thermodynamic compute clearinghouse on Base L2, enabling ZK-verified off-chain compute job management and on-chain financial operations:
Open a compute job (exergynet_open_job): Autonomously handle USDC approvals, on-chain escrow, and job registration without human intervention.
Verify program status (exergynet_verify_program): Check whether the LNES-01 protocol is live and active on Mainnet by providing an RPC URL.
Get Program ID (exergynet_get_program_id): Retrieve the Mainnet LNES-01 program ID.
Get Proof Transaction (exergynet_get_proof_transaction): Retrieve the proven SettleExergy transaction signature, confirming a ZK-verified settlement on-chain.
Estimate gate profitability (exergynet_estimate_gate): Calculate exergy-gate profitability by inputting external compute costs, settlement costs, and an optional risk margin to assess the economics of a compute job.
Provides read-only lookups for the ExergyNet LNES-03 program on Solana, including verifying the program account is executable, returning the program ID, and retrieving a reference settlement transaction signature.
Read-only MCP lookups for the ExergyNet LNES-03 program on Solana, plus a local compute-cost estimator. Part of ExergyNet, model-independent infrastructure for persistent memory, governed execution, and verifiable settlement — see exergynet.org.
A prior version of this package (versions up to and including 0.2.2) shipped a working exergynet_open_job tool that, once a user configured a real wallet, sent a real Base Mainnet transaction — including an unconditional, unlimited USDC spending approval — to a contract address that ExergyNet's own status page identifies as retired, with access control that cannot be independently verified. No evidence was found of any independent (non-developer) wallet ever having used this path. Full detail: MCP_SECURITY_ADVISORY_2026-08-28.md in the exergynet-site repository.
As of 0.2.3, exergynet_open_job is disabled. It always returns a fail-closed message and does not construct, sign, or submit any transaction under any configuration. This version has no signing dependency at all (ethers and viem have been removed) and does not read or require any private key. 0.2.4 additionally fixes input-validation and audit-logging gaps found by an independent MCP security scan — see below.
If you installed a version before 0.2.3 and configured a real BASE_PRIVATE_KEY, revoke any USDC approval you may have granted to 0x5cfE075149776f4b3cca07a27D4fd85A60BA5e3f on Base Mainnet (e.g. via revoke.cash) and upgrade immediately.
Related MCP server: cosmergon
An earlier build (0.1.10) was independently scanned by MCP Vouch against the OWASP MCP Top 10 and scored 71/100 (Grade C), with four warnings: input validation, audit/telemetry, rate limiting, and supply chain risk. 0.2.4 addresses all four in the current tool set:
Input validation: exergynet_estimate_gate and exergynet_verify_program now reject non-finite, negative, or malformed input with a clear error instead of silently coercing it.
Audit/telemetry: every tool call is logged to stderr with a timestamp and outcome.
Rate limiting: exergynet_verify_program (the only tool making an outbound network call) is limited to 20 calls per 10-second window.
Supply chain: ethers/viem were already removed in 0.2.3. npm audit fix was applied for the transitive ws vulnerability in 0.2.4. The remaining moderate-severity uuid advisory (reachable via @solana/web3.js → jayson → uuid@8.3.2) is resolved in 0.2.5 with a targeted overrides entry pinning jayson's uuid dependency to ^11.1.1, without downgrading @solana/web3.js itself. npm audit reports 0 vulnerabilities after this change. Verified safe, not just applied blindly: full rebuild, all 9 regression tests passing, and a live network call through exergynet_verify_program against Solana Mainnet-Beta confirmed the override doesn't change RPC behavior.
A fresh independent rescan will be requested once a version is published; results (old vs. new) will be recorded rather than the 71/100 figure being quietly dropped.
exergynet-mcp-server is the settlement-surface MCP server: read-only LNES-03 Solana program lookups plus a local compute-cost estimator. It is one interface into the broader ExergyNet fabric.
ExergyNet is model-independent infrastructure for autonomous AI systems — persistent memory, governed execution, and verifiable settlement. The three primary interfaces are:
Interface | Package | What it exposes |
Local persistent memory | BM25 search, SHA-256-addressed shard store, xLMP bounded recall (validated at mean K ≈ 896 tokens across a ~10M-token corpus) | |
Settlement surface (this package) |
| Read-only LNES-03 Solana lookups + compute cost estimator; write settlement ( |
Authority gate | LNES-22 (separate service) | Consequence authorization, delegation receipts, red-team-validated rejection logic |
If you want persistent local memory for your AI agent, install @lnes/vanguard-memory-node. If you want to query LNES-03 program state or estimate compute costs, install this package.
npx -y exergynet-mcp-serverclaude mcp add --transport stdio exergynet -- npx -y exergynet-mcp-server{
"mcpServers": {
"exergynet": {
"command": "npx",
"args": ["-y", "exergynet-mcp-server"]
}
}
}No private key or wallet credential is required or accepted by this server. RPC_URL is optional and defaults to the public Solana Mainnet-Beta endpoint.
Tool | What it does | Network call? | Can it move funds or sign anything? |
| Returns the LNES-03 Solana program ID | No — static value | No |
| Read-only check that the LNES-03 program account exists and is executable on Solana | Yes — one read-only RPC call (rate-limited: 20/10s) | No |
| Returns a reference LNES-03 settlement transaction signature | No — static value | No |
| Local arithmetic: compares an external compute cost against a settlement cost + risk margin | No — local arithmetic only | No |
| Disabled. Always returns a fail-closed message (security advisory 2026-08-28) | No | No — no signing capability in this version |
exergynet_open_job will remain disabled until a current Base L2 execution target is independently verified end-to-end — correct chain ID, correct contract identity, matching ABI, and a live settlement path (a real prover producing the ZK receipt that settleExergy requires) — and that verification is documented publicly. A version that re-enables it will state exactly which contract it targets and how a caller can independently confirm that before any transaction is possible. Until then: no ExergyNet MCP tool in this package will ever ask for a private key or send a transaction.
For current, verified Base L2 contract addresses and settlement status, see exergynet.org/proof.html.
ExergyNet is built to be discovered by AI agents, not humans browsing a docs page.
Well-known endpoint: https://exergynet.org/.well-known/exergynet.json — capabilities manifest
LLMs.txt: https://exergynet.org/llms.txt — protocol description in model-readable form
MCP server card: https://exergynet.org/.well-known/mcp/server-card.json
MCP Registry: io.github.ezumba/exergynet
AI can propose consequences. AI cannot authorize its own consequences.
The Consequence Boundary (LNES-22) is architecturally separate from this server. This package exposes read-only program lookups and a local cost estimator. When exergynet_open_job is re-enabled, it will operate within your explicitly granted spending authority only — the model layer never holds signing credentials for consequential actions.
See SECURITY.md for the x402 attack-class analysis and ExergyNet's architectural controls.
Claude (Claude Code, Claude Desktop)
ElizaOS
Any MCP-compatible agent runtime
npm: @lnes/vanguard-memory-node — companion local memory package
MCP Registry — io.github.ezumba/exergynet
MIT © ezumba
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.
Bounded agent exploration with persistent progress, deterministic receipts, and return contracts.
