Skip to main content
Glama
dinggi5

Kura

by dinggi5
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

History

get_history
Read-only

Retrieve recent transaction attempts with statuses like sent, blocked, or settled, sorted newest first. Use limit to cap how many are returned (default 20).

Instructions

Returns the active account's recent transaction attempts, newest first. status is one of sent, blocked, failed, signed (x402 signed, awaiting settlement), settled (x402 settled, settle_tx is the settlement tx), settle_failed, unknown (a signed transaction was submitted but the wallet couldn't confirm the chain received it — detail is its tx hash; it may have gone through, so never resend on the strength of this entry alone; the wallet app later rechecks it on-chain and turns it into sent or reverted), reverted (mined but reverted on-chain — no money moved, only gas), expired (an x402 signature that was never used before it expired — no money moved), or received (money that came in — to is the sender, detail the tx hash; both are empty for ETH a contract sent; found on-chain by the wallet app while it runs, back to 90 days). Use limit to cap how many come back (default 20).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many recent entries to return (default 20, max 200).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.1
    • removedInput schema / properties / limit / default
      Removed value: -null
    • removedInput schema / properties / limit / nullable
      Removed value: -true
  2. First observedv0.2.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description carries substantial extra behavior: per-status meaning, which statuses mean no money moved (reverted, expired), that 'unknown' may have gone through and the wallet rechecks it on-chain, that 'received' comes from an app-driven on-chain scan back to 90 days. This is exactly the context annotations cannot supply.

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?

The core purpose is front-loaded and every clause carries information — the status enumeration is necessary because there is no output schema. It loses a point because the status glossary is delivered as one very dense run-on sentence rather than a scannable list.

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?

With no output schema and only one optional parameter, the description fully covers what the agent needs: return ordering, default limit, and the complete semantics of every status value including financial and safety implications. Nothing material is missing.

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% for the single 'limit' parameter, so the schema already documents default 20 and max 200; the description only restates the default. Baseline 3 applies since the schema does the heavy lifting and the description adds no new parameter syntax.

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 — 'Returns the active account's recent transaction attempts, newest first' — including scope (active account) and ordering. The resource is unmistakably distinct from siblings like get_balances and get_wallet_status, so an agent can route without opening any schema.

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 by the resource and by the embedded warning 'never resend on the strength of this entry alone', which quietly steers the agent away from acting on 'unknown' entries via x402_resubmit. However, it never explicitly says when to call this versus alternatives, nor states prerequisites or exclusions.

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

Deploy Server

Other Tools