Skip to main content
Glama
Sign In

Realtap

by io.github.CSteenkamp
OverviewDiscussionsAdmin

What changed since a time

what_changed
Read-onlyIdempotent

Diff of the market since a time: tokens whose price moved by more than X %, tokens with a new first pool, new governance actions and large trades. Price moves cover at most the last 24 h (no older price snapshots), tokens below the liquidity floor are left out, and sections that could not be read are listed under unavailable. Also at /api/md/changes?since=.

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": {
      "since": "<since>"
    },
    "name": "what_changed"
  }
}

Input Schema

NameRequiredDescriptionDefault
sinceYesISO 8601 time (2026-10-21T08:00:00Z), a date, or an age such as 90m, 6h or 2d (at most 30 days back; the diff itself covers at most the last 7 days).
minTradeAdaNoSmallest trade in ADA to count as large (default 100,000; at least 1,000 is used).
minChangePctNoSmallest absolute price change in percent to list a token (default 10).
minLiquidityAdaNoLeave out tokens with less pool liquidity than this many ADA (default 10,000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Goes beyond the readOnly/idempotent annotations with real constraints: a 24-hour ceiling on price-move data (no older snapshots), a liquidity floor that silently drops tokens, and a partial-failure mode reported via `unavailable`. It omits anything about result caps or rate limits, but the disclosure of data-window and failure behavior is substantive.

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?

Two tight sentences, content first and caveats second, with no filler. The trailing '/api/md/changes?since=' endpoint note is mildly extraneous to tool invocation but is short and useful to API-oriented agents.

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?

With no output schema, the description does the necessary work by naming the sections returned and the `unavailable` bucket for partial failures. What's missing is the shape/magnitude of the result (per-section item counts, ordering, or truncation behavior) for what is clearly a multi-section aggregate response.

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% and each parameter is already described with type, default, and bounds, so the schema carries the burden. The description restates the filter concepts (X% price change, large trades, liquidity floor) without adding mapping, units, or edge-case behavior beyond what the schema states.

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+resource ('Diff of the market since a time') and enumerates exactly the four sections returned: price movers past a threshold, tokens with a new first pool, new governance actions, and large trades. This distinguishes it from single-focus siblings such as get_market_movers, list_governance_actions, and get_recent_trades.

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?

Gives clear operating context: price moves only span the last 24h, low-liquidity tokens are excluded, and unreadable sections surface under `unavailable`. It does not, however, say when to prefer this aggregate over the narrower siblings (get_market_movers, get_recent_trades), so the routing guidance stops slightly short.

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

All Realtap 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