Полный паритет с /v1/chat/completions (без streaming).
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| stop | No | ||
| model | Yes | ||
| tools | No | ||
| messages | Yes | ||
| reasoning | No | ||
| max_tokens | No | ||
| web_search | No | ||
| temperature | No | ||
| tool_choice | No | ||
| response_format | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden but provides only one concrete behavioral trait: no streaming. 'Full parity' implies standard OpenAI-compatible request/response behavior, yet auth, rate-limit, error, and side-effect characteristics are not spelled out.
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 dense sentence with the key caveat (no streaming) included. Every word earns its place and no redundant schema content is repeated.
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 is adequate for an API-savvy agent because the parity statement encodes request/response semantics, but for an 11-parameter tool with no output schema and no annotations it leaves non-API-specific context (return format, error behavior, auth) implicit. It relies heavily on the agent already knowing /v1/chat/completions.
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 0%, but the parity statement gives the parameter names the semantics of OpenAI's chat completions API, which is substantial shared meaning. This compensates for the undocumented schema better than a generic summary would, though it still delegates detailed parameter explanations to external knowledge.
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 that the tool has full parity with the well-known /v1/chat/completions endpoint and explicitly excludes streaming, which makes its function clear. It lacks an explicit verb like 'generate', but the endpoint reference is specific enough to distinguish it from the unrelated model/balance sibling tools.
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?
Usage context is only implied: an agent can infer this is the tool for standard chat completions since no other chat-oriented sibling exists. The only explicit guidance is the exclusion of streaming ('без streaming'); there is no stated when-to-use or when-not-to-use discussion beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
balance_get, chat_complete, and models_get_pricing have clearly distinct purposes. models_list and models_search overlap somewhat, but the descriptions differentiate a paginated catalog from a filtered search.
Most tools follow a resource-first, action-last pattern like balance_get and models_list. models_get_pricing breaks the pattern slightly by embedding a second object in the action, and chat_complete is a little ambiguous, but overall the naming remains readable and predictable.
Five tools is well-scoped for a chat/API gateway server. Each tool serves a distinct core need: balance, completion, pricing, model listing, and model search.
The set covers the main workflows: checking balance, calling chat completions, browsing/searching models, and fetching pricing. The explicit lack of streaming is a notable gap, but non-streaming parity is still provided and there are no dead ends.
