APIXO

Get APIXO model prices

get_model_pricing

Read-onlyIdempotent

Read prices for the connected APIXO account. Pass a canonical public model ID, or omit model to read all published, currently available models, including LLM prices. Returns specifications, base and final unit prices, billing units and the applied discount type. Read-only and free; any valid MCP login is sufficient. Prices are reference unit rates, not a generation quote. A task-model fixed unit price already includes the applicable account pricing; never apply a discount again. LLM rates follow the applicable token-billing discounts. PER_1M_TOKENS means per million tokens. Some models have multiple billable components or quantity limits; preserve the specification and billing unit. Pricing does not establish that this plugin can generate with a model; use list_models/get_model_schema for execution support.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_model_pricing"
  }
}

Input Schema

Name	Required	Description	Default
`model`	No

Output Schema

Name	Required	Description	Default
`prices`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.6/5.0

Behavior4/5

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: free access, any valid MCP login suffices, prices are reference rates not a generation quote, and task-model fixed prices already include account pricing so discounts must not be re-applied. These are real behavioral warnings an agent would otherwise miss. Slightly dense but genuinely informative.

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

Conciseness4/5

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

Purpose and the model/omit choice are front-loaded, followed by pricing caveats. The back half is dense with billing-unit and discount rules, but nearly every sentence carries non-obvious information. Minor tightening possible in the billing/discount sentences.

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?

An output schema exists, yet the description still summarizes returns (specifications, base/final unit prices, billing units, discount type) and warns about multiple billable components and PER_1M_TOKENS. For a one-parameter read tool, 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.

Parameters4/5

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

Schema coverage is 0% and the lone parameter has only a regex pattern, so the description must carry the meaning. It does: 'model' is a canonical public model ID, and omitting it returns all published, currently available models. It could go further on ID format, but the semantics of the optional parameter are clear.

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?

Opens with a specific verb+resource: 'Read prices for the connected APIXO account,' and clarifies scope (single model vs. all published models). It explicitly separates itself from list_models/get_model_schema, which handle execution support rather than pricing.

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?

States the two calling modes clearly (pass a canonical model ID, or omit to read all published available models) and names the alternative tools with the condition that selects them: 'Pricing does not establish that this plugin can generate with a model; use list_models/get_model_schema for execution support.'

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

All APIXO tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?