qmax

QSwap pools ranked by real fee income

qmax_list_pools

Read-onlyIdempotent

Every QSwap liquidity pool with its TVL, trailing swap volume, estimated fee APR (from real swap volume; only 0.192% of each swap's volume reaches liquidity providers), price change and impermanent loss over the window. A trailing estimate: past fees do not predict future fees, and volume that looks inflated (wash trading) is flagged in each pool's notes.

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_list_pools"
  }
}

Input Schema

Name	Required	Description	Default
`sort`	No	What to rank by: apr (fee yield), tvl (size of the pool) or volume	apr
`limit`	No	Most pools to return
`window`	No	The period fee yield is measured over	7d

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 24, 2026
- addedInput schema / properties / limit / description
```
Added value: +"Most pools to return"
```
- addedInput schema / properties / sort / description
```
Added value: +"What to rank by: apr (fee yield), tvl (size of the pool) or volume"
```
- addedInput schema / properties / window / description
```
Added value: +"The period fee yield is measured over"
```
First observedOct 17, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations only declare it read-only, idempotent and open-world; the description adds substantive domain behavior on top: the fee APR is a real-volume-derived estimate, only 0.192% of swap volume actually reaches LPs, and wash-trading-inflated pools are flagged per pool. It also warns the estimate is trailing and non-predictive — exactly the caveats an agent needs to interpret results responsibly.

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-loaded with the resource and metrics, followed by a caveat sentence that genuinely earns its place (fee derivation, wash-trading flags). The middle clause is a long run-on field list, but no sentence is filler.

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 takes on the burden of describing returns and does so by enumerating every metric. Combined with the fee-derivation explanation and data-quality caveat, an agent has everything needed to call and interpret this 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% and the enum descriptions already explain sort, limit and window, so the schema carries the load. The description adds mild meaning by tying APR to 'real swap volume' and metrics to 'over the window', but nothing about defaults, caps or the 7d/30d tradeoff. Baseline 3 is correct.

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 resource (every QSwap liquidity pool) and enumerates the metrics returned — TVL, trailing volume, fee APR, price change, impermanent loss. Clear enough that an agent knows this is a ranking/screening tool, but it never distinguishes itself from siblings like qmax_pool_detail or qmax_get_liquidity_pool, which could plausibly return overlapping data for a single pool.

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?

No explicit when-to-use, when-not, or named alternatives. Usage is only implied by the framing ('ranked by real fee income', sortable by apr/tvl/volume) — the agent must infer this is the screening tool versus the single-pool lookup siblings. Putting the ranking purpose up front earns a 3 but no more.

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

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