Read-only MCP server for querying OkkMax measurements of AI API relay services, including model availability, observed prices, 24-hour uptime, latency, and model- and group-level purity evidence. No sign-in or API key is required.
Scored across 6 tools
Each tool has a clearly distinct role: search_models finds model slugs, search_stations finds relays, get_station gives a single relay report, get_model_board compares relays for one model, find_cheapest_relay applies a specific price filter, and explain_methodology is purely informational. Descriptions explicitly cross-reference each other (e.g., 'to compare several relays use get_model_board'), eliminating the main price-tool overlap.
All names are snake_case and verb-first (explain_, find_, get_, search_), with predictable noun phrases that match the resource or action. No mixed conventions or vague verbs.
Six tools is well-scoped for a relay-station ranking and model-price comparison service: two search tools, two lookup/report tools, one filtered price tool, and one methodology explainer. Each earns its place without redundancy.
Core workflows are covered: discovering relays and models, getting detailed station reports, listing relays for a model with prices/uptime, finding the cheapest qualifying relay, and understanding the scoring methodology. Minor gaps exist, such as no explicit top-level leaderboard/ranking endpoint (though search_stations returns leaderboard order) and no historical or trend data.
Explain how OkkMax measures and scores relay stations: the rank score formula, the three purity tiers (pureblood, downgrade, counterfeit), how availability and speed are probed, detection cadence, how Sponsor ad placements relate to ranking, and the limits of the data. Returns markdown with a data timestamp. Call this before explaining a score to a user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful context beyond that: it returns markdown, includes a data timestamp, and explicitly documents 'the limits of the data,' which matters for downstream interpretation. It does not describe size or length of the output, but the disclosure of data limitations is real added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence lists the covered topics and closes with the actionable instruction to call it before explaining a score. The enumeration is dense but each item earns its place by telling the agent exactly what answers are available. Slightly long, but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only explanation tool with no output schema, the description supplies everything needed: what it covers, that it returns markdown plus a timestamp, and that it documents data limitations. An agent can decide to call it and know what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, which is the baseline-4 case per the rubric. The description correctly implies a parameterless invocation by never referencing any input, so nothing is missing or misleading here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Explain how OkkMax measures and scores relay stations') and then enumerates the exact contents covered: rank score formula, purity tiers, probing, cadence, Sponsor placements, and data limits. That level of specificity cleanly separates it from data-lookup siblings such as get_station or get_model_board.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit timing guidance: 'Call this before explaining a score to a user.' That establishes a clear precondition for use. It stops short of naming which sibling to call instead for related questions, but the read-only, zero-argument nature makes misuse unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the relay with the lowest observed input price for one model, under these conditions: CNY-priced relays whose 24h uptime is at least minUptime24hPercent (default 90; pass the user's number when they name an uptime requirement), excluding first-top-up, trial and free promotional groups. Returns that one relay with its slug, group, price per 1M input tokens, 24h uptime, the filter criteria, the data time (dataAsOf) and the only wording the result supports for a price claim. It is a single filtered candidate, not an overall ranking: to compare several relays use get_model_board, and check purity with get_station before recommending.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| minUptime24hPercent | No | Minimum 24h uptime in percent (0-100, default 90). Set it to the uptime the user asked for, for example 99. Groups whose uptime is below it or not measured are excluded. |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| model | Yes | |
| relay | No | |
| reason | No | |
| criteria | Yes | |
| dataAsOf | Yes | ISO 8601 time the underlying OkkMax data was last updated (not the time of this response). null when unavailable. |
| statement | No | The only wording this result supports for a price claim; it carries the filter, currency, unit and data time. |
| aliasNotice | No | |
| suggestions | No | |
| modelBoardUrl | Yes | |
| requestedModel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile needs no restating. The description adds real behavioral context beyond them: the exact exclusion set (first-top-up, trial, free promotional groups), the CNY pricing restriction, the fact that low or unmeasured uptime groups are dropped, and that results carry dataAsOf plus 'the only wording the result supports for a price claim' — a useful anti-overclaiming constraint. Missing are any notes on empty-result behavior or rate limits, which keeps it at a solid 3 rather than higher.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and the filter conditions, then a return-shape sentence, then sibling routing — a logical order with no filler sentences. It is dense to the point of being clause-heavy, packing filters, exclusions, return fields, and caveats into three long sentences, which costs a little readability but nothing is gratuitous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter read tool with a full input schema, full annotations, and an output schema, the definition covers everything an agent needs: filter semantics, the single-candidate limitation, downstream verification steps, and the evidentiary caveat about price wording. Return values are largely deferred to the output schema, which is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already well documented, establishing a baseline of 3. The description reinforces but does not extend the schema: its uptime guidance ('pass the user's number when they name an uptime requirement') and default-90 note are already present in the minUptime24hPercent schema text, and the model and locale parameters receive no added meaning in the description. Adequate but redundant rather than additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening states a precise verb, resource, and scope: 'Find the relay with the lowest observed input price for one model,' immediately qualified with the filtering conditions (CNY-priced, uptime floor, exclusion of first-top-up/trial/free promo groups). It also explicitly distinguishes itself from ranking siblings by noting it returns 'a single filtered candidate, not an overall ranking.' An agent can tell this apart from get_model_board without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names concrete when-to-use conditions ('pass the user's number when they name an uptime requirement') and explicitly routes to alternatives: get_model_board for comparing several relays, get_station for purity checks before recommending. Both the trigger and the exclusions are stated rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
OkkMax report for one relay station. Without model: the full report as markdown: rank and score breakdown, station-wide purity, per-channel availability and latency, groups and prices for every model, payment/refund terms and user review summary. With model (and optionally group): a compact JSON result for that one model only: the groups selling it with prices, each group's purity, and whether this model was directly probed in that group (selectedModelDirectlyVerified, actualModelSeen, detectedAt). Station-wide purity does not prove a specific model or group is genuine: when the user cares about one model, pass model. Promotions, invitation codes and invite links are not included. Use the slug from search_stations.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Station slug, e.g. from search_stations. | |
| group | No | Group name; only with model. Narrows the result to that one group. | |
| model | No | Model slug, e.g. claude-sonnet-5-5 (from search_models). Returns only this model's groups, prices and purity evidence as JSON. Omit for the full markdown report. | |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent safety profile, so the description is free to add the behavior that actually matters: the exact content of each mode, the important caveat that station-wide purity does not prove a specific model or group is genuine, and the explicit list of content that is omitted. That purity caveat is real decision-relevant behavior not derivable from any structured field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded and earns most of its length, leading with the two-mode split before detail. The single dense paragraph is heavier than ideal — the model-mode clause and the purity warning could be broken out — but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 full burden of describing return values and does so for both modes, including named fields (selectedModelDirectlyVerified, actualModelSeen, detectedAt) and the markdown report's sections. For a four-parameter read tool this is complete enough to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters including the locale enum are already documented in the schema itself. The description reinforces the model/group coupling and the consequence of passing model, but adds little syntactic or semantic detail the schema lacks — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource — an OkkMax report for one relay station — and immediately splits it into two distinct output modes (full markdown vs. compact per-model JSON). An agent can tell exactly what this returns and how it differs from search_stations or get_model_board without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit conditional guidance: pass model when the user cares about a specific model, group only in combination with model, and take the slug from search_stations. It also states exclusions (promotions, invitation codes, invite links). It stops short of routing the agent away from this tool toward siblings like get_model_board or find_cheapest_relay.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the AI models that relays resell (Claude, GPT/Codex, Gemini, and others) with OkkMax model pages. Returns the canonical slug to pass to get_model_board or find_cheapest_relay, how many monitored relays sell the model, and the official vendor price in USD per 1M tokens. Other spellings of the same version (for example claude-sonnet-4.6 for claude-sonnet-4-6) are listed in aliases, not as separate models; their relay counts are not merged.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (1-50, default 10). | |
| query | No | Free text, e.g. opus, gpt, gemini. Omit to list popular models first. | |
| 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 |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| models | Yes | |
| dataAsOf | Yes | ISO 8601 time the underlying OkkMax data was last updated (not the time of this response). null when unavailable. |
| suggestions | No | Present when nothing matched: what to try next. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, closed-world and non-destructive, so the safety profile is settled. The description adds genuinely new behavior: alias spellings are folded into an aliases field rather than returned as separate models, and their relay counts are not merged — a caveat that would otherwise cause an agent to misread the counts. It does not mention pagination or result ordering, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action and result payload, then the downstream-tool routing, then the alias caveat in a logical order. The opening phrase 'with OkkMax model pages' is slightly awkward and the last sentence is dense, but nothing is truly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and annotations cover safety, so the description need not explain return formatting or side effects. It supplies the missing interpretive context — canonical slug identity and unmerged alias counts — that an agent could not infer from structured fields alone. Only the absence of explicit sibling routing keeps it from being complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so limit, query and locale are already fully documented, including the enum values and defaults. The description contributes no additional parameter-level syntax or format guidance; its only adjacent detail, alias handling, is a result-modeling note rather than query semantics. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Search the AI models that relays resell') and names concrete examples (Claude, GPT/Codex, Gemini), which cleanly separates it from the sibling station-search tools. It also states what the result contains — canonical slug, relay count, vendor price — so an agent knows the shape of the answer before opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes the workflow position by saying the returned canonical slug is what you pass to get_model_board or find_cheapest_relay, which implies this is the entry point before those calls. It stops short of explicitly saying when to use this over search_stations, but the model-vs-station distinction is clear from the resource named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search relay services tracked by OkkMax by station name, slug, domain, URL, or model ID. Returns matching relays in leaderboard order with their current metrics. Use get_station for a full report.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (1-50, default 10). | |
| query | No | Free text: a relay name, slug, domain or URL, or a model ID such as claude-opus. Omit to list the top of the leaderboard. | |
| 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 |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| dataAsOf | Yes | ISO 8601 time the underlying OkkMax data was last updated (not the time of this response). null when unavailable. |
| stations | Yes | |
| suggestions | No | Present when nothing matched: what to try next. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the description needn't restate safety. It does add real value beyond them: results come back in leaderboard order, carry current metrics, and are a summary rather than a full report. It says nothing about matching semantics (exact vs fuzzy) or empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place: the first defines scope and inputs, the second routes to the sibling. Everything is front-loaded with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema descriptions, an output schema, and complete annotations, an agent has nearly everything it needs from structured fields, and the description supplies the ordering and the escalation path. The remaining gap is disambiguating this tool from search_models when a model ID is passed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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's list of searchable fields mirrors what the query parameter already documents, and it adds no meaning for locale or limit, so it does not exceed the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Search') plus resource ('relay services tracked by OkkMax') and enumerates the searchable fields (name, slug, domain, URL, model ID). It distinguishes itself from get_station, but leaves the overlap with the sibling search_models unresolved, since model ID is explicitly a valid query here too.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names one alternative ('Use get_station for a full report'), which is real routing guidance. However, it offers no guidance on when to prefer this over search_models or find_cheapest_relay, and the useful "omit query to list the leaderboard top" behavior lives only in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
explain_methodologyfind_cheapest_relayget_model_boardget_stationsearch_modelssearch_stations
Add one secure layer between your agents and this server.