Skip to main content
Glama
Sign In

qmax

by io.github.profitphil
OverviewDiscussionsAdmin

Latest trades on QX and QSwap

qmax_get_tape
Read-onlyIdempotent

The most recent trades on both markets in one feed, newest first: time, market, asset, quantity, QU, price and direction. The direction is the TAKER's side (the person who started the trade): 'buy' or 'sell'. Rows also carry the transaction hash. The answer includes 'flow24h', the last 24 hours of buy versus sell volume, and 'latestId', the id to give as 'since' to get only newer trades. Served from memory, so cheap to poll.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "qmax_get_tape"
  }
}

Input Schema

NameRequiredDescriptionDefault
assetNoOnly this asset (leave out for all)
limitNoMost trades to return, newest first
sinceNoOnly trades newer than this id (the latestId from an earlier call)
venueNoOnly trades on this market (QX or QSwap); leave out for both

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / limit / description
      Added value: +"Most trades to return, newest first"
    • addedInput schema / properties / venue / description
      Added value: +"Only trades on this market (QX or QSwap); leave out for both"
  2. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the description correctly spends its words elsewhere: it discloses that data is served from memory (cheap to poll) and clarifies that 'direction' is the taker's side. That is genuine added context, but there is no disclosure of retention window, ordering guarantees beyond 'newest first', or what happens when 'since' is stale.

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 the scope and field list, then the taker-direction and flow24h/latestId semantics. Mostly dense and purposeful; the transaction-hash sentence is marginal but not wasteful.

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, the description carries the return-shape burden and does so fully: row fields, the flow24h aggregate, and the latestId continuation token are all named. Combined with the polling guidance, an agent has everything needed to call and consume it correctly.

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 already documents every parameter, which sets the baseline at 3. The description reinforces the 'since'/'latestId' round-trip, but it adds little the schema doesn't already say about 'asset', 'venue', or 'limit'.

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 and resource ('most recent trades on both markets in one feed') and enumerates the returned fields, so the agent knows exactly what it gets. It implicitly distinguishes itself from single-market tools via 'both markets', but never names a sibling or states what makes it different from qmax_get_flow, whose 24h buy/sell volume it partially overlaps with.

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 operational context: 'Served from memory, so cheap to poll' and explains that 'latestId' should be fed back as 'since' for incremental polling. That is actionable when-to-use guidance, but there is no explicit when-not or pointer to an alternative for other trade views.

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

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