Skip to main content
Glama
Sign In

Kellian

by app.kellian
OverviewDiscussionsAdmin

Settle every on-chain claimable market — the protocol submits and pays the gas — defaults to on-chain-eligible only

kellian_sweep_claims

Settle every claimable market owned by the agent wallet. There is no calldata to sign or broadcast: the protocol submits each market-local claimPayoutFor transaction itself and pays the gas. Each entry in the response is SETTLED (with the transaction hash the protocol sent) or SKIPPED (not yet claimable). Pending finality is not claimable. Claim submission applies to onchain markets. Committed markets settle automatically at final resolution; GET /claims/receipts reports exact already-credited payouts. Explicit batch requests return SKIPPED/COMMITTED_SETTLED only after a corroborated payout receipt, with claimed:true and amountAvailable:true. Pending or unproven cases return SKIPPED/NOT_CLAIMABLE_YET, claimed:false and amountAvailable:false; their required amount of zero is an unavailable placeholder, not a credited zero result. No transaction is submitted for a committed market.

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": {
      "walletAddress": "<walletAddress>",
      "idempotencyKey": "<idempotencyKey>"
    },
    "name": "kellian_sweep_claims"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
cursorNo
proofNonceNoRequired single-use nonce for the wallet proof. Fetch from POST /api/auth/nonce; consumed on verification so the proof cannot be replayed.
walletAddressYesWallet that owns the payout claims
idempotencyKeyYesStable retry key. Reuse only with byte-equivalent tool arguments.
walletSignatureNoAction-bound wallet proof. Sign the canonical 'problee-mcp-auth:…' challenge (binds agent, apiKey, tool, scope, chain, resource, payloadHash, nonce, timestamp).
includeIneligibleNo
signatureTimestampNoUnix timestamp (seconds) used in the signed challenge message

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true; the description goes far beyond that by stating the protocol pays gas and submits on the agent's behalf, that no transaction is submitted for committed markets, and exactly how SETTLED vs SKIPPED outcomes and the claimed/amountAvailable flags behave. What it omits is the required action-bound wallet proof (proofNonce/walletSignature) — a significant precondition for a mutating tool that the schema documents but the description never mentions.

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

Conciseness3/5

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

The purpose is front-loaded in the first sentence and the second sentence adds genuinely useful mechanism detail. The later clauses, however, are dense, repetitive near-duplicates about SKIPPED/COMMITTED_SETTLED and NOT_CLAIMABLE_YET flag combinations, restating information an output schema already carries.

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 heavy explanation of SETTLED/SKIPPED flags is largely redundant, while the description omits the auth/proof prerequisite and any mention of pagination or batch size limits. For an 8-parameter mutating tool with a mid-coverage schema, it is adequate but leaves real gaps.

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

Parameters2/5

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

Schema coverage is only 63%, and the description explains no parameter at all — limit, cursor, includeIneligible, proofNonce, walletSignature and signatureTimestamp are left entirely to the schema. Notably, includeIneligible is only hinted at in the title ('defaults to on-chain-eligible only'), not in the description, and there is no explanation of batching or pagination behavior used by limit/cursor.

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?

The description names a specific verb and resource — 'Settle every claimable market owned by the agent wallet' — and clarifies the mechanism (protocol submits claimPayoutFor itself, no calldata to sign), which implicitly separates it from prepare_claims and simulate_claims. It stops short of naming any sibling explicitly, so the agent must infer the routing from the mechanism description.

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

Usage Guidelines4/5

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

It defines the selection conditions well: only on-chain markets are eligible for claim submission, committed markets settle automatically, and pending finality is not claimable. It never says 'use this instead of X' for the prepare/simulate/get_claim_status siblings, but the eligibility rules are concrete enough to guide invocation.

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