Skip to main content
Glama

Grandet

by io.github.hanzohanzhe
OverviewDiscussionsAdmin

Find a suitable low-cost model API / 寻找便宜且适用的模型 API

grandet_find_cheapest_api
Read-onlyIdempotent

Compare Grandet model prices within each unit. Read listings for price-only ordering and conditions; legacy recommended/alternative/cheapest retain their old meanings. Use view=compact for shared connection cards and a short text response. Provide exactly one model or name selector. host records the source only and never selects the inference route. Send targetApp when the user or conversation identifies the intended API application, including explicit use in the current app. With no target, compare directly. An unrecorded app connection permits a price-only recommendation, not a compatibility claim. Omit profile/protocol for a multi-protocol app unless already specified. Existing client remains a legacy target-app alias. Infer coding/chat/long_output from the task; presets are estimates. Use grandet_list_apps only when application facts are needed. Do not request API keys. view defaults to "compact"; pass view="full" for every field.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
osNoOperating system the target app runs on, for connection steps: windows, macos, linux or unknown.unknown
mixNoWorkload used to blend input, cache and output prices into one price per million total tokens. Presets "chat" (default), "coding" and "long_output", or custom input/cache-read/output/cache-write shares totalling 100.
asOfNoEvaluate as of this UTC time (ISO 8601, e.g. "2026-10-16T12:00:00Z"). Omit to evaluate now.
hostNoThe assistant or app making this call, e.g. "claude-code" or "codex". Attribution only; it does not change results.
langNoAnswer language: "en" or "zh-CN".en
nameNoThe catalogue's 20-character hexadecimal raw-name ID (not the name text). Send exactly one of model or name.
viewNo"compact" (default): a short text summary plus the listings, with connection cards shared in integrationCards; about a third of the size. "full": every legacy field, with the whole JSON repeated as text. "brief": a short text summary plus one structured body preserving required original fields; size varies with the requested limit and results and can exceed 12,000 characters.compact
limitNoRows per block, 1–20 (default 5).
modelNoModel to look up: a catalogue ID, an exact model name or a natural name such as "claude-sonnet-5-5". Send exactly one of model or name. An ambiguous name returns NEEDS_CLARIFICATION with candidates.
plansNo"best" (default) keeps one group per site; "all" lists every group of every site.
clientNoLegacy alias of targetApp. Prefer targetApp.
channelNo"standard" (default) lists ordinary channels, "declared-nonstandard" only channels the site itself labels nonstandard, "all" both.
currencyNoLimit to one unit board: USD_CREDIT or CNY_CREDIT (site credit, not cash), USD or CNY (cash). Never compare prices across units.
targetAppNoCatalogue ID of the app that will use the API, e.g. "openclaw", "claude-code" or "codex". Selects compatible protocols and connection steps. Send it only when the user says where the API will be used.
releaseSetNoPin a published data release by its release-set hash. Omit to use the current release.
skillBuildNoGrandet Skill build ID when called from the Skill. Omit otherwise.
endpointTypeNoLimit to one API protocol. Send it only when the user named a protocol.
skillVersionNoGrandet Skill version when called from the Skill, e.g. "0.3.0". Omit otherwise.
targetProfileNoAn inference profile ID of the target app (see grandet_list_apps). Only together with targetApp or client.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds real behavior beyond that: host is attribution-only and never selects the inference route, an unrecorded app connection permits a price-only recommendation but no compatibility claim, and presets are estimates. It does not describe pagination or result-size behavior beyond the brief view caveat.

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

Conciseness3/5

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

The content is dense and jumps between unrelated topics (ordering semantics, view modes, targetApp, host, matching, API keys) without clear front-loading, and some clauses ('legacy recommended/alternative/cheapest retain their old meanings') are opaque to a fresh reader. Few sentences are wasted, but structure is poor.

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?

For a 19-parameter tool with no output schema, the description covers identity/route selection, result shaping, and several defaults, while the schema fully documents the remaining fields. It falls short only on explaining the shape of returned listings beyond the view-mode trade-offs.

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, but the description adds semantics not in the schema: exactly one of model/name must be supplied, host never selects the route, targetApp should be omitted for a multi-protocol app unless specified, and view defaults to compact. These clarify selection intent rather than repeating field text.

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+resource — comparing Grandet model prices within a single unit of account and reading listings for ordering/conditions. It is clearly distinguishable from grandet_list_apps and grandet_resolve_model, though the title's 'cheapest' framing is not echoed as crisply in the body.

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?

Explicit conditions throughout: send targetApp only when the user names where the API will be used; use grandet_list_apps only when application facts are needed; do not request API keys; with no target, compare directly. It names the alternative sibling and the when-not cases.

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

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