GPT, Claude, Gemini, DeepSeek, Grok, Qwen and GLM through one API key. Pay per token.
Scored across 6 tools
Each tool has a distinct purpose: asking a model, comparing models, generating images, checking balance, viewing usage, and listing models. There is no overlap between these operations, and descriptions clarify any potential ambiguity (e.g., ask_model vs compare_models).
All tool names follow a clear verb_noun pattern: ask_model, compare_models, generate_image, get_balance, get_usage, list_models. This is consistent and predictable, making it easy for an agent to infer the action and target.
With 6 tools, the server is well-scoped for its purpose (accessing Store API capabilities). Each tool is necessary and covers a distinct aspect of the API, so no tool feels redundant or missing.
The tool set covers the core operations: listing models, querying models, comparing responses, generating images, checking balance, and viewing usage. A minor gap is the lack of a tool for managing API keys or canceling requests, but these are not essential for the stated domain and can be handled externally.
Ask any model from the Store API catalog — GPT, Claude, Gemini, DeepSeek, Grok, Qwen, GLM — and get the answer as text. Lets you consult a second model from inside the current chat. — Задать вопрос любой модели каталога и получить ответ текстом.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model slug, e.g. openai/gpt-6-sol or anthropic/claude-sonnet-5. Get the list from list_models | |
| prompt | Yes | Question or task for the model | |
| system | No | System instruction, optional | |
| max_tokens | No | Answer length limit, 1024 by default |
| Name | Required | Description |
|---|---|---|
| error | No | |
| model | No | |
| answer | No | |
| input_tokens | No | |
| output_tokens | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and openWorldHint=true, so the agent knows this is not a read-only operation and may access external data. The description adds that it queries a catalog model and returns text, but does not disclose potential costs, latency, or any side effects. With annotations covering the safety profile, a 3 is appropriate—some added context but not rich behavioral detail.
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 two sentences (plus a Russian translation) and is front-loaded with the primary action. The second sentence adds context about consulting a second model, which is not redundant. The bilingual duplication is minor but arguably unnecessary for an AI agent; overall it is appropriately sized and efficient.
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?
Given the tool's simplicity, 4 parameters fully described in the schema, and the presence of an output schema, the description is complete enough for an agent to call it correctly. It covers the purpose and the primary use case. Nothing critical is missing; the output format is handled by the output schema.
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 (model, prompt, system, max_tokens) are already documented in the schema. The description does not add any parameter-specific guidance beyond what's there. Per the rubric, a baseline of 3 is correct when the schema handles the documentation.
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 states a specific action ('ask any model') and a clear resource (Store API catalog), and names the model families it covers. It also frames the unique value ('consult a second model from inside the current chat'), which distinguishes it from siblings like list_models or compare_models. No ambiguity about what the tool does.
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?
The description gives a clear usage context: when you want to consult a second model within the chat. It does not explicitly state when not to use it or point to alternatives (e.g., compare_models for comparison), but the context is evident from the purpose and the sibling list. This is 'clear context, no exclusions', which matches a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask 2 to 4 models the same question at once and get their answers side by side with token counts. Every model is billed separately. — Задать один вопрос нескольким моделям сразу и сравнить ответы.
| Name | Required | Description | Default |
|---|---|---|---|
| models | Yes | 2 to 4 model slugs from list_models, e.g. openai/gpt-6-sol and anthropic/claude-sonnet-5 | |
| prompt | Yes | Question or task, the same for every model | |
| system | No | System instruction, optional | |
| max_tokens | No | Answer length limit for each model, 600 by default |
| Name | Required | Description |
|---|---|---|
| answers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only (mutation possible) and not idempotent. The description discloses that billing occurs for each model, which is useful for cost awareness. It does not mention any side effects beyond costs, but it also doesn't state that it sends prompts to external APIs, which could be inferred. The billing disclosure adds value beyond the annotations.
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 two sentences long, front-loaded with the core functionality and key constraint (2-4 models). The bilingual addition is redundant and could be considered waste, but the core is concise. It earns a 4 for being mostly efficient.
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 tool with an output schema and full schema coverage, the description is adequate but not complete. It lacks guidance on expected output structure (though output schema exists), error scenarios, or cost implications beyond billing. Given the complexity of multi-model queries, it could benefit from more context, but the essentials are present.
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 schema fully documents parameters. The description adds minimal extra semantics beyond the schema, excepting the billing note. It does not elaborate on the behavior of max_tokens or system, but the schema covers this, so a 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 action (ask a question to 2-4 models at once) and the outcome (get answers side by side with token counts), effectively distinguishing it from the sibling tool ask_model which handles single-model queries. However, it doesn't explicitly mention the comparison aspect as a differentiator, though the side-by-side display is implied.
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?
The description implies usage for comparing multiple models, but does not explicitly state when to use this tool instead of ask_model (single model) or provide exclusion criteria. The mention of 'every model is billed separately' gives a cost consideration, but there's no clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt and return a link to it. — Сгенерировать изображение по описанию, возвращает ссылку.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Size, e.g. 1024x1024 | |
| model | No | Image model, fal-ai/flux/schnell by default | |
| prompt | Yes | Image description |
| Name | Required | Description |
|---|---|---|
| url | No | |
| error | No | |
| model | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only, not idempotent, and not destructive. The description adds that it returns a link, which is useful, but does not disclose external service dependencies, generation time, or cost implications. It does not contradict annotations, but adds limited extra behavioral context beyond them.
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 a single sentence with the key action front-loaded. The bilingual repetition (English and Russian) is redundant but not detrimental to clarity or length.
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 and full parameter documentation, the description is sufficient for a simple tool. It doesn't mention model/size options, but those are documented in the schema, so nothing critical is missing for correct invocation.
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 schema covers all parameters with descriptions (100% coverage), so the description adds no additional semantic value beyond what is already in the schema. Baseline of 3 is appropriate since 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?
The description clearly states the action ('Generate an image from a text prompt') and the outcome ('return a link to it'). It is distinct from sibling tools that focus on models and usage, leaving no ambiguity about its purpose.
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?
No explicit guidance on when to use this tool versus alternatives, nor any exclusions or conditions. However, the sibling tools are functionally distinct (model queries, balance, usage), so the context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remaining balance on your Store API key, in rubles. — Остаток средств на ключе в рублях.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| top_up_url | No | |
| balance_rub | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the contextual detail that the balance is reported in rubles and is a remaining amount, but it does not disclose staleness, update behavior, or failure characteristics.
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 extremely compact and front-loaded: it immediately states the balance and currency. The Russian repetition mirrors the English rather than adding noise, and every piece of content earns its place.
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 read-only, zero-parameter balance-check tool with an output schema and readOnly/idempotent annotations, the description is complete. Nothing else is needed for an agent to select and invoke it 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?
The tool has zero parameters, so there is nothing for the description to explain. Per the baseline for zero-parameter tools, the description does not need to compensate for schema gaps and correctly introduces no nonexistent parameters.
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 states a specific verb and resource: 'Remaining balance on your Store API key' with the unit 'in rubles'. This makes the tool's purpose unmistakable and semantically distinct from sibling tools like get_usage, which concern usage rather than remaining funds.
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?
No guidance is given about when to choose this tool over alternatives. In particular, the sibling get_usage could plausibly overlap with balance/account-status questions, and the description does not explain the difference or provide any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Spending history for this key: how much went to each model over the last N days, with request counts. — История трат по ключу: сколько ушло на каждую модель за последние N дней.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days back to look, 1 to 90, 7 by default |
| Name | Required | Description |
|---|---|---|
| days | No | |
| by_model | No | |
| total_rub | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds context about output grouping (per model, request counts) but does not disclose additional behavioral traits such as data freshness, rate limits, or scope limitations beyond 'this key.'
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 short and front-loaded with the core purpose. The bilingual repetition of the same sentence adds no new information but is not harmful; it slightly reduces efficiency.
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 simple read-only tool with one optional parameter and an output schema, the description is mostly complete: it states the scope, the time window, and the breakdown by model. It leaves out explicit alternative routing, but that gap was already accounted for in usage guidelines.
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 'days' parameter is fully documented in the schema (1–90, default 7). The description only references 'N days' and adds no meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb-resource pair: 'spending history for this key' with a per-model breakdown over N days and request counts. This clearly distinguishes it from siblings like get_balance and list_models, even without naming them.
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?
The description implies when to use the tool: when you need spending history per model over a recent period. However, it does not explicitly state when not to use it or point to alternatives such as get_balance, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Store API models with prices in rubles per 1M tokens. Use it before ask_model to pick a model. — Список моделей Store API с ценами в рублях за 1 млн токенов.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Filter by provider: openai, anthropic, google, deepseek, qwen, mistral, xai, zai |
| Name | Required | Description |
|---|---|---|
| images | No | Image models with the price of one image in rubles |
| models | No | Text models with prices in rubles per 1M tokens |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that prices are denominated in rubles per 1M tokens, which is useful context, but it does not disclose further behavior such as default provider handling or potential absence of results.
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 English sentence is concise and front-loaded, stating the core function and pricing unit immediately. The Russian translation is redundant for an AI agent but not harmful; the overall length is appropriate for the simple tool.
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?
Given the tool's simplicity, one optional parameter, and an output schema that covers return values, the description provides sufficient context. It explains the purpose, pricing unit, and recommended usage sequence, leaving little ambiguity for correct invocation.
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 only parameter 'provider' is already documented in the schema with allowed values. The description does not add extra parameter-level meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List available Store API models') and the resource (models with prices in rubles per 1M tokens). It also references the sibling ask_model, giving some differentiation, though it does not explicitly distinguish itself from compare_models.
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?
The description explicitly says 'Use it before ask_model to pick a model', providing a concrete usage context. It does not name when not to use it or mention compare_models as an alternative, but the guidance is clear and actionable.
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.
ask_model1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "answer": {
+ "type": "string"
+ },
+ "error": {
+ "type": "string"
+ },
+ "input_tokens": {
+ "type": "number"
+ },
+ "model": {
+ "type": "string"
+ },
+ "output_tokens": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}compare_models1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "answers": {
+ "items": {
+ "properties": {
+ "answer": {
+ "type": "string"
+ },
+ "error": {
+ "type": "string"
+ },
+ "input_tokens": {
+ "type": "number"
+ },
+ "model": {
+ "type": "string"
+ },
+ "output_tokens": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}generate_image1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "model": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_balance1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "balance_rub": {
+ "type": "number"
+ },
+ "top_up_url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}get_usage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "by_model": {
+ "items": {
+ "properties": {
+ "cost_rub": {
+ "type": "number"
+ },
+ "input_tokens": {
+ "type": "number"
+ },
+ "model": {
+ "type": "string"
+ },
+ "output_tokens": {
+ "type": "number"
+ },
+ "requests": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "days": {
+ "type": "number"
+ },
+ "total_rub": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}list_models1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "images": {
+ "description": "Image models with the price of one image in rubles",
+ "items": {
+ "properties": {
+ "display_name": {
+ "type": "string"
+ },
+ "model": {
+ "type": "string"
+ },
+ "price_rub": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "models": {
+ "description": "Text models with prices in rubles per 1M tokens",
+ "items": {
+ "properties": {
+ "display_name": {
+ "type": "string"
+ },
+ "input_per_1m_rub": {
+ "type": "number"
+ },
+ "model": {
+ "type": "string"
+ },
+ "output_per_1m_rub": {
+ "type": "number"
+ },
+ "provider": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}balancecompare_modelsget_balanceget_usageask_modelbalancegenerate_imagelist_modelsAsk Claude, GPT, Grok, GLM, Kimi or DeepSeek from your client; token price plus a $0.001 call fee.
247 LLMs + image/video/voice/music gen + crypto/DeFi/markets/web-search. Pay-per-call USDC, no key.
Image, video, audio and chat from 61 AI models through one connector. Pay per use, no subscription.
Image, video, music and text generation across 100+ models through one endpoint.
Add one secure layer between your agents and this server.
