This connector is a duplicate. Use Hubris instead — same endpoint (https://api.hubris.pw/mcp), but with ownership verified, OAuth, all five tools inspected and a quality score.
OpenAI-compatible LLM gateway for Russia: 500+ models, ruble pricing, balance, chat.
Scored across 15 tools
Each tool targets a distinct capability: chat, decisions, embeddings, images, rerank, speech, transcription, video create/get, youtube. The only potentially overlapping trio (models_list, models_search, models_get_pricing) is explicitly differentiated in the descriptions by scope and purpose, and balance_get vs usage_get are clearly split (remaining vs spent).
Names follow a predictable snake_case noun_verb pattern (balance_get, chat_complete, video_create, video_get, embeddings_create). Minor deviations: 'rerank' is a bare verb and 'models_get_pricing' breaks the two-part pattern, but the set remains highly readable.
15 tools is well-scoped for an AI-model aggregator covering text, audio, image and video inference plus catalogue and billing. Every tool earns its place with no filler.
The surface covers the full inference lifecycle for each modality plus models, pricing, usage and balance, and video has a proper create/poll pair. Gaps are explicitly deferred to the HTTP API (streaming, voice output, image-to-video, large file transfer), so agents hit intentional limits rather than dead ends.
Current balance of the Hubris account the API key belongs to, in rubles.
Worth checking before a long or expensive run: requests are refused once the balance is spent. The balance can go slightly negative — one operation is allowed to overdraw it, and the next one is refused.
Two representations of the same number come back. Use balanceKopecks for arithmetic and comparisons — it is an exact integer string. Use balanceRub for display.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| balanceRub | Yes | Balance in rubles as a decimal string, e.g. "1240.55". Negative when the account is overdrawn. |
| balanceKopecks | Yes | The same balance in kopecks as an integer string. Use this one for arithmetic: it is exact, while the ruble string is for display. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent), the description adds behavioral context: requests are refused when balance is spent, and the account can go slightly negative. This goes beyond the annotation hints.
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 concise and well-structured, with two clear paragraphs. It avoids unnecessary details and delivers the essential information efficiently.
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?
The description explains the output representations (balanceKopecks for arithmetic, balanceRub for display) and the behavior regarding balance depletion, making it complete for a simple no-parameter tool.
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 has no parameters, and schema coverage is 100% (empty). The description does not add parameter-related information, but since there are none, the baseline of 3 is appropriate.
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 clearly states the tool retrieves the current account balance, using the verb 'get' and specifying the resource. It distinguishes itself from siblings by the explicit focus on balance, though not directly comparing to others.
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?
Provides explicit guidance on when to use the tool: 'Worth checking before a long or expensive run'. Also explains the behavior of balance going negative, which informs usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a chat completion on any model in the Hubris catalogue and get the answer back. Full parity with POST /v1/chat/completions — same request shape, same response shape, including tool calls, structured output and reasoning. Streaming is not available here: MCP tool calls are synchronous, and stream is ignored if you pass it.
This is how you reach a model you cannot reach otherwise — pick an id with models_search, then call it here. Useful for delegating a subtask to a cheaper or a stronger model than the one you are running on.
Chat models that draw (Gemini Image, GPT-5 Image) take modalities ["image","text"]; their pictures come back as image content next to the JSON. Voice answers of audio models need streaming and are available through the HTTP API only.
The call spends real money from the account balance: it is billed per token at the catalogue price, in rubles. balance_get shows what is left.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Best-effort determinism. Not every model honours it. | |
| stop | No | Up to four strings that cut the answer short. | |
| model | Yes | Model id from the catalogue, vendor included and matched exactly, e.g. "anthropic/claude-sonnet-5". Short names and names with a trailing date are rejected. Use models_search to find one. | |
| tools | No | Function-calling tools, OpenAI shape. Model must have the "tools" capability. | |
| messages | Yes | Conversation so far, oldest first. | |
| reasoning | No | Extended thinking on models with the "reasoning" capability: {effort:"low"|"medium"|"high"}, {max_tokens:N}, or {enabled:false} to turn it off. | |
| max_tokens | No | Cap on the length of the answer, in tokens. | |
| modalities | No | ["image","text"] on chat models that draw (Gemini Image, GPT-5 Image): the pictures come back as image content. | |
| web_search | No | Enables built-in web search on models whose capabilities include "web_search". | |
| temperature | No | Sampling temperature, 0–2. Some newer models reject it; leave it out unless you need it. | |
| tool_choice | No | "auto", "none", "required", or a specific function to force. | |
| response_format | No | {type:"json_object"} or {type:"json_schema", json_schema:{…}} to constrain the answer to JSON. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-idempotent, open-world behavior, but the description goes well beyond them: it discloses real per-token billing in rubles against the account balance, the synchronous/streaming limitation, capability gating per parameter family, that image models return image content alongside the JSON, and that audio output is HTTP-only. That is exactly the context annotations cannot carry.
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 purpose, then layered by concern: parity/limitations, routing, multimodal edge cases, and cost. Four short paragraphs for a 12-parameter tool, with no sentence that could be deleted without losing operative information.
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 high-complexity, no-output-schema tool, it covers what the response contains (answer plus image content), what streaming does not do, which parameters are capability-gated, and the financial side effect. Nothing an agent needs to call it correctly is missing.
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 the baseline is 3, and the description earns an extra point by explaining how modalities behaves on drawing models and by tying tools/web_search/reasoning parameters to model capability requirements. It does not add syntax detail for the remaining parameters (seed, stop, response_format), but those are already well documented in 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?
States a specific verb and resource ('Run a chat completion on any model in the Hubris catalogue and get the answer back') and immediately scopes it against the rest of the Hubris surface by invoking the POST /v1/chat/completions parity contract. An agent can distinguish it from embeddings_create, image_generate, or rerank 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?
Explicitly routes the agent: pick a model id with models_search, check the balance with balance_get, and use the HTTP API when streaming or audio output is required. It also names the alternative use case (delegating to a cheaper or stronger model) and states the negative case ('stream is ignored if you pass it').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a decision model (Jev, Clef, Mercury Decide and others) structured questions about some data and get probabilities instead of text. Same as POST /v1/decisions. Question types: "noul" — yes or no, answered as the probability of yes; "choice" — one option out of criteria; "score" — a level on the scale given in criteria. All questions are answered in one call.
Good for classification, routing and triage where you need a calibrated number rather than prose — and much cheaper than asking a chat model.
Spends money from the account balance: billed per input token only. usage.cost_rub is what this call cost.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model id from the catalogue, vendor included and matched exactly, e.g. "typesafe/jev-1.13". Find one with models_search and tool: "decisions_ask". | |
| state | Yes | The data the questions are about: a string, an object or an array. | |
| questions | Yes | Questions by key, e.g. {"urgent": {"type": "noul", "instructions": "Is this urgent?"}, "team": {"type": "choice", "instructions": "Which team?", "criteria": {"billing": "Payments", "tech": "Outages"}}}. "score" takes criteria as an array of level descriptions. Each key comes back in answers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuinely new operational detail the annotations cannot convey: it spends account balance, is billed per input token only, that usage.cost_rub reports the charge, and that all questions are answered in a single call. That billing transparency is exactly the extra context a paid, non-idempotent call needs.
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 purpose in the first sentence, then question-type semantics, then usage guidance, then cost. Four short paragraphs, each with a distinct job; no filler or repetition of the name/title. 'Same as POST /v1/decisions' is minor API-reference detail but plausibly useful to the caller.
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 return burden and does explain the cost field (usage.cost_rub) and that each question key comes back in answers. Combined with annotations covering safety and full schema coverage, an agent has enough to call it correctly. It could say more about failure modes or invalid model ids, which is why it is not a 5.
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 schema already documents model, state and questions. The description still adds meaning beyond it by defining each question type semantically — noul is 'yes or no, answered as the probability of yes' — which the schema only gestures at via an example. It adds nothing further for model or state, so it does not reach 5.
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?
States a specific verb (ask) and resource (a decision model, with named examples Jev/Clef/Mercury Decide) and immediately draws the defining contrast: 'get probabilities instead of text.' It distinguishes itself from the closest sibling, chat_complete, by output type rather than leaving the agent to infer.
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?
'Good for classification, routing and triage where you need a calibrated number rather than prose — and much cheaper than asking a chat model' gives clear when-to-use context and implicitly steers away from chat_complete. It stops short of an explicit 'use chat_complete instead for X' rule or any when-not-to-use exclusion, so it is strong but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn text into embedding vectors with any embedding model in the Hubris catalogue — for semantic search, RAG, deduplication and clustering. Same as POST /v1/embeddings, OpenAI shape: data[i].embedding is the vector for input[i].
Pass a list of strings to embed a batch in one call, which is faster and cheaper than one call per string. Vectors are long: 1536 numbers make about 30 KB of JSON, and the whole answer lands in your context. Embed only what you will actually store or compare, use dimensions where the model allows it, and send large batches through the HTTP API (POST /v1/embeddings).
Spends money from the account balance: billed per input token. usage.cost_rub is what this call cost.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Text to embed: one string, or a list of up to 16 strings embedded in one call. | |
| model | Yes | Model id from the catalogue, vendor included and matched exactly, e.g. "openai/text-embedding-3-small". Find one with models_search and tool: "embeddings_create". | |
| dimensions | No | Shorter vectors, only on models that support it (openai/text-embedding-3-*). Leave out otherwise. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false; the description adds genuinely new behavior: the call spends account balance billed per input token, usage.cost_rub reports the cost, and vectors are large (~1536 numbers, ~30 KB of JSON) landing in the agent's context. That cost and context-bloat warning is exactly the kind of disclosure annotations cannot carry.
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 tight paragraphs, front-loaded with what the tool does, then usage guidance, then cost/behavior. Every sentence carries distinct information — use cases, batching advice, size warning, billing — with no restatement of the name or schema.
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?
No output schema exists, and the description compensates by describing the return shape (OpenAI-style, data[i].embedding is the vector for input[i], usage.cost_rub for cost). For a three-parameter tool with full schema coverage, nothing an agent needs to call it correctly is missing.
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 the baseline is 3, but the description adds value beyond the schema: it explains why to pass a list (faster and cheaper than one call per string) and when to use `dimensions` (only where the model allows it). It does not add new syntax or formatting beyond what the schema states, so it stays just above baseline.
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?
States a concrete verb+resource (turn text into embedding vectors) and enumerates the workloads it serves — semantic search, RAG, deduplication, clustering — which cleanly separates it from siblings like chat_complete, rerank, and image_generate. It also pins the resource to an OpenAI-compatible shape, so an agent knows exactly what category of operation this is.
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?
Gives clear when-to-use context (embed what you will actually store or compare) and routes the agent away from this tool for large batches: 'send large batches through the HTTP API (POST /v1/embeddings)'. It also advises batch-in-one-call over per-string calls. There is no explicit when-not beyond the large-batch case, but the routing guidance is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw an image from a text description with an image model from the Hubris catalogue (FLUX, Recraft, Seedream, GPT Image and others) and get the picture back right away as image content. Same as POST /v1/images/generations.
Only models whose tool is "image_generate" work here. Models that draw inside a chat answer and also write text (Gemini Image, GPT-5 Image) have tool "chat_complete" and run there. Sizes such as 4K can be heavier than your client accepts in one answer — ask for 2K or less here.
Spends money from the account balance: most image models are billed per image, some per megapixel or per token — models_get_pricing shows the price before you call. The charge shows up in usage_get.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | How many images to draw, 1 or 2. Each one is billed. Defaults to 1. | |
| size | No | Image size such as "1024x1024", or a tier such as "2K" on models that use tiers. Leave out for the model default. | |
| model | Yes | Image model id, vendor included and matched exactly, e.g. "black-forest-labs/flux.2-pro". Find one with models_search and tool: "image_generate". | |
| prompt | Yes | What to draw. Be specific about subject, style and composition. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic write/open-world/non-idempotent profile; the description goes well beyond them by disclosing that the call spends account balance, that billing varies per image/megapixel/token, where the charge surfaces (usage_get), and that the image is returned synchronously as content. No contradiction with readOnlyHint=false or destructiveHint=false.
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 purpose and return behavior, then model eligibility and the size limit, then cost. Three short paragraphs, each carrying non-redundant information, though the billing sentence is somewhat dense and could be trimmed without loss.
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?
No output schema exists, but the description states what comes back (image content immediately), covers cost implications, model eligibility, and size caveats — everything an agent needs to invoke this correctly. Nothing material is left to inference.
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 adds real meaning on top by explaining the size tiers ("4K can be heavier than your client accepts" → prefer 2K) and by constraining the model parameter to ids whose tool is "image_generate". The n multiplier's per-image billing is also flagged, though the schema already covers it.
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 sentence names a specific verb (draw/generate), the resource (image), the return form (image content), and the underlying API endpoint, and it enumerates the model families involved. It clearly separates itself from chat_complete by explaining that chat models with tool "chat_complete" do not belong here.
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?
Explicitly states the selection rule (only models whose tool is "image_generate") and names the alternative path for chat-style image models. It also adds a practical guardrail (ask for 2K or less because 4K answers may exceed what the client accepts) and routes the agent to models_get_pricing before spending, which is a genuine when-to-use precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full price of one model in rubles — the authoritative answer to "what does this cost".
Prefer this over the pricing embedded in models_list and models_search whenever the model is not billed per token. Those two return "0.00" token rates for such models; only this tool returns perUnit, where the real price per image, per second or per thousand characters lives.
For speech models it also lists the voices speech_create accepts (supportedVoices), for video models the durations, resolutions and aspect ratios video_create accepts (video).
Errors with InvalidParams if the model id is unknown or the model is no longer active.
| Name | Required | Description | Default |
|---|---|---|---|
| modelId | Yes | Exact model id from the catalogue, vendor included, e.g. "openai/gpt-6-astra". |
| Name | Required | Description |
|---|---|---|
| unit | Yes | Billing unit. "token" — priced per token, the two Rub fields below are meaningful. "unit" — priced per image, per minute, per character and so on; token fields are "0.00" and the real price is in models_get_pricing → perUnit. "unknown" — no pricing on record. |
| video | No | Video models only: the values video_create accepts for this model. |
| isFree | Yes | True only for genuinely free models. Do not infer this from a zero price: models billed per image or per minute also report "0.00" token rates. |
| perUnit | No | Present only for models not billed per token. This is where their real price lives. |
| currency | Yes | All prices are in rubles. |
| inputPer1MRub | Yes | Price of 1M input tokens in rubles, decimal string, e.g. "182.40". "0.00" when unit is not "token". |
| outputPer1MRub | Yes | Price of 1M output tokens in rubles, decimal string. "0.00" when unit is not "token". |
| supportedVoices | No | Speech models only: voice names to pass as `voice` to speech_create. Absent when the model has no list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral content beyond them: the error contract (InvalidParams for unknown or inactive models) and the fact that this tool uniquely returns `perUnit`, `supportedVoices`, and `video`.
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 answer and then the routing rule, with no filler sentences. The opening phrase about being the 'authoritative answer to what does this cost' is slightly rhetorical but still does work toward intent.
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, so return values need not be enumerated, yet the description usefully flags where the meaningful fields live. Error behavior is stated, and the cross-tool relationships (speech_create, video_create) are made explicit. Nothing needed to call it correctly is missing.
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% and the single `modelId` parameter is already documented as an exact catalogue id with a vendor prefix. The description adds no format, casing, or fallback guidance beyond what the schema states, so the 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?
States a specific verb ('Get') and resource ('model pricing') and pins the scope: the full price of one model in rubles. It explicitly distinguishes itself from sibling pricing paths (models_list, models_search), so an agent can route without opening a 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?
Gives an explicit preference rule: use this over models_list/models_search whenever the model is not billed per token, with the concrete symptom ('0.00' token rates) that indicates the wrong tool. It also names the downstream consumers (speech_create, video_create) whose accepted inputs are surfaced here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Walk the whole Hubris catalogue page by page, ordered by model id. Returns every active model with its capabilities, context window and ruble price.
Use this when you need the complete catalogue — to cache it, to count models, or to scan for something no filter covers. When you are looking for a model that fits a task, use models_search instead: it filters by capability, price and context server-side and saves you a few hundred rows.
Paging: read nextCursor from the response and pass it back as cursor. When nextCursor is absent you have reached the end. The catalogue holds roughly 550 models, so a full walk is about 11 calls at the default page size.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Models per page, 1–200. Defaults to 50. | |
| cursor | No | The `nextCursor` value from the previous response. Omit for the first page. |
| Name | Required | Description |
|---|---|---|
| models | Yes | |
| nextCursor | No | Pass back as `cursor` to fetch the next page. Absent when the last page was returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, idempotent, non-destructive read, so the safety profile needs no restating. The description adds real operational context beyond that: catalogue size (~550 models), a rough cost of a full walk (~11 calls at default page size), and the loop contract for nextCursor. It stops short of describing rate limits or ordering stability guarantees, but the delta over annotations is genuine.
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 tight paragraphs in a clear order: what it does, when to use it versus the sibling, then the paging mechanics. Every sentence carries information and nothing is padded.
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 an output schema present, return values need not be re-explained. The description still covers the pieces an agent needs to drive the tool correctly: the alternative for filtered lookups, the cursor loop, and the expected number of calls for a full traversal.
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 both parameters are already documented, which sets the baseline at 3. The description adds meaning via the paging workflow — read nextCursor, pass it back as cursor, absence signals the end — which is more than a restatement of the schema field text.
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?
States a specific verb and resource ('walk the whole Hubris catalogue page by page') plus the ordering and the payload returned (capabilities, context window, price). It explicitly distinguishes itself from the sibling models_search, so an agent can route between them without opening a 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?
Gives explicit when-to-use cases (caching, counting, scanning for something no filter covers) and an explicit when-not with the named alternative ('use models_search instead: it filters by capability, price and context server-side'). The selection rule is fully determined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find models that fit a task. Filters by name, the tool that runs the model, capability, price ceiling and context window, and can sort the result. This is the tool to reach for when choosing a model — it does the filtering server-side and returns at most 50 rows.
All filters combine with AND, and every one of them is optional: calling with no arguments returns the first 50 active models.
Two things worth knowing about prices. maxInputPer1MRub keeps only models billed per token, because a ruble-per-million ceiling is meaningless for a model billed per image. The cheap_input and cheap_output sorts push non-token models to the end of the list for the same reason — their token rate reads as zero, which would otherwise put video models at the top of "cheapest".
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | cheap_input / cheap_output — ascending token price, models not billed per token go last. big_context — widest context window first. popular — most used on Hubris first. Unsorted when omitted. | |
| tool | No | Keep only models run by this tool: "chat_complete" for text, "embeddings_create", "rerank", "decisions_ask", "image_generate", "speech_create", "transcription_create" or "video_create". The way to find a model for any tool other than chat_complete. | |
| query | No | Case-insensitive substring matched against the model id and display name, e.g. "claude" or "gpt". | |
| capability | No | Keep only models with this capability. vision — reads images. image_gen — draws them. transcription — speech to text via /v1/audio/transcriptions. audio_in — accepts an audio recording in chat. audio_out — answers with speech. audio — legacy, matches either audio direction. tools — function calling. reasoning — extended thinking. web_search — built-in web search. decisions — yes/no, choice and scale answers with probabilities via /v1/decisions (no text output). rerank — orders documents by relevance to a query via /v1/rerank (no text output). | |
| minContext | No | Keep only models whose context window is at least this many tokens. | |
| maxInputPer1MRub | No | Ceiling on the price of 1M input tokens, in rubles. Also restricts the result to models billed per token, since the ceiling means nothing for models billed per image or minute. |
| Name | Required | Description |
|---|---|---|
| models | Yes | Matching models, at most 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds real behavior: server-side filtering, a hard 50-row cap, AND-combination of filters, and the deliberate treatment of non-token-billed models under price ceilings and cheap sorts. These are non-obvious quirks an agent would otherwise misread.
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 purpose, then defaults, then the price caveat; nearly every sentence carries information. The price paragraph partially duplicates the schema's own notes, which costs a little tightness.
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?
Covers filtering semantics, sort behavior, argument optionality, the no-arg default, and the result cap. An output schema exists, so return-shape detail is correctly left out; nothing an agent needs to call this correctly is missing.
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 earns above that by explaining why maxInputPer1MRub implicitly excludes per-image/per-minute models and why cheap_input/cheap_output reorder them, which the schema only asserts. It reinforces rather than redefines the schema's enum semantics.
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?
States a specific verb and resource ('Find models that fit a task') and enumerates exactly what can be filtered and sorted. It positions itself as the model-selection entry point, though it never names its closest sibling (models_list) to draw the boundary explicitly.
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?
Gives clear context ('the tool to reach for when choosing a model') and states that all filters are optional with a defined no-argument default (first 50 active models). It stops short of naming when to prefer models_list or models_get_pricing instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order documents by how well they answer a query, best first, with a relevance score each. Same as POST /v1/rerank. Typical use: a vector or keyword search finds 50–100 candidates, rerank picks the few that really answer the question, and only those go to the model — answers get more accurate and prompts shorter.
results[].index points into the documents list you sent. Scores are comparable only within one response.
Spends money from the account balance: Cohere models are billed per search (up to 100 documents), the rest per input token. usage.cost_rub is what this call cost.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model id from the catalogue, vendor included and matched exactly, e.g. "cohere/rerank-v3.5". Find one with models_search and tool: "rerank". | |
| query | Yes | The question or search query to rank the documents against. | |
| top_n | No | Return only this many best documents. Leave out to get all of them, ranked. | |
| documents | Yes | Candidate documents as plain text, 1 to 1000 of them. Their order in the answer is by relevance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: this call spends account balance ('Cohere models are billed per search (up to 100 documents), the rest per input token'), reports usage.cost_rub, and warns that scores are only comparable within a single response. That billing and score-comparability context is exactly what the readOnlyHint=false / openWorldHint=true annotations cannot convey.
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 short, front-loaded paragraphs: what it does, how it is typically used, then result and cost caveats. Every line carries load and nothing is padded.
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 compensates by explaining the return shape (index into the input documents list, a score per document, best-first ordering, cross-response score comparability). Together with the cost disclosure, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema, which sets the baseline at 3. The description clarifies result-pointer semantics ('results[].index points into the documents list you sent') but mostly restates the schema's own parameter text rather than adding per-parameter meaning.
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?
States a specific verb and resource ('Order documents by how well they answer a query, best first, with a relevance score each') and anchors it to a concrete API operation. The pipeline sentence (search finds candidates, rerank picks the few) makes its distinct role versus retrieval/embedding siblings unmistakable.
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?
Gives a clear typical-use scenario: 50-100 candidates from vector or keyword search, with rerank narrowing them before they reach the model. It does not name explicit alternatives or when-not-to-use conditions (e.g. versus embeddings_create or models_search), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read text aloud with a text-to-speech model from the Hubris catalogue and get the audio file back as audio content. Same as POST /v1/audio/speech.
Many models need a voice: the list of voices is on the model card (models_get_pricing → supportedVoices) — pick one from there. The answer is mp3 unless you ask for pcm. Up to 5 000 characters per call, a few minutes of speech; split longer texts or use the HTTP API (POST /v1/audio/speech).
Spends money from the account balance: priced per character of text or per second of audio, depending on the model — models_get_pricing shows which. The charge shows up in usage_get.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Text to read aloud, up to 5 000 characters. | |
| model | Yes | Speech model id, vendor included and matched exactly, e.g. "microsoft/mai-voice-2-flash". Find one with models_search and tool: "speech_create". | |
| voice | No | Voice name from the model card. Required when the model has a list of voices. | |
| response_format | No | Audio format: "mp3" (default here, plays everywhere) or "pcm" (raw 16-bit samples). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as a non-read-only, open-world, non-idempotent operation, and the description goes well beyond them: it discloses that the call spends real account balance, that pricing is per character or per second depending on the model, and where the charge surfaces (usage_get). That is exactly the cost/irreversibility context an agent needs before invoking a billable mutation.
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 short paragraphs, front-loaded with what the tool does, then voice/format specifics, then cost. Every sentence carries information, though the closing cost sentence is slightly redundant with the pricing pointer in the middle paragraph.
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 4-parameter tool with no output schema and no nested objects, the description covers inputs, defaults, limits, cost implications, and the return medium (audio content). Nothing an agent needs in order to call it correctly is missing.
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 3 baseline applies, but the description adds real meaning: it points to models_get_pricing → supportedVoices as the source of valid voice names, explains the mp3-vs-pcm choice, and reinforces the 5 000-character input cap. Only the model-id discovery path is a genuinely new hint beyond the schema text.
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?
States a specific verb and resource ('Read text aloud with a text-to-speech model from the Hubris catalogue and get the audio file back as audio content') and pins it to the underlying operation (POST /v1/audio/speech). This clearly separates it from siblings like transcription_create, image_generate and video_create.
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?
Gives concrete usage context: pick a voice when the model needs one, mp3 is the default unless pcm is requested, and texts beyond 5 000 characters should be split or sent to the HTTP API — an explicit alternative. It stops short of stating when *not* to use this tool versus e.g. transcription_create, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe a recording to text with a speech recognition model from the Hubris catalogue (Whisper, GPT-4o Transcribe, Deepgram, ElevenLabs Scribe and others). Same as POST /v1/audio/transcriptions with the audio sent as base64.
Pass the file content itself, base64-encoded — links to files are not accepted. Every byte of the recording is written out inside this call, so it suits clips of seconds, not minutes; send longer recordings through the HTTP API (POST /v1/audio/transcriptions).
Spends money from the account balance: most models are billed per second or minute of audio, some per token. usage.cost_rub is what this call cost.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Recognition model id, vendor included and matched exactly, e.g. "openai/whisper-1". Find one with models_search and tool: "transcription_create". | |
| format | Yes | Audio format of the recording: wav, mp3, flac, m4a, ogg, webm or aac. | |
| language | No | Language of the speech as an ISO-639-1 code, e.g. "ru". Helps accuracy; leave out to detect it automatically. | |
| audio_base64 | Yes | The recording, base64-encoded, without a "data:" prefix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic profile (not read-only, not idempotent, not destructive, open-world). The description adds materially new behavior: the call spends real money from the account balance, billing is per second/minute or per token depending on model, and cost surfaces in usage.cost_rub. That monetization disclosure is exactly the kind of context an agent needs before invoking.
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 tight paragraphs: identity/catalogue, input constraint plus size guidance, then cost. Front-loaded and every sentence carries load; the model-name list is short and useful for orienting the agent.
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 paid, non-idempotent, open-world transcription call with full schema coverage and no output schema, the description covers all the decision-relevant gaps: model discovery, input form, size ceiling with a fallback route, and billing. Nothing needed to call it correctly is missing.
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 four parameters are already documented, making 3 the baseline. The description reinforces audio_base64 ('pass the file content itself, links are not accepted') but adds little syntax or format detail the schema does not already carry.
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?
States a specific verb and resource ('Transcribe a recording to text') plus the model catalogue it draws from, and pins the operation to a known HTTP equivalent (POST /v1/audio/transcriptions with base64 audio). This is enough to separate it from sibling tools like speech_create and youtube_transcribe 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?
Explicitly routes the agent: use this for clips of seconds, send longer recordings through the HTTP API instead, and find the model id via models_search. It also states a hard precondition (base64 content required, links rejected), leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What this connection has spent over a period: requests, tokens, cache savings and the total in rubles. Same as GET /v1/usage. With an API key that is the key's spending; connected through OAuth, it is the spending of the whole app connection over the period, not just of the current hourly token.
Use it to report what a run cost, to check spending against a budget, or to see the charge of tools that do not return their own price (image_generate, speech_create). balance_get shows what is left on the account.
Free to call: it only reads.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Period: "today", "24h" (default), "7d", "30d" or "mtd" — month to date. All times in UTC. |
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| by_key | No | |
| object | Yes | |
| period | Yes | |
| totals | Yes | |
| buckets | Yes | |
| by_model | No | |
| granularity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond that: the scoping semantics under API-key vs OAuth auth (key spend vs whole app-connection spend, not just the current hourly token) and the fact that calls are free. It stops short of rate limits or result shape, but the output schema exists.
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 short paragraphs, front-loaded with what is returned, then when to use it, then the cost/safety note. Every sentence carries distinct information (return shape, auth scoping, use cases, sibling routing, free to call) with no repetition.
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 an output schema present, return values need no description, and the remaining gaps an agent would care about (auth-dependent spending scope, cost of the call, budget/account alternatives) are all covered. Nothing needed to call it correctly is missing.
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% and the single period enum is fully documented in the schema, including the '24h' default and UTC note. The description adds no syntax or format detail beyond the schema, so the 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?
States a specific verb and resource (what this connection has spent over a period) and enumerates the returned components: requests, tokens, cache savings, total in rubles. It also names the sibling it is not by pointing to balance_get for remaining balance, so the agent can distinguish it 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?
Gives explicit use cases (report what a run cost, check against a budget, price tools that do not return their own cost such as image_generate and speech_create) and routes the balance question to balance_get. Nothing about when to select this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start generating a video from a text prompt with a video model from the Hubris catalogue (Veo, Kling, Seedance, Wan, Hailuo, Runway and others). Same as POST /v1/videos. Generation takes from one to several minutes, so this returns a task id right away; poll video_get with it every 15–30 seconds until status is "completed" or "failed".
Allowed durations, resolutions and aspect ratios differ per model — models_get_pricing lists them under video. This tool takes a text prompt only: starting from images or a source video, and models that need a source — video editing, upscaling and talking avatars (FLUX Video Edit, FLUX Video Upscale, Runway Aleph, HeyGen Avatar) — work through the HTTP API (POST /v1/videos).
Connected through OAuth (Claude, Cursor, VS Code)? Video needs the permission to create videos on the consent screen. If this tool answers that videos:write is missing, reconnect.
Spends money from the account balance: priced per second of video. The largest possible cost is held when the task starts, the actual cost is charged when it completes and the difference is returned; a failed generation returns the whole hold.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Fixed seed for a repeatable result, on models that support it. | |
| model | Yes | Video model id, vendor included and matched exactly, e.g. "kwaivgi/kling-v3.0-pro". Find one with models_search and tool: "video_create". | |
| prompt | Yes | What should happen in the video: subject, action, camera, style. | |
| duration | No | Length in seconds, from the values the model supports. | |
| resolution | No | Resolution such as "720p" or "1080p", from the values the model supports. | |
| aspect_ratio | No | Frame shape such as "16:9" or "9:16", from the values the model supports. | |
| generate_audio | No | Generate a soundtrack, on models that can. Usually costs more per second. | |
| idempotency_key | No | Your own unique string for this request. Repeating the call with the same key returns the same task instead of starting and paying for a second one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly=false, destructive=false) but say nothing about async behavior, cost, or auth. The description adds substantive context beyond them: the multi-minute async model, the cost hold/charge/refund mechanics, the OAuth videos:write consent-scope requirement and reconnect hint, and the idempotency-key deduplication behavior. This is exactly the extra context annotations cannot convey.
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 purpose and async contract, then constraints, auth, and billing. Every paragraph carries distinct information, but the OAuth-scope aside is somewhat niche for a general audience and the block is longer than strictly necessary.
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 complex, stateful, money-spending tool with no output schema, the description covers everything an agent needs: return value (task id), polling loop, cost semantics, auth prerequisite, and where to find per-model limits. Nothing essential is left to inference.
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, but the description adds real meaning: duration/resolution/aspect_ratio values are model-dependent (schema just says "from the values the model supports"), model ids must be vendor-qualified and found via models_search, prompt is text-only, and generate_audio usually costs more. This goes beyond the per-field schema text.
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?
Opens with a specific verb+resource: "Start generating a video from a text prompt," and names the model catalogue it draws from. It clearly differentiates itself from video_get (polling) and models_search (finding model ids), so an agent can route correctly without opening schemas.
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?
Explicitly states the workflow (returns a task id, poll video_get every 15–30s until completed/failed) and draws a firm boundary around what this tool cannot do: image-to-video, editing, upscaling and avatars must go through the HTTP API. It also points to models_get_pricing for per-model constraints. When/when-not and the alternative are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status of a video task started with video_create: "pending", "in_progress", "completed" or "failed". Same as GET /v1/videos/{id}.
While the video is being made, usage.estimated_cost is the amount held on the balance. Once it is "completed", usage.cost is the final price and the answer carries a link to the video file as an MCP resource (video/mp4) — read that resource to get the video itself. The file is kept for 72 hours. Files over 25 MB are not served as a resource; download those over HTTP (GET /v1/videos/{id}/content) with the same key.
Free to call: it only reads the task. Poll every 15–30 seconds, not more often.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task id returned by video_create. |
| Name | Required | Description |
|---|---|---|
| id | Yes | Task id. |
| error | No | Why the generation failed, when status is "failed". |
| usage | No | Money: the hold while in progress, the final price once completed. |
| status | Yes | "pending" and "in_progress" — keep polling; "completed" — the video is ready; "failed" — the hold is returned. |
| created | Yes | When the task was started, Unix seconds. |
| unsigned_urls | No | HTTP download links for the finished video; they need the same Bearer key. The MCP resource link in the answer needs nothing extra. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: the cost lifecycle (estimated_cost is a hold, usage.cost is final after completion), the 72-hour file retention, the 25 MB resource-serving limit with an HTTP fallback endpoint, and rate-limit-style polling advice. That is exactly the kind of behavior an agent cannot infer from the schema.
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 status meaning, then cost semantics, then file delivery mechanics, then polling cadence. Every sentence carries distinct, actionable information with no padding.
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?
Even though an output schema exists (so return values need not be described), the description proactively explains the cost fields, the video/mp4 MCP resource, and the 25 MB/HTTP fallback path. For a polling status tool, an agent has everything needed to call it and consume the result 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 description coverage is 100% and the single id parameter is already documented as 'Task id returned by video_create.' The description reinforces the origin of the id and maps it to the REST path parameter {id}, but adds no syntax or format detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb and resource ('Status of a video task started with video_create') and immediately enumerates the possible states, so the agent knows exactly what is returned. It also names the sibling tool that produces the id, distinguishing it from video_create unambiguously.
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?
Gives explicit operational guidance: 'Free to call: it only reads the task. Poll every 15–30 seconds, not more often.' It also names the upstream tool (video_create) whose output is required. When-to-use and cadence are both spelled out, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcript or summary of a YouTube video by its link. Same as POST /v1/video/transcriptions. The video is checked before any model is called: a deleted, private or link-only video, a live stream and a video longer than four hours are refused without charge.
mode "exact" gives a word-for-word transcript, each line with an [HH:MM:SS] timecode, optionally labelled by speaker. mode "fast" gives a summary with key points and rough timecodes — several times faster and cheaper on long videos. An hour-long video in "exact" takes several minutes, which may exceed your client's tool timeout; prefer "fast" there.
Spends money from the account balance: billed per token of the model doing the work. usage.cost_rub is what this call cost.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Link to the YouTube video, e.g. "https://youtu.be/ITL6WqcV6sE". | |
| mode | No | "exact" — word-for-word transcript with timecodes (default); "fast" — summary with key points. | |
| diarize | No | With mode "exact": label lines by speaker ("Speaker 1:", or by name when it is said in the video). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses pre-flight validation with no charge on refusal, the per-token billing model with usage.cost_rub as the cost field, and concrete latency expectations (an hour of video takes several minutes in exact mode). This matters because readOnlyHint=false alone tells the agent a mutation happens but not that money is spent or how long the call blocks.
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?
Well front-loaded: the one-line purpose and the free-validation guarantee come first, then cost, then mode tradeoffs. Dense but each sentence carries weight; the only slightly expendable line is the raw API-path equivalence.
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 still characterizes the return shape (timecoded lines, speaker labels, usage.cost_rub) and covers rejection, billing, latency, and mode semantics, which is enough for correct invocation. A fuller return-structure sketch would be the only gap.
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 3 is the baseline, but the description adds real meaning: it explains the tradeoff between exact (word-for-word, timecodes, optional speaker labels) and fast (key points, rough timecodes, several times faster and cheaper), which is decision-relevant context the enum alone does not convey.
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?
States a specific verb and resource — transcript or summary of a YouTube video by link — and the API equivalence (POST /v1/video/transcriptions) removes ambiguity about what backs it. It does not explicitly differentiate from siblings like transcription_create or video_get, so an agent must infer the YouTube-specific scope from the name.
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?
Gives clear mode-selection guidance (exact vs fast, prefer fast on long videos because exact may exceed the client tool timeout) and lists rejection conditions up front (deleted/private/link-only, live streams, over four hours) so the agent knows when a call will be refused. It never routes the agent to a sibling tool as an alternative, which keeps it short of a 5.
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.
chat_complete1 field changedInput schema / properties / modalitiesAdded value: +{
+ "description": "[\"image\",\"text\"] on chat models that draw (Gemini Image, GPT-5 Image): the pictures come back as image content.",
+ "items": {
+ "enum": [
+ "text",
+ "image"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}decisions_askembeddings_createimage_generatemodels_get_pricing2 fields changedOutput schema / properties / supportedVoicesAdded value: +{
+ "description": "Speech models only: voice names to pass as `voice` to speech_create. Absent when the model has no list.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / videoAdded value: +{
+ "additionalProperties": false,
+ "description": "Video models only: the values video_create accepts for this model.",
+ "properties": {
+ "aspectRatios": {
+ "description": "Allowed `aspect_ratio` values, e.g. \"16:9\". Empty when not selectable.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "durations": {
+ "description": "Allowed `duration` values in seconds. Empty when the model does not take this parameter.",
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "generateAudio": {
+ "description": "Whether `generate_audio` is available on this model.",
+ "type": "boolean"
+ },
+ "resolutions": {
+ "description": "Allowed `resolution` values, e.g. \"720p\". Empty when not selectable.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "seed": {
+ "description": "Whether `seed` is available on this model.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "durations",
+ "resolutions",
+ "aspectRatios",
+ "generateAudio",
+ "seed"
+ ],
+ "type": "object"
+}models_list3 fields changedOutput schema / properties / models / items / properties / capabilities / descriptionPrevious value: -"Any of: vision, image_gen, transcription, audio_in, audio_out, audio (legacy, means either audio direction), tools, reasoning, web_search."New value: +"Any of: vision, image_gen, transcription, audio_in, audio_out, audio (legacy, means either audio direction), decisions, rerank, tools, reasoning, web_search."Output schema / properties / models / items / properties / toolAdded value: +{
+ "description": "The tool that runs this model, e.g. \"chat_complete\" for text models or \"video_create\" for video ones.",
+ "enum": [
+ "chat_complete",
+ "embeddings_create",
+ "rerank",
+ "decisions_ask",
+ "image_generate",
+ "speech_create",
+ "transcription_create",
+ "video_create"
+ ],
+ "type": "string"
+}Output schema / properties / models / items / requiredPrevious value: -[
- "id",
- "displayName",
- "capabilities",
- "contextLength",
- "pricing"
-]New value: +[
+ "id",
+ "displayName",
+ "tool",
+ "capabilities",
+ "contextLength",
+ "pricing"
+]models_search6 fields changedInput schema / properties / capability / descriptionPrevious value: -"Keep only models with this capability. vision — reads images. image_gen — draws them. transcription — speech to text via /v1/audio/transcriptions. audio_in — accepts an audio recording in chat. audio_out — answers with speech. audio — legacy, matches either audio direction. tools — function calling. reasoning — extended thinking. web_search — built-in web search. decisions — yes/no, choice and scale answers with probabilities via /v1/decisions (no text output)."New value: +"Keep only models with this capability. vision — reads images. image_gen — draws them. transcription — speech to text via /v1/audio/transcriptions. audio_in — accepts an audio recording in chat. audio_out — answers with speech. audio — legacy, matches either audio direction. tools — function calling. reasoning — extended thinking. web_search — built-in web search. decisions — yes/no, choice and scale answers with probabilities via /v1/decisions (no text output). rerank — orders documents by relevance to a query via /v1/rerank (no text output)."Input schema / properties / capability / enumPrevious value: -[
- "vision",
- "reasoning",
- "tools",
- "web_search",
- "audio_in",
- "audio_out",
- "audio",
- "image_gen",
- "transcription",
- "decisions"
-]New value: +[
+ "vision",
+ "reasoning",
+ "tools",
+ "web_search",
+ "audio_in",
+ "audio_out",
+ "audio",
+ "image_gen",
+ "transcription",
+ "decisions",
+ "rerank"
+]Input schema / properties / toolAdded value: +{
+ "description": "Keep only models run by this tool: \"chat_complete\" for text, \"embeddings_create\", \"rerank\", \"decisions_ask\", \"image_generate\", \"speech_create\", \"transcription_create\" or \"video_create\". The way to find a model for any tool other than chat_complete.",
+ "enum": [
+ "chat_complete",
+ "embeddings_create",
+ "rerank",
+ "decisions_ask",
+ "image_generate",
+ "speech_create",
+ "transcription_create",
+ "video_create"
+ ],
+ "type": "string"
+}Output schema / properties / models / items / properties / capabilities / descriptionPrevious value: -"Any of: vision, image_gen, transcription, audio_in, audio_out, audio (legacy, means either audio direction), tools, reasoning, web_search."New value: +"Any of: vision, image_gen, transcription, audio_in, audio_out, audio (legacy, means either audio direction), decisions, rerank, tools, reasoning, web_search."Output schema / properties / models / items / properties / toolAdded value: +{
+ "description": "The tool that runs this model, e.g. \"chat_complete\" for text models or \"video_create\" for video ones.",
+ "enum": [
+ "chat_complete",
+ "embeddings_create",
+ "rerank",
+ "decisions_ask",
+ "image_generate",
+ "speech_create",
+ "transcription_create",
+ "video_create"
+ ],
+ "type": "string"
+}Output schema / properties / models / items / requiredPrevious value: -[
- "id",
- "displayName",
- "capabilities",
- "contextLength",
- "pricing"
-]New value: +[
+ "id",
+ "displayName",
+ "tool",
+ "capabilities",
+ "contextLength",
+ "pricing"
+]rerankspeech_createtranscription_createusage_getvideo_createvideo_getyoutube_transcribemodels_search2 fields changedInput schema / properties / capability / descriptionPrevious value: -"Keep only models with this capability. vision — reads images. image_gen — draws them. transcription — speech to text via /v1/audio/transcriptions. audio_in — accepts an audio recording in chat. audio_out — answers with speech. audio — legacy, matches either audio direction. tools — function calling. reasoning — extended thinking. web_search — built-in web search."New value: +"Keep only models with this capability. vision — reads images. image_gen — draws them. transcription — speech to text via /v1/audio/transcriptions. audio_in — accepts an audio recording in chat. audio_out — answers with speech. audio — legacy, matches either audio direction. tools — function calling. reasoning — extended thinking. web_search — built-in web search. decisions — yes/no, choice and scale answers with probabilities via /v1/decisions (no text output)."Input schema / properties / capability / enumPrevious value: -[
- "vision",
- "reasoning",
- "tools",
- "web_search",
- "audio_in",
- "audio_out",
- "audio",
- "image_gen",
- "transcription"
-]New value: +[
+ "vision",
+ "reasoning",
+ "tools",
+ "web_search",
+ "audio_in",
+ "audio_out",
+ "audio",
+ "image_gen",
+ "transcription",
+ "decisions"
+]balance_get1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "balanceKopecks": {
+ "description": "The same balance in kopecks as an integer string. Use this one for arithmetic: it is exact, while the ruble string is for display.",
+ "type": "string"
+ },
+ "balanceRub": {
+ "description": "Balance in rubles as a decimal string, e.g. \"1240.55\". Negative when the account is overdrawn.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "balanceRub",
+ "balanceKopecks"
+ ],
+ "type": "object"
+}chat_complete16 fields changedInput schema / properties / max_tokens / descriptionAdded value: +"Cap on the length of the answer, in tokens."Input schema / properties / messages / descriptionAdded value: +"Conversation so far, oldest first."Input schema / properties / messages / items / properties / content / descriptionAdded value: +"Message text. Can be an array of parts for multimodal input — {type:\"text\"} and {type:\"image_url\"} — on models whose capabilities include \"vision\"."Input schema / properties / messages / items / properties / name / descriptionAdded value: +"Optional author name."Input schema / properties / messages / items / properties / role / descriptionAdded value: +"Who the message is from."Input schema / properties / messages / items / properties / tool_call_id / descriptionAdded value: +"Which tool call this result answers, on a tool message."Input schema / properties / messages / items / properties / tool_calls / descriptionAdded value: +"Tool calls the model asked for, on an assistant message."Input schema / properties / model / descriptionAdded value: +"Model id from the catalogue, vendor included and matched exactly, e.g. \"anthropic/claude-sonnet-5\". Short names and names with a trailing date are rejected. Use models_search to find one."Input schema / properties / reasoning / descriptionAdded value: +"Extended thinking on models with the \"reasoning\" capability: {effort:\"low\"|\"medium\"|\"high\"}, {max_tokens:N}, or {enabled:false} to turn it off."Input schema / properties / response_format / descriptionAdded value: +"{type:\"json_object\"} or {type:\"json_schema\", json_schema:{…}} to constrain the answer to JSON."Input schema / properties / seed / descriptionAdded value: +"Best-effort determinism. Not every model honours it."Input schema / properties / stop / descriptionAdded value: +"Up to four strings that cut the answer short."Input schema / properties / temperature / descriptionAdded value: +"Sampling temperature, 0–2. Some newer models reject it; leave it out unless you need it."Input schema / properties / tool_choice / descriptionAdded value: +"\"auto\", \"none\", \"required\", or a specific function to force."Input schema / properties / tools / descriptionAdded value: +"Function-calling tools, OpenAI shape. Model must have the \"tools\" capability."Input schema / properties / web_search / descriptionAdded value: +"Enables built-in web search on models whose capabilities include \"web_search\"."models_get_pricing2 fields changedInput schema / properties / modelId / descriptionAdded value: +"Exact model id from the catalogue, vendor included, e.g. \"openai/gpt-6-astra\"."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "const": "RUB",
+ "description": "All prices are in rubles.",
+ "type": "string"
+ },
+ "inputPer1MRub": {
+ "description": "Price of 1M input tokens in rubles, decimal string, e.g. \"182.40\". \"0.00\" when unit is not \"token\".",
+ "type": "string"
+ },
+ "isFree": {
+ "description": "True only for genuinely free models. Do not infer this from a zero price: models billed per image or per minute also report \"0.00\" token rates.",
+ "type": "boolean"
+ },
+ "outputPer1MRub": {
+ "description": "Price of 1M output tokens in rubles, decimal string. \"0.00\" when unit is not \"token\".",
+ "type": "string"
+ },
+ "perUnit": {
+ "description": "Present only for models not billed per token. This is where their real price lives.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "priceRub": {
+ "description": "Price of one unit in rubles, decimal string.",
+ "type": "string"
+ },
+ "sku": {
+ "description": "What exactly is billed, e.g. \"image\", \"video\", \"speech\".",
+ "type": "string"
+ },
+ "unit": {
+ "description": "Unit of billing, e.g. \"image\", \"second\", \"1k characters\".",
+ "type": "string"
+ }
+ },
+ "required": [
+ "sku",
+ "unit",
+ "priceRub"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "unit": {
+ "description": "Billing unit. \"token\" — priced per token, the two Rub fields below are meaningful. \"unit\" — priced per image, per minute, per character and so on; token fields are \"0.00\" and the real price is in models_get_pricing → perUnit. \"unknown\" — no pricing on record.",
+ "enum": [
+ "token",
+ "unit",
+ "unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "unit",
+ "inputPer1MRub",
+ "outputPer1MRub",
+ "isFree",
+ "currency"
+ ],
+ "type": "object"
+}models_list3 fields changedInput schema / properties / cursor / descriptionPrevious value: -"Курсор из предыдущего ответа (model id)."New value: +"The `nextCursor` value from the previous response. Omit for the first page."Input schema / properties / limit / descriptionAdded value: +"Models per page, 1–200. Defaults to 50."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "models": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "capabilities": {
+ "description": "Any of: vision, image_gen, transcription, audio_in, audio_out, audio (legacy, means either audio direction), tools, reasoning, web_search.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "contextLength": {
+ "description": "Context window in tokens.",
+ "type": "number"
+ },
+ "displayName": {
+ "description": "Human-readable model name.",
+ "type": "string"
+ },
+ "id": {
+ "description": "Model id to pass to chat_complete and to the OpenAI-compatible API, e.g. \"anthropic/claude-sonnet-5\".",
+ "type": "string"
+ },
+ "pricing": {
+ "additionalProperties": false,
+ "properties": {
+ "inputPer1MRub": {
+ "description": "Price of 1M input tokens in rubles, decimal string, e.g. \"182.40\". \"0.00\" when unit is not \"token\".",
+ "type": "string"
+ },
+ "isFree": {
+ "description": "True only for genuinely free models. Do not infer this from a zero price: models billed per image or per minute also report \"0.00\" token rates.",
+ "type": "boolean"
+ },
+ "outputPer1MRub": {
+ "description": "Price of 1M output tokens in rubles, decimal string. \"0.00\" when unit is not \"token\".",
+ "type": "string"
+ },
+ "unit": {
+ "description": "Billing unit. \"token\" — priced per token, the two Rub fields below are meaningful. \"unit\" — priced per image, per minute, per character and so on; token fields are \"0.00\" and the real price is in models_get_pricing → perUnit. \"unknown\" — no pricing on record.",
+ "enum": [
+ "token",
+ "unit",
+ "unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "unit",
+ "inputPer1MRub",
+ "outputPer1MRub",
+ "isFree"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "displayName",
+ "capabilities",
+ "contextLength",
+ "pricing"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextCursor": {
+ "description": "Pass back as `cursor` to fetch the next page. Absent when the last page was returned.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "models"
+ ],
+ "type": "object"
+}models_search6 fields changedInput schema / properties / capability / descriptionPrevious value: -"audio_in — модель слушает аудиозапись, audio_out — отвечает голосом. Устаревший `audio` = любой из двух."New value: +"Keep only models with this capability. vision — reads images. image_gen — draws them. transcription — speech to text via /v1/audio/transcriptions. audio_in — accepts an audio recording in chat. audio_out — answers with speech. audio — legacy, matches either audio direction. tools — function calling. reasoning — extended thinking. web_search — built-in web search."Input schema / properties / maxInputPer1MRub / descriptionPrevious value: -"Порог в ₽ за 1М входных токенов. Оставляет только модели с токенной тарификацией (pricing.unit = token)."New value: +"Ceiling on the price of 1M input tokens, in rubles. Also restricts the result to models billed per token, since the ceiling means nothing for models billed per image or minute."Input schema / properties / minContext / descriptionAdded value: +"Keep only models whose context window is at least this many tokens."Input schema / properties / query / descriptionPrevious value: -"Подстрока в id или displayName."New value: +"Case-insensitive substring matched against the model id and display name, e.g. \"claude\" or \"gpt\"."Input schema / properties / sort / descriptionPrevious value: -"cheap_input / cheap_output сортируют по цене за токены; модели с оплатой в других единицах уходят в конец списка."New value: +"cheap_input / cheap_output — ascending token price, models not billed per token go last. big_context — widest context window first. popular — most used on Hubris first. Unsorted when omitted."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "models": {
+ "description": "Matching models, at most 50.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "capabilities": {
+ "description": "Any of: vision, image_gen, transcription, audio_in, audio_out, audio (legacy, means either audio direction), tools, reasoning, web_search.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "contextLength": {
+ "description": "Context window in tokens.",
+ "type": "number"
+ },
+ "displayName": {
+ "description": "Human-readable model name.",
+ "type": "string"
+ },
+ "id": {
+ "description": "Model id to pass to chat_complete and to the OpenAI-compatible API, e.g. \"anthropic/claude-sonnet-5\".",
+ "type": "string"
+ },
+ "pricing": {
+ "additionalProperties": false,
+ "properties": {
+ "inputPer1MRub": {
+ "description": "Price of 1M input tokens in rubles, decimal string, e.g. \"182.40\". \"0.00\" when unit is not \"token\".",
+ "type": "string"
+ },
+ "isFree": {
+ "description": "True only for genuinely free models. Do not infer this from a zero price: models billed per image or per minute also report \"0.00\" token rates.",
+ "type": "boolean"
+ },
+ "outputPer1MRub": {
+ "description": "Price of 1M output tokens in rubles, decimal string. \"0.00\" when unit is not \"token\".",
+ "type": "string"
+ },
+ "unit": {
+ "description": "Billing unit. \"token\" — priced per token, the two Rub fields below are meaningful. \"unit\" — priced per image, per minute, per character and so on; token fields are \"0.00\" and the real price is in models_get_pricing → perUnit. \"unknown\" — no pricing on record.",
+ "enum": [
+ "token",
+ "unit",
+ "unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "unit",
+ "inputPer1MRub",
+ "outputPer1MRub",
+ "isFree"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "displayName",
+ "capabilities",
+ "contextLength",
+ "pricing"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "models"
+ ],
+ "type": "object"
+}balance_getchat_completemodels_get_pricingmodels_listmodels_search100+ AI models: FLUX, Sora, Veo, Kling, Runway, Suno. OAuth or Bearer. No VPN. RU billing.
Open AI models through one OpenAI-compatible API: chat, live model list, prices and cost estimates.
GPT, Claude, Gemini, DeepSeek, Grok, Qwen and GLM through one API key. Pay per token.
14 tools: LLM chat, summaries, translation, embeddings, speech, images. From $0.002.
Add one secure layer between your agents and this server.
