Skip to main content
Glama
Sign In

Kellian

by app.kellian
OverviewDiscussionsAdmin

Verify a mined cancellation and report exact canonical finality

kellian_confirm_order_cancel
Destructive

Verify a mined OrderCancelledEvent. Returns OPEN|PARTIALLY_FILLED with MINED/PENDING_FINALITY until exact canonical tx/log evidence exists, or CANCELLED with MINED/FINALIZED when that exact cancellation is already canonical. Requires the same maker wallet proof used to prepare cancellation.

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": {
      "orderHash": "<orderHash>",
      "txHash": "<txHash>",
      "walletAddress": "<walletAddress>",
      "walletSignature": "<walletSignature>",
      "signatureTimestamp": "<signatureTimestamp>",
      "proofNonce": "<proofNonce>",
      "idempotencyKey": "<idempotencyKey>"
    },
    "name": "kellian_confirm_order_cancel"
  }
}

Input Schema

NameRequiredDescriptionDefault
txHashYesMined cancellation transaction hash
orderHashYesOrder hash whose cancellation was broadcast
proofNonceYesRequired single-use nonce for the wallet proof. Fetch from POST /api/auth/nonce; consumed on verification so the proof cannot be replayed.
walletAddressYesWallet address that owns the order
idempotencyKeyYesStable retry key. Reuse only with byte-equivalent tool arguments.
walletSignatureYesAction-bound wallet proof. Sign the canonical 'problee-mcp-auth:…' challenge (binds agent, apiKey, tool, scope, chain, resource, payloadHash, nonce, timestamp).
signatureTimestampYesUnix timestamp (seconds) used in the signed challenge message

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.4/5.0
Behavior3/5

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

The description adds real semantics beyond the annotations: a pending-finality outcome (OPEN|PARTIALLY_FILLED with MINED/PENDING_FINALITY) versus a settled one (CANCELLED with MINED/FINALIZED), which tells the agent to expect and retry on non-final states. However, it reads as a pure read — "Verify" / "Returns" — while the annotations declare readOnlyHint=false and destructiveHint=true; the actual reason (the single-use proofNonce is consumed on verification) appears only in the schema, so the description never reconciles the destructive classification. That reconciliation gap keeps it at a 3 despite the strong state disclosure.

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?

Three sentences, front-loaded with the action and the possible outcomes, then the auth prerequisite — no filler. The state notation (OPEN|PARTIALLY_FILLED with MINED/PENDING_FINALITY) is dense but each token carries distinct information an agent needs.

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

Completeness3/5

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

An output schema exists, so the description is not obligated to enumerate return shape, yet it does enough to explain finality semantics. What is missing for a tool this involved (7 required params, wallet proof, nonce) is the retry/idempotency picture — how a consumed nonce interacts with idempotencyKey on a retry — and any pointer to the sibling that actually broadcasts the cancel.

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%, so the schema already carries all seven parameters, including the nonce-consumption and idempotency-key details. The description's only added meaning is the requirement to reuse the same maker wallet proof and the fact that canonical tx/log evidence is what gets checked. That is marginal value over structured data, so baseline 3 is right.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Verify a mined OrderCancelledEvent" gives a specific verb (verify) and resource (a mined cancellation event), and the return-state sentence makes clear this reports finality rather than performing the cancel. It never names the siblings it is adjacent to (kellian_cancel_order, kellian_get_transaction_status, kellian_list_order_events), so the agent must infer the boundary rather than read it.

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?

Usage is implied rather than stated: the tool is called after a cancellation has been broadcast and mined. The one explicit condition is a prerequisite — "Requires the same maker wallet proof used to prepare cancellation" — which usefully tells the agent it must reuse the earlier proof material. There is no when-not guidance and no named alternative for cases where the agent actually wants to broadcast a cancel or check a generic transaction.

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

All Kellian toolsInspect
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