OkkMax-mcp

Get relay leaderboard for a model

get_model_board

Read-onlyIdempotent

For one model, list the monitored relays that sell it, one row per relay using its highest-uptime group: input/output/cache price per 1M tokens in the relay's own currency (CNY or USD), 24h uptime and latency. Sorted by uptime, then price. Paged with limit and offset: total, returned, hasMore and nextOffset say whether the page is complete, and coversAllRelays is true only when it holds the whole board. This is not a price ranking and includes USD-priced relays and promotional groups; for the lowest price under an uptime condition use find_cheapest_relay.

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results (1-50, default 10).
`model`	Yes	Model slug as used on OkkMax, e.g. claude-opus-5-5 or gpt-6-astra. Dated aliases and other spellings of the same version (4.6 for 4-6) are accepted and resolved to the canonical slug. Use search_models to find slugs.
`locale`	No	Language of the human-readable text (statement, reason, notes, suggestions) and of the OkkMax page links. Pass zh when the user writes Chinese, otherwise en. Field names and data values are the same either way.	en
`offset`	No	Rows to skip, for paging. Use nextOffset from the previous response while hasMore is true.

Output Schema

Name	Required	Description
`url`	Yes
`note`	Yes
`model`	Yes
`title`	Yes
`total`	Yes
`offset`	Yes
`relays`	Yes
`hasMore`	Yes	true when more rows exist after this page. Request nextOffset to continue.
`dataAsOf`	Yes	ISO 8601 time the underlying OkkMax data was last updated (not the time of this response). null when unavailable.
`returned`	Yes
`nextOffset`	Yes
`aliasNotice`	No
`billingUnit`	Yes
`totalRelays`	Yes	Number of relays on the whole board (same as total).
`contextLength`	Yes
`requestedModel`	No	Present only when the requested slug was another spelling of the canonical model; model then holds the canonical slug.
`coversAllRelays`	Yes	true only when this response contains every relay on the board (offset 0 and hasMore false). Only then may the rows be treated as the full candidate set.
`officialPriceUsdPer1M`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: sort order ('uptime, then price'), currency handling per relay (CNY or USD), the highest-uptime-group selection rule, and the meaning of coversAllRelays. Paging completeness fields (total, returned, hasMore, nextOffset) are spelled out, which an agent needs to decide when to re-request.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with zero filler: purpose and row shape first, sorting and units next, paging semantics and the sibling redirect last. Every clause carries information an agent would otherwise have to infer.

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?

For a paged, read-only listing tool with an output schema, this covers the remaining gaps an agent needs: sort order, currency mixing, group-selection rule, page-completeness flags, and the alternative for price search. Nothing material is left unexplained.

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 baseline is 3. The description still adds meaning by framing limit/offset as paging and tying them to the response fields ('nextOffset say whether the page is complete'), and by noting prices are in the relay's own currency. It does not restate model/locale semantics, but the schema already covers those thoroughly.

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?

The description opens with a specific verb and resource ('For one model, list the monitored relays that sell it, one row per relay using its highest-uptime group') and pins down scope precisely. It also names the sibling it is not ('not a price ranking... use find_cheapest_relay'), so an agent can separate it from find_cheapest_relay without inspecting either schema.

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?

It states the use case (per-model relay board with price, uptime, latency), an explicit exclusion ('This is not a price ranking'), and the exact alternative for the excluded case ('for the lowest price under an uptime condition use find_cheapest_relay'). It even discloses that USD-priced relays and promotional groups are included, which prevents a common misuse.

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

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

Resources

Need Help?