Trnch on Elysium

Report a sent swap

trnch_confirm

Idempotent

Optional, after sending a swap built by trnch_buy or trnch_sell on Elysium (chainId 99901): report its hash. Returns { ok, txHash, chainId, status: "pending", meaning }, an acknowledgement only: it does not send, cancel or change the transaction. Nothing is credited on the call. A scheduled pass (every 2 minutes) reads the transaction on Elysium: sent by the key's wallet, a swap Trnch built for it, and the Trnch fee paid to the Trnch fee recipient in that same transaction. Only then is its volume counted in the swap stats of Elysium; there are no points or rewards on this chain. A hash that does not prove all of this counts nothing. Calling it twice with the same hash changes nothing. 10 calls per minute per key; 20 hashes at most awaiting settlement per wallet (429). 409 if the wallet has no Trnch account (sign in once on the site). Requires an API key (created by wallet signature), sent as Authorization: Bearer .

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "txHash": "<txHash>"
    },
    "name": "trnch_confirm"
  }
}

Input Schema

Name	Required	Description	Default
`txHash`	Yes	Hash of the Elysium transaction you sent.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: it explains that the call itself does not send, cancel or change the transaction and credits nothing, that settlement happens in a 2-minute scheduled pass with three verification conditions, that a non-proving hash counts nothing, and that repeat calls are inert. It also discloses rate limits (10/min per key), queue limits (20 pending hashes → 429), the 409 no-account condition, and the API-key auth requirement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and the sibling dependency, and most clauses carry distinct information. There is mild redundancy in restating the no-side-effect point three ways ('acknowledgement only', 'does not send, cancel or change', 'nothing is credited on the call').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description gives the return shape ({ ok, txHash, chainId, status, meaning }), both error conditions, auth requirements, and the settlement semantics. An agent has everything needed to call it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the format of txHash is already documented, but the description adds real meaning: the hash must be of a transaction the key's wallet actually sent, that Trnch built, and that pays the Trnch fee in the same transaction, or it counts nothing. That is semantic value the schema cannot carry.

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?

States a specific verb and resource ('report its hash' for a swap sent by trnch_buy or trnch_sell on Elysium, chainId 99901) and scopes it as optional. It clearly separates this from the sibling tools that actually build swaps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it ('Optional, after sending a swap built by trnch_buy or trnch_sell') and names the prerequisites that select it. It also explains the consequence of not using it — volume is only counted in Elysium stats after the confirmation pass — so the agent knows the trade-off.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Trnch on Elysium tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?