Skip to main content
Glama
wagyourtail

openai-mcp

by wagyourtail
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

chat

Offload small, mechanical tasks to a cheap local or OpenAI-compatible model via one-shot prompts or full multi-turn conversations, keeping bulky intermediate output out of your own context.

Instructions

Chat-completion passthrough to the cheap/local model — cheapest way to offload a small mechanical task. Pass prompt (+ optional system) for one-shot completions, or messages for a full OpenAI-style conversation (few-shot examples, multi-turn).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seedNoFixed seed for reproducible output.
stopNoStop sequences.
modelNoModel to use (default: provider/config default). Use list_models to see options.
thinkNoChain-of-thought control (ollama `think`; best-effort on openai-compatible servers). think:false keeps the whole max_tokens budget for the answer.
top_pNoNucleus sampling threshold.
promptNoOne-shot prompt (use this OR messages)
systemNoSystem prompt prepended when using prompt
num_ctxNoContext window size (ollama providers only; bounded for VRAM).
optionsNoProvider-native overrides merged into the request (ollama `options` keys like top_k/repeat_penalty; openai-compatible body fields). Wins over named params.
messagesNoOpenAI-style message list (use this OR prompt)
providerNoProvider name from server config (default: default_provider).
max_tokensNoMax tokens to generate. On thinking models, thinking consumes this budget — pass think:false for short mechanical answers.
temperatureNoSampling temperature (default ~0.2).
response_formatNo"json" for JSON mode, or a JSON schema for structured output

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the burden and does disclose that this is a cheap/local passthrough for mechanical tasks. However, it does not describe return format, error behavior, model fallback behavior, or authentication/permission expectations.

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

Conciseness5/5

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

Two tightly written sentences, front-loaded with the tool’s role and followed by the two input modes. There is no redundant or padding text.

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?

The description covers the main invocation paths for a 14-parameter tool, but without an output schema it does not explain the return shape or limitations. Advanced parameters such as response_format, think, and max_tokens are left entirely to the schema.

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 the schema already documents all 14 parameters thoroughly. The description adds only high-level clarification that prompt/system are for one-shot use and messages supports few-shot or multi-turn conversations.

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?

The description clearly identifies a chat-completion passthrough to a cheap/local model and frames its role as offloading small mechanical tasks. It distinguishes the tool by cost and generality, though it does not explicitly name sibling alternatives.

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

Usage Guidelines4/5

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

It gives clear usage modes: prompt plus optional system for one-shot completions, or messages for OpenAI-style conversations. It lacks explicit when-not guidance or named alternatives such as summarize, extract, or classify.

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

Deploy Server

Other Tools