Skip to main content
Glama
Aimagine-life

hubris-mcp

by Aimagine-life
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Hybrid

Chat completion

chat_complete

Run chat completions on any Hubris model with full OpenAI API parity, including tool calls and structured output. Delegate subtasks to cheaper or stronger models, billed per token.

Instructions

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.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seedNoBest-effort determinism. Not every model honours it.
stopNoUp to four strings that cut the answer short.
modelYesModel 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.
toolsNoFunction-calling tools, OpenAI shape. Model must have the "tools" capability.
messagesYesConversation so far, oldest first.
reasoningNoExtended thinking on models with the "reasoning" capability: {effort:"low"|"medium"|"high"}, {max_tokens:N}, or {enabled:false} to turn it off.
max_tokensNoCap on the length of the answer, in tokens.
web_searchNoEnables built-in web search on models whose capabilities include "web_search".
temperatureNoSampling temperature, 0–2. Some newer models reject it; leave it out unless you need it.
tool_choiceNo"auto", "none", "required", or a specific function to force.
response_formatNo{type:"json_object"} or {type:"json_schema", json_schema:{…}} to constrain the answer to JSON.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

The annotations indicate a non-read-only, non-idempotent, non-destructive operation, and the description adds important behavioral context: it spends real money per token in rubles, is synchronous, and ignores streaming. This goes beyond the basic annotation flags and warns the agent about cost and execution semantics.

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?

The description is a bit longer than strictly necessary, but every paragraph adds value: parity, streaming limitation, model selection guidance, and cost warning. No redundant filler is present, and the structure is logical.

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?

Despite having no output schema, the description states the response shape matches OpenAI chat completions, including tool calls, structured output, and reasoning. It also covers cost, model lookup via sibling tools, and streaming behavior, giving the agent enough context to invoke the tool correctly.

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

Parameters5/5

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

Schema coverage is 100% and each parameter has a detailed, actionable description: model must match the catalogue exactly, messages support multimodal parts, tools require the tools capability, temperature has a caveat for newer models, and reasoning/web_search/response_format are scoped to model capabilities. The description also frames parameters through the OpenAI parity statement.

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 runs a chat completion against any model in the Hubris catalogue, and distinguishes it from sibling tools by referencing models_search for model discovery and balance_get for cost. It also clarifies the synchronous nature and full parity with the OpenAI chat completions endpoint.

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 explicitly explains when to use the tool: to reach a model not otherwise reachable, after picking an id via models_search, and for delegating subtasks. It also gives a clear negative constraint by stating streaming is not available and the stream parameter is ignored.

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

Install Server

Other Tools