ModelsLab

Chat Completion

chat-completion

Chat with AI language models.
Send messages to an LLM and receive AI-generated responses.
Supports various models and configuration options.
A message may carry a PDF as a {"type":"file","file":{"filename":...,"file_data":"data:application/pdf;base64,..."}} content part.

Input Schema

TableJSON Schema

Name	Required	Description
`n`	No	Number of completions to generate (1-10).
`seed`	No	Random seed for reproducible results.
`stop`	No	Up to 4 sequences where the API will stop generating.
`top_k`	No	Top-k sampling parameter.
`top_p`	No	Nucleus sampling parameter (0-1).
`plugins`	No	OpenRouter plugins. Send [{"id":"file-parser","pdf":{"engine":"native"}}] alongside a {"type":"file"} content part to have a PDF attachment parsed.
`messages`	Yes	Array of message objects with "role" (system/user/assistant) and "content" keys.
`model_id`	Yes	The LLM model ID to use (e.g., "gpt-4", "claude-3").
`max_tokens`	No	Maximum number of tokens to generate.
`temperature`	No	Sampling temperature (0-2). Higher values make output more random.
`response_format`	No	Response format configuration (e.g., {"type": "json_object"}).
`presence_penalty`	No	Penalty for new topics (-2 to 2).
`frequency_penalty`	No	Penalty for frequent tokens (-2 to 2).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations provide only openWorldHint=true, so the description carries most of the behavioral burden. It does add non-obvious context: PDF attachment handling via a typed file content part, tying into the plugins/file-parser mechanism. However, it says nothing about cost, streaming, rate limits, or error behavior, and 'Supports various models and configuration options' is filler.

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?

Front-loaded with the core action and only four short sentences. The PDF detail earns its place, but 'Supports various models and configuration options' is a low-value sentence that could be cut.

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

Completeness3/5

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

With 13 parameters, nested content objects, and no output schema, the description covers the essential action and the notable PDF attachment case but omits the shape of the response (choices, streaming), model selection cost implications, and error handling. Adequate but with clear gaps for a tool this complex.

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

Parameters3/5

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

Schema description coverage is 100%, so all 13 parameters are already documented, which sets the baseline at 3. The description supplements this by showing the exact file content-part shape for messages, adding real value beyond the schema, but it adds nothing for the sampling/knob parameters.

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

Purpose4/5

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

States a specific verb+resource: chat with AI language models, send messages and receive generated responses. It clearly identifies the text-LLM capability amid media-generation siblings, but never names a sibling or explicitly contrasts itself (e.g. against list-models), so differentiation is implied rather than stated.

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?

There is no when-to-use/when-not guidance and no routing to alternatives. The only practical hint is that a message may carry a PDF, which is a capability note rather than selection guidance. Model choice is left entirely to the caller with just two example IDs.

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

All ModelsLab 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?