mcp

address_latest__kaspa_address_latest

Query latest Kaspa address data. Cursor pagination: use 'nextStartingAfter' from response as 'startingAfter'.

Actions: • get-balance: Get address KAS balance • list-transactions: Get address transactions

Networks: mainnet (only)

Credits by action (source: OpenAPI): • get-balance: kaspa 918 • list-transactions: kaspa 918

Credits are indicative only and may change at any time. The actual credits spent for each API request are returned in the response headers.

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": {
      "action": "<action>",
      "network": "<network>",
      "address": "<address>"
    },
    "name": "address_latest__kaspa_address_latest"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Number of items to return (max 50)
`action`	Yes	Action to perform: get-balance, list-transactions
`address`	Yes	Kaspa address to query
`context`	No	Optional context for the request - echoed back in response
`network`	Yes	Network name: mainnet (only mainnet available)
`sortingOrder`	No	Sort order: ascending (oldest first) or descending (newest first)
`startingAfter`	No	Pagination cursor - use nextStartingAfter from previous response

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses pagination mechanics, the mainnet-only constraint, and per-action credit costs (918 kaspa each), which is real behavioral value. It stops short of stating read-only nature, auth/permission requirements, or rate limits.

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-loads purpose, then pagination, actions, networks, and credit costs in a scannable structure. The credits disclaimer is slightly verbose but bounded and clearly marked as indicative.

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

Completeness4/5

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

For a query tool with no output schema and no annotations, the description covers the critical operational facts: available actions, the only supported network, pagination, and cost. Return-value shape is only partially implied (nextStartingAfter), but the essentials for correct invocation are present.

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 schema already documents all parameters (baseline 3). The description adds cross-field semantics the schema cannot express: how to feed nextStartingAfter back into startingAfter for pagination, which is genuinely beyond the field-level descriptions.

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?

States a specific verb+resource ('Query latest Kaspa address data') and enumerates the two supported actions (get-balance, list-transactions), which clarifies scope. It is clearly a Kaspa-specific sibling to the evm/solana/xrp/utxo address_latest tools, though the differentiation rests mostly on the network name rather than an explicit statement.

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?

Gives actionable pagination guidance ('use nextStartingAfter from response as startingAfter') and lists the valid actions, so usage is implied. However, it offers no guidance on when to choose this tool versus address_history__* or transactions_data__transactions_data_kaspa, and no exclusions.

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

All mcp 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.