Skip to main content
Glama

openai_create_chat_completion

Creates chat completions for OpenAI models across text and audio workflows by sending messages and optional audio, modality, response-format, temperature, and token settings.

Instructions

Call Chat Completions for models or audio workflows that require that API surface.

Input Schema

NameRequiredDescriptionDefault
modelYes
audio_jsonNo
temperatureNo
messages_jsonYes
modalities_jsonNo
save_audio_outputNo
response_format_jsonNo
max_completion_tokensNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing about this being a billable, non-idempotent inference call, how audio output is persisted (save_audio_output defaults to true), or what happens with token limits. Only a vague hint about which API surface to use is disclosed.

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

Conciseness3/5

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

It is a single front-loaded sentence with no filler, but brevity here comes from under-specification rather than economy; the one clause that exists is vague rather than informative.

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

Completeness2/5

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

Output schema means return values need not be described, but for an 8-parameter inference tool with zero annotation and zero schema description coverage, the definition leaves an agent without enough information to construct valid arguments or anticipate side effects such as audio file creation and cost.

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

Parameters2/5

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

Schema description coverage is 0% across 8 parameters, so the description must compensate, but it explains none of them - notably that messages_json, audio_json, modalities_json, and response_format_json are JSON-encoded strings, and what temperature=-1 or max_completion_tokens=0 mean as sentinel defaults.

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

Purpose3/5

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

The description names the API surface (Chat Completions) and a verb (Call), so the resource is identifiable, but 'models or audio workflows that require that API surface' is circular and never says concretely what the tool produces (a completion) or how it differs from the sibling openai_create_response, which is the obvious alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gestures at when to use it ('models or audio workflows that require that API surface'), which weakly implies a compatibility/legacy escape hatch, but it never names an alternative such as openai_create_response, openai_generate_speech, or openai_transcribe_audio, and gives no when-not guidance.

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