hubris-mcp

Get model pricing

models_get_pricing

Read-onlyIdempotent

Retrieve the full price of a single model in rubles, including non-token billing. Returns the real per-unit cost (per image, second, or thousand characters) instead of zeroed token rates.

Instructions

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.

Errors with InvalidParams if the model id is unknown or the model is no longer active.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`modelId`	Yes	Exact model id from the catalogue, vendor included, e.g. "openai/gpt-6-astra".

Output Schema

TableJSON Schema

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.
`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".

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by detailing the return format (perUnit price in rubles) and error behavior (InvalidParams for unknown/inactive model IDs), going beyond what the annotations alone convey. Slightly short of a 5 because it doesn't mention any potential side effects or edge cases beyond errors.

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

Conciseness5/5

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

The description is compact and well-structured. The first sentence delivers the primary purpose, the second provides usage guidance and contrasts with siblings, and the third mentions error behavior. Each sentence earns its place, and the most critical information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown but indicated), the description adequately covers when to use the tool, what it returns (perUnit price in rubles), and how errors are handled. It doesn't need to enumerate return fields since the output schema exists, and the description covers all necessary operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description for modelId is already thorough: 'Exact model id from the catalogue, vendor included, e.g. "openai/gpt-6-astra"'. The tool description does not add additional parameter semantics beyond implying that the ID must be valid and active (which is inferred from the error behavior). Since schema coverage is 100%, the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'The full price of one model in rubles' and explicitly distinguishes it from siblings by noting that models_list and models_search may return '0.00' for non-token models, while this tool provides the 'perUnit' price. This leaves no ambiguity about what the tool does or how it differs.

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?

The description gives explicit guidance on when to use this tool: 'Prefer this over the pricing embedded in models_list and models_search whenever the model is not billed per token.' It also mentions error conditions (InvalidParams for unknown/inactive models) and clarifies the output unit, making the choice and invocation straightforward.

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

Install Server