Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Ltc Address Profile

ltc_address_profile
Read-only

Litecoin (ltc, LTC, mainnet) address PROFILE (lifetime summary): total received & sent (LTC), number of distinct senders/receivers, receiving/spending counts, first/last activity. Use to triage a LTC address during tracing — how much flowed and how connected. NOTE: an aggregate profile, not hop-by-hop edges — ltc_address_flow_summary returns the top counterparties, ltc_flow_edges and ltc_tx_flow the edges. Role from the ratio: Distinct_Senders ≫ Distinct_Receivers = consolidator; the reverse = distributor; thousands of both = mega-hub (exchange — don't trace deeper). Received_LTC / Sent_LTC are cumulative TURNOVER, not holdings: every output ever paid to the address (including the change it pays back to itself inside its own spending transactions) and every input it ever spent. The same coins are counted each time they pass through, so a busy exchange wallet's totals can exceed the coin's total supply many times over; Received_LTC minus Sent_LTC is the balance at this address. Litecoin totals come from a pre-aggregated table that holds a few duplicated and a few missing records. They match the transactions exactly on an ordinary address; on a busy one they can be off in either direction by up to a fraction of a percent (a Litecoin exchange address: 10 receiving outputs and 78 LTC too many, 0.14 %), so a negative balance, or a remainder on an emptied address, can be that artifact rather than real funds. For an exact figure on a single transaction use ltc_tx_flow. No address labels are returned here: identify addresses with labels_for_addresses(chain='litecoin'), which knows only a few hundred Litecoin addresses (exchange reserve wallets, sanctioned entities) — pass many addresses in ONE call; an empty answer there is a coverage gap, not a clean address. Amounts are in LTC; for a USD value use currency_price with currency_id "ltc".

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": {
      "address": "<address>"
    },
    "name": "ltc_address_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
formatNoShape of the returned data. "rows" (the default) returns one item per row. "columnar" returns a single item, {"columns":[...],"rows":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.rows
addressYesLitecoin address — L… or M… (34 characters, base58, case-sensitive) or ltc1… (bech32, any case). Give an old-style 3… P2SH address in its M… form; private MWEB (ltcmweb1…) addresses and the m-… / d-… script placeholders are rejected. An address of another chain does not have this form and is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
      +  "default": "rows",
      +  "description": "Shape of the returned data. \"rows\" (the default) returns one item per row. \"columnar\" returns a single item, {\"columns\":[...],\"rows\":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the read-only safety profile, yet the description adds substantive context: turnover vs. holdings semantics, self-change double counting, the pre-aggregated table's duplicated/missing records with a concrete error magnitude (0.14% on an exchange address), and the absence of labels. This is exactly the interpretive caveat an agent needs.

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?

Purpose is front-loaded in the first sentence, followed by sibling routing, then interpretation caveats. The data-quality paragraph is long but its warning about false negatives on balances is genuinely load-bearing; slight density cost.

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?

There is no output schema, and the description compensates by enumerating returned fields and explaining how to interpret them (turnover vs. balance, artifact-driven values). Safety is covered by annotations, so 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 coverage is 100%, so the schema fully documents 'address' (formats, rejections) and 'format'. The description adds nothing about parameters beyond the schema, so baseline 3 applies.

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 resource (Litecoin address lifetime profile) and enumerates the exact fields returned — total received/sent, distinct senders/receivers, counts, first/last activity. It explicitly distinguishes itself from ltc_address_flow_summary, ltc_flow_edges, and ltc_tx_flow.

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?

Gives an explicit use case (triage during tracing), names the non-use case (not hop-by-hop edges) and routes to the correct siblings for each alternative. It also tells the agent when to use ltc_tx_flow for exact per-transaction figures and labels_for_addresses for identification.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.