The OpenAIMCP server provides access to OpenAI's APIs through AceDataCloud, enabling text, image, audio, and embedding operations.
Chat Completions — Generate conversational responses with models like GPT-4, GPT-4o, GPT-5, and o-series (o1, o3, o4-mini), controlling temperature, max tokens, reasoning effort, and service tier.
Responses API — Access extended model variants (e.g., dated releases like o3-2025-04-16, search-preview) with optional background/async processing.
Image Generation — Create AI images from text using DALL·E 3, gpt-image-1, nano-banana, etc., with custom size, quality, output format, background transparency, and async callback workflows.
Image Editing — Modify existing images via URL with AI, controlling fidelity, size, quality, and format.
Text Embeddings — Convert text into vectors using text-embedding-3-small, text-embedding-3-large, or text-embedding-ada-002 for semantic search and similarity.
Audio — Text-to-speech and audio transcription from URLs using Whisper or GPT-Transcribe models.
Async Task Management — Retrieve individual image tasks or list/filter tasks (by ID, trace ID, etc.) created via callback-based asynchronous requests.
Model Discovery — List available chat, image, and embedding models.
Usage Guide — Access a comprehensive in-server guide with examples and best practices.
Provides tools for interacting with OpenAI API, enabling chat completions, image generation, editing, and text embeddings through various GPT and DALL-E models.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenAIMCP Write a short poem about autumn leaves"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for OpenAI API access using AceDataCloud.
Interact with OpenAI models for chat completions, image generation, text embeddings, and more — directly from Claude, VS Code, or any MCP-compatible client.
Chat Completions — Access GPT-4, GPT-4o, GPT-5, o1, o3, o4-mini, and many more models
Responses API — Extended model variant support including dated releases and search-preview models
Image Generation — Create images with gpt-image-1, gpt-image-2, dall-e-3, and nano-banana models
Image Editing — Modify existing images with AI
Text Embeddings — Generate vector representations with text-embedding-3 models
Audio — Convert text to speech and transcribe audio with whisper-1 or gpt-transcribe
Related MCP server: Outsource MCP
Get an API token from AceDataCloud.
pip install mcp-openaiSet your API token:
export ACEDATACLOUD_API_TOKEN=your_api_token_heremcp-openaiTool | Description |
| Create chat completions using OpenAI models |
| Create responses using the Responses API |
| Generate images from text descriptions |
| Edit existing images with AI |
| Create text embedding vectors |
| Convert text to spoken audio |
| Transcribe audio from a URL |
| List available chat/completion models |
| List available image models |
| List available embedding models |
| Get comprehensive usage guide |
GPT-5 Series: gpt-5.5, gpt-5.5-pro, gpt-5.4, gpt-5.4-pro, gpt-5.2, gpt-5.1, gpt-5, gpt-5-mini, gpt-5-nano
GPT-4 Series: gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, gpt-4o, gpt-4o-mini, gpt-4
Reasoning: o4-mini, o3, o3-mini, o3-pro, o1, o1-mini, o1-pro
gpt-image-1, gpt-image-1.5, gpt-image-2, dall-e-3, dall-e-2, nano-banana, nano-banana-2, nano-banana-pro
text-embedding-3-small, text-embedding-3-large, text-embedding-ada-002
whisper-1, gpt-transcribe
openai_chat_completion(
messages=[{"role": "user", "content": "Explain quantum computing in simple terms"}],
model="gpt-4.1"
)openai_generate_image(
prompt="A serene Japanese garden with cherry blossoms at sunset, photorealistic",
model="gpt-image-1",
size="1024x1024"
)openai_create_embedding(
input="The quick brown fox jumps over the lazy dog",
model="text-embedding-3-small"
)Variable | Description | Default |
| API token (required) | — |
| API base URL |
|
| Request timeout in seconds |
|
| MCP server name |
|
| Logging level |
|
# Install dependencies
pip install -e ".[dev,test]"
# Run tests
pytest
# Run linter
ruff check .MIT
Create a chat completion using OpenAI models via AceDataCloud.
Sends a conversation to the specified model and returns the generated response.
Supports all major GPT and o-series models.
Use this when:
- You need to have a conversation with an AI model
- You want to generate text responses based on a prompt
- You need structured JSON output from a model
Returns:
JSON response containing the model's reply and usage information.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | How many chat completion choices to generate for each input. Default is 1. | |
| model | No | The model to use for chat completion. Options include gpt-4.1, gpt-4o, gpt-5, o1, o3, o4-mini, and many more. Default is gpt-4.1. | gpt-4.1 |
| messages | Yes | A list of messages comprising the conversation. Each message must have a 'role' ('system', 'user', or 'assistant') and 'content' field. Example: [{'role': 'user', 'content': 'Hello!'}] | |
| max_tokens | No | The maximum number of tokens to generate. If not specified, the model uses its default limit. | |
| temperature | No | Sampling temperature between 0 and 2. Higher values (e.g. 0.8) make output more random, lower values (e.g. 0.2) make it more focused. Default is 1. | |
| service_tier | No | Specifies the processing tier. Options: 'auto' (default), 'default', 'flex', 'scale', 'priority'. | |
| reasoning_effort | No | Constrains effort on reasoning for reasoning models. Options: 'minimal', 'low', 'medium', 'high'. Default is 'medium'. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that the tool sends a conversation to a model and returns a JSON response with the reply and usage information. This adequately covers the main behavior without contradictions.
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 concise, using a few sentences and bullet points. Every sentence adds value: purpose, supported models, use cases, and return format. No wasted words.
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?
Given the output schema exists, the description does not need to detail return values extensively. It mentions the JSON response includes reply and usage information, which is sufficient. Parameters are fully described in the schema. Could be more complete with error handling, but adequate.
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 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, e.g., mentioning 'all major GPT and o-series models' and the return format. It does not significantly enhance parameter understanding.
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 clearly states the tool creates a chat completion using OpenAI models. It specifies the verb 'create' and the resource 'chat completion.' The sibling tools like openai_create_embedding and openai_generate_image are distinct, so this description effectively differentiates itself.
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?
The description includes a 'Use this when:' section listing three specific scenarios: conversation, text generation, and structured JSON output. It does not explicitly mention when not to use or alternative tools, but the use cases are clear and distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create text embeddings using OpenAI embedding models via AceDataCloud.
Converts text into numerical vector representations that can be used for
semantic search, text similarity, clustering, and other ML tasks.
Use this when:
- You need to compare semantic similarity between texts
- You want to build a semantic search system
- You need vector representations for machine learning
Returns:
JSON response containing the embedding vectors and usage information.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Input text to embed. Can be a single string, an array of strings, or token arrays. The text to embed into a numerical vector representation. | |
| model | No | The embedding model to use. Options: 'text-embedding-3-small' (default, cost-efficient), 'text-embedding-3-large' (higher quality), 'text-embedding-ada-002' (legacy). | text-embedding-3-small |
| dimensions | No | Optional output embedding size. Supported by text-embedding-3 models. Reduces the embedding dimensions while maintaining quality. | |
| encoding_format | No | The format of the returned embeddings. 'float' returns floating-point numbers (default), 'base64' returns base64-encoded data. | float |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It mentions the return format (JSON with vectors and usage) but does not disclose potential behavioral traits like rate limits, maximum input length, or any side effects. For a nondestructive embedding tool, this is adequate but not exceptional.
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 well-structured with a clear opening, bulleted use cases, and a returns line. It is slightly redundant (first sentence and second sentence overlap), but overall concise and front-loaded.
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?
Given the tool's complexity (4 params, output schema present), the description covers purpose, use cases, and return type. It does not mention error handling or prerequisites, but the presence of an output schema and detailed schema descriptions compensates for these omissions.
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 coverage is 100%, so baseline is 3. The description adds no additional parameter details beyond the schema; the intro and use cases are generic. The schema already adequately describes all four parameters.
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 clearly states the tool creates text embeddings using OpenAI models, with specific verb 'Create' and resource 'embeddings'. It distinguishes from sibling tools like chat completion and image generation by focusing on vector representations for semantic search and clustering.
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?
The description provides explicit 'Use this when' bullet points covering key use cases (semantic similarity, search, ML tasks). However, it lacks exclusionary guidance or alternatives, such as noting that for text generation one should use openai_chat_completion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a response using the OpenAI Responses API via AceDataCloud.
The Responses API is an alternative to the Chat Completions API with support
for a wider range of model variants and additional features like background processing.
Use this when:
- You need access to model-specific dated variants (e.g., o3-2025-04-16)
- You want background processing with a task ID
- You need access to search-preview models
Returns:
JSON response containing the model's output and usage information.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Number of response choices to generate. Default is 1. | |
| input | Yes | A list of messages comprising the conversation. Each message must have a 'role' ('system', 'user', or 'assistant') and 'content' field. Example: [{'role': 'user', 'content': 'Explain quantum computing'}] | |
| model | No | The model to use. Supports a wide range of GPT-4, GPT-4o, GPT-5, and o-series models including their dated variants. Default is gpt-4.1. | gpt-4.1 |
| background | No | Whether to run the model response in the background. When True, returns immediately with a task ID. | |
| max_tokens | No | The maximum number of tokens to generate in the response. If not specified, the model uses its default limit. | |
| temperature | No | Sampling temperature between 0 and 2. Higher values produce more creative output; lower values produce more deterministic output. Default is 1. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses background processing behavior (returns immediately with task ID) and return format (JSON with output and usage). Could add more about idempotency or rate limits.
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?
Highly concise: three sentences plus bullet list. No unnecessary words, front-loaded with purpose, then usage, then return info.
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?
Given an output schema exists (context signal), description adequately covers purpose, usage, and behavioral traits. All 6 parameters are described in schema, and description complements with use-case context.
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 coverage is 100%, so baseline is 3. The description adds context (e.g., background ties to task ID, model variants mention search-preview), but does not significantly augment parameter meaning beyond schema descriptions.
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 clearly states the tool creates a response using the OpenAI Responses API, distinguishes it from Chat Completions, and lists specific use cases like accessing dated model variants and background processing.
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?
The 'Use this when' section provides three explicit scenarios, including background processing and search-preview models. It implicitly contrasts with Chat Completions via sibling tool name, but lacks explicit 'do not use when' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit or modify existing images using OpenAI image models via AceDataCloud.
Applies AI-powered edits to existing images based on text descriptions.
Can modify, extend, or transform images while preserving desired elements.
Use this when:
- You want to modify an existing image
- You need to add, remove, or change elements in an image
- You want to apply a specific style or transformation to an image
Returns:
JSON response containing the edited image URL(s) or base64 data.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Number of images to generate (1-10). Default is 1. | |
| size | No | Output image dimensions as 'WIDTHxHEIGHT' or 'auto'. Default is '1024x1024'. gpt-image-2 accepts any custom dimensions (multiples of 16, longer side ≤ 3840, total pixels ≤ 8,294,400). Common presets — 1K: '1024x1024', '1536x1024', '1024x1536', '1792x1024', '1024x1792'; 2K (1.5× rate): '2048x2048', '2048x1536', '1536x2048', '2048x1152', '1152x2048'; 4K (1.5× rate): '2880x2880', '3264x2448', '2448x3264', '3840x2160', '2160x3840'. dall-e-2: '256x256', '512x512', '1024x1024'. | 1024x1024 |
| image | Yes | Reference image URL(s). Accepts a single URL string or an array of URLs for multi-image editing. The image(s) to use as the starting point for edits. | |
| model | No | The image model to use for editing. Options: 'gpt-image-1' (default), 'gpt-image-1.5', 'gpt-image-2', 'dall-e-3', 'nano-banana' variants. | gpt-image-1 |
| prompt | Yes | Text description of the desired edit. Max 1000 characters for gpt-image models. Describe what you want to change or add to the image. | |
| quality | No | Output quality. Options: 'auto' (default), 'high', 'medium', 'low', 'standard'. | auto |
| background | No | Background handling. 'transparent' removes background, 'opaque' keeps it, 'auto' decides automatically. | |
| callback_url | No | Optional webhook URL. When provided, returns task_id immediately and POSTs result to this URL when complete. | |
| output_format | No | Output file format. Options: 'png' (default), 'jpeg', 'webp'. | png |
| input_fidelity | No | How closely to follow the reference image. 'high' preserves more detail, 'low' allows more creative freedom. | |
| response_format | No | How to return the image. 'url' (default) returns a URL, 'b64_json' returns base64-encoded image data. | url |
| output_compression | No | Compression level (0-100%) for jpeg/webp output. Default is 100. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It mentions AI-powered edits and returns JSON with image URL/base64, but does not disclose important behaviors like model-specific limitations, potential failures, or the irreversible nature of edits. It adds contextual value but lacks comprehensive transparency.
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 front-loaded with purpose and use cases, with bullet points for clarity. It is relatively concise, though the mention of 'AceDataCloud' clutters slightly. The return format section is brief. Overall efficient for the complexity.
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?
Given the tool has 12 parameters and an output schema, the description covers use cases, return format, and high-level capabilities. It could be more complete by explaining model-specific behavior (e.g., size presets for different models) and multi-image editing support, but it is generally adequate.
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 100%, so baseline is 3. The description does not add extra parameter information beyond what the schema provides. It mentions broad capabilities but no parameter-specific details beyond the schema.
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 clearly states the verb 'Edit or modify existing images' and the resource 'existing images using OpenAI image models via AceDataCloud'. It distinguishes itself from sibling tool openai_generate_image by specifying that it works on existing images.
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?
Explicitly lists when to use this tool with three bullet points: modify existing image, add/remove/change elements, apply style/transformation. This helps an AI agent select it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate images using OpenAI image models via AceDataCloud.
Creates AI-generated images from text descriptions using models like
gpt-image-1, dall-e-3, and nano-banana variants.
Use this when:
- You want to create an image from a text description
- You need AI-generated artwork or illustrations
- You want to generate product mockups or visual concepts
Returns:
JSON response containing image URLs or base64 data.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Number of images to generate (1-10). Default is 1. | |
| size | No | Image dimensions as 'WIDTHxHEIGHT' or 'auto' (default). gpt-image-2 accepts any custom dimensions matching the format (multiples of 16, longer side ≤ 3840, total pixels ≤ 8,294,400). Common presets — 1K: '1024x1024', '1536x1024', '1024x1536', '1792x1024', '1024x1792'; 2K (1.5× rate): '2048x2048', '2048x1536', '1536x2048', '2048x1152', '1152x2048'; 4K (1.5× rate): '2880x2880', '3264x2448', '2448x3264', '3840x2160', '2160x3840'. dall-e-2: '256x256', '512x512', '1024x1024'. dall-e-3: '1024x1024', '1792x1024', '1024x1792'. | 1024x1024 |
| model | No | The image model to use. Options: 'gpt-image-1' (default, versatile), 'gpt-image-1.5', 'gpt-image-2', 'dall-e-3', 'dall-e-2', 'nano-banana', 'nano-banana-2', 'nano-banana-pro'. | gpt-image-1 |
| style | No | Image style for dall-e-3. 'vivid' generates hyper-real and dramatic images, 'natural' produces more natural, less hyper-real looking images. | |
| prompt | Yes | A text description of the desired image(s). Be descriptive about the subject, style, lighting, and composition. Example: 'A serene mountain landscape at sunset with golden light' | |
| quality | No | Image quality. Options: 'auto' (default), 'high', 'medium', 'low', 'hd' (dall-e-3 high detail), 'standard' (dall-e-3 standard). | auto |
| background | No | Background type for gpt-image models. 'transparent' removes the background, 'opaque' keeps it, 'auto' decides automatically. | |
| moderation | No | Content moderation level. 'auto' uses default moderation, 'low' applies less strict filtering. | |
| callback_url | No | Optional webhook URL. When provided, the API returns a task_id immediately and POSTs the result to this URL when generation completes. | |
| output_format | No | Output file format. Options: 'png' (default), 'jpeg', 'webp'. | png |
| partial_images | No | Number of partial images to emit during streaming (0-3). 0 returns the final image in one event. | |
| response_format | No | How to return the image. 'url' (default) returns a URL, 'b64_json' returns base64-encoded image data. | url |
| output_compression | No | Compression level (0-100%) for jpeg/webp output formats. Default is 100. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions return format (URL or base64). Lacks disclosure of latency, cost, asynchronous behavior (despite callback_url parameter), model-specific limitations, or that some parameters are model-dependent. Insufficient for an image generation tool.
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?
Structured with a title, purpose paragraph, bullet points for usage, and return type. Some redundancy in bullet points (restate primary purpose). Could be slightly more concise but overall effective.
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?
Complex tool with 13 parameters and output schema. Description covers general purpose and usage but misses key context like model-specific behaviors, async callback handling, and image size limitations. Adequate but not thorough.
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 coverage is 100% with detailed per-parameter descriptions. The tool description adds no additional parameter meaning beyond the schema. Baseline 3 is appropriate.
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?
Clearly states it generates images using specific models (gpt-image-1, dall-e-3, nano-banana) from text descriptions. Distinguishes from sibling tools like openai_edit_image (edits) and openai_chat_completion (text generation). Verb+resource is specific.
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?
Explicitly lists three use cases (create from text, artwork, mockups) in a 'Use this when' section. Does not explicitly mention alternatives or when not to use, but the sibling context implies which tool to use for editing (openai_edit_image). Clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single async image task by its task ID or custom trace ID.
Image generation and editing requests submitted with a callback_url are
processed asynchronously and produce a persistent task record. Use this
tool to check whether the task has finished and to retrieve the final
result.
Note: tasks are only created when the original request included a
callback_url. Synchronous (non-callback) calls are not stored.
Use this when:
- You previously called openai_generate_image or openai_edit_image with a
callback_url and want to retrieve the result
- You want to check the status of an async image task
Returns:
JSON object with task details (id, trace_id, type, request, response,
created_at, finished_at, duration) or an empty object if not found.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Task ID returned by the original image request (e.g. from openai_generate_image or openai_edit_image when callback_url was set). At least one of 'id' or 'trace_id' must be provided. | |
| trace_id | No | Custom trace ID supplied via the 'trace_id' field on the original image request. When both 'id' and 'trace_id' are given, 'trace_id' takes precedence. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that tasks are only created when a callback_url was provided, that synchronous calls are not stored, and it lists the returned fields. This provides sufficient behavioral context for a read-only retrieval tool.
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 well-structured with clear sections, including a note about task creation and usage guidance. It is concise and front-loaded with the main purpose. Minor redundancy (e.g., mentioning async twice) but overall efficient.
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?
Given that an output schema is implied (the description lists returned fields), the description covers the tool's purpose, usage, and parameter semantics. It is complete for a retrieval tool, including the prerequisite about callback_url and the distinction from synchronous calls.
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 100%, with descriptions for both 'id' and 'trace_id'. The description adds value beyond the schema by explaining the relationship: at least one must be provided, and trace_id takes precedence when both are given. It also clarifies that 'id' comes from the original request and 'trace_id' is a custom ID.
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 clearly states that the tool retrieves a single async image task by task ID or custom trace ID. It uses specific verbs ('retrieve') and resource ('async image task'), and distinguishes itself from sibling tools like openai_list_tasks (which lists tasks) and openai_generate_image/openai_edit_image (which create tasks).
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?
The description explicitly states when to use the tool: after calling openai_generate_image or openai_edit_image with a callback_url, to check status and retrieve result. It explains the prerequisite (callback_url must have been set) and the use case of checking async task status. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive guide for using the OpenAI tools.
Provides detailed information on how to use all available OpenAI tools
effectively, including examples and best practices.
Returns:
Complete usage guide for OpenAI tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only mentions returning a guide, omitting whether it is read-only, requires authentication, or has any side effects. Minimal disclosure for a safe retrieval tool.
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?
Three concise sentences, front-loaded with the primary purpose. No redundant or extraneous information.
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?
Given no parameters, the presence of an output schema, and the tool's straightforward nature, the description sufficiently covers what the tool does and what it returns. No additional detail seems necessary.
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?
The tool has zero parameters, and the schema coverage is 100%. The description adds value by outlining the content of the guide (examples, best practices), though parameter-specific details are unnecessary.
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 a specific verb 'Get' and resource 'guide for using the OpenAI tools'. It clearly distinguishes from sibling action tools like openai_chat_completion or openai_generate_image, which perform operations rather than provide documentation.
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?
The description implies this tool should be used to obtain comprehensive guidance, but it does not explicitly state when not to use it or provide alternatives. However, the context of sibling tools makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available chat completion models.
Shows all models available for the chat completions and responses endpoints,
including GPT-4, GPT-4o, GPT-5, and o-series models.
Returns:
Table of all chat models with descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that the tool is a read-only listing operation and describes the return format. However, it does not mention authentication requirements or rate limits, which is acceptable given the simplicity.
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 concise, front-loading the main action in the first sentence. It contains only two sentences plus a returns line, with no unnecessary words.
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?
Given the tool has no parameters and an output schema exists (implied by 'Returns'), the description sufficiently explains the tool's purpose and output. It could mention that it includes both old and new models, but it's adequate.
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?
There are zero parameters with 100% schema coverage. The description adds value by explaining the nature of the returned data (table with descriptions). This meets the baseline for no-parameter tools.
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 clearly states the tool lists all available chat completion models, distinguishing it from sibling list tools like openai_list_embedding_models. The verb 'list' and resource 'chat completion models' are specific.
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?
The description provides no explicit guidance on when to use this tool or when to choose alternatives. While the purpose is clear, it does not educate the agent about its role relative to other tools like openai_chat_completion. Implied usage but no explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available text embedding models.
Shows all models available for the embeddings endpoint.
Returns:
Table of all embedding models with descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full burden. It discloses that the tool lists models and returns a table with descriptions, which is transparent for a read-only list operation. No contradictions.
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 extremely concise with three short sentences. Front-loaded with the main purpose, then additional scope, then return format. No wasted words.
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?
Given the tool's simplicity (no parameters, output schema exists), the description is complete. It covers what it does, scope, and return value adequately.
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?
The input schema has zero parameters, so the description does not need to add parameter info. Baseline of 4 for 0 parameters is appropriate; description adds no unnecessary detail.
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 clearly states 'List all available text embedding models' with a specific verb and resource. It distinguishes from sibling tools like openai_list_chat_models and openai_list_image_models by specifying 'embedding models'.
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?
The description provides no guidance on when to use this tool versus alternatives like openai_create_embedding or other listing tools. No when-not or explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available image generation and editing models.
Shows all models available for the images/generations and images/edits endpoints.
Returns:
Table of all image models with descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively communicates a read-only action that returns a table. It discloses the operation's scope and outcome, which is adequate for a non-destructive listing tool.
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 remarkably concise with three short sentences that front-load the purpose and provide essential details without any fluff.
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?
Given zero parameters and the presence of an output schema, the description fully covers what the tool does and what it returns, leaving no ambiguity.
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?
The tool has no parameters, so the baseline is 4. The description does not need to add parameter details, and it correctly focuses on the output.
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 clearly states the tool lists all available image generation and editing models and specifies the relevant endpoints, effectively distinguishing it from sibling list tools like list_chat_models.
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?
The description states when to use the tool (to list available image models) and mentions endpoints, making the purpose clear. It lacks explicit when-not or alternative guidance, but the context is sufficient for a simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List async image tasks using batch query filters.
Returns a paginated list of async image task records. You must provide at
least one filter: ids, trace_ids, application_id, user_id, or a
created_at_min / created_at_max time window.
Note: tasks are only created when the original request included a
callback_url. Synchronous (non-callback) calls are not stored.
Use this when:
- You want to list multiple tasks at once
- You want to see all tasks for an application or user
Returns:
JSON object with 'items' array and 'count' field.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | List of task IDs to retrieve. | |
| type | No | Filter by upstream type. Options: 'images', 'images_generations', 'images_edits'. | |
| limit | No | Number of tasks per page. Default is 12. | |
| offset | No | Pagination offset. Default is 0. | |
| user_id | No | List all tasks belonging to the specified end user. | |
| trace_ids | No | List of custom trace IDs to retrieve. | |
| application_id | No | List all tasks belonging to the specified application. | |
| created_at_max | No | Latest task creation timestamp (Unix seconds, inclusive). | |
| created_at_min | No | Earliest task creation timestamp (Unix seconds, inclusive). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral info: tasks only created with callback_url, return format (JSON with items and count), and pagination via limit/offset. Lacks rate limit or auth details but sufficient for core behavior.
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?
Concise, well-structured with bullet points. First sentence fronts the purpose. Every sentence adds unique information without redundancy.
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?
Given 9 optional parameters, no annotations, but presence of output schema, the description covers essential constraints (required filter, callback_url condition) and return format. Sufficient for an agent to use correctly.
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 coverage is 100% so baseline is 3. Description adds value by stating the 'at least one filter' requirement and explaining callback_url context, which are not in the schema's parameter descriptions.
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 clearly states it lists async image tasks using batch query filters, with the verb 'list' and resource 'async image tasks'. It distinguishes from sibling tool openai_get_task which retrieves single tasks.
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?
Explicitly provides 'Use this when' scenarios (listing multiple tasks, viewing all tasks for an application or user). Also notes that tasks are only stored with callback_url, implying when not to use. Could explicitly mention single-task retrieval via get_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes (chat, embeddings, image generation, task management). The overlap between 'openai_chat_completion' and 'openai_create_response' introduces ambiguity, but descriptions clarify their specific use cases (standard vs. dated models/background processing).
All tools follow a consistent 'openai_{verb}_{noun}' pattern (e.g., 'openai_create_embedding', 'openai_list_tasks'). The naming is predictable and adheres to a single convention.
With 11 tools, the server covers the major OpenAI functionalities (chat, embeddings, image generation/editing, model listing, async tasks) without being bloated. The count feels well-scoped for a focused AI service.
The tool set covers core workflows (create, read, list) for chat, embeddings, and images, plus async task management. Minor gaps exist (e.g., no delete/moderation tools), but these are not critical for the server's stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AceDataCloud/OpenAIMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
