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., "@smartapi-images Create a realistic painting of a sunset over the ocean."
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.
smartapi-images packages a local MCP server and a Codex skill for generating one image through
SmartAPI's explicit POST /v1/images/generations endpoint.
The Codex reasoning model remains a text model such as gpt-5.6-sol. When the user asks for an
image, Codex calls the generate_image tool, which spends the user's SmartAPI balance and saves the
returned image locally.
Node.js 20 or newer
A normal SmartAPI user key with enough available balance
Related MCP server: gpt-image-2-combined
corepack pnpm install
corepack pnpm check
export SMARTAPI_API_KEY='sk-smart-...'The default API URL is https://api.smartapi.shop/v1. Generated files are written to
~/Pictures/SmartAPI by default. Override either setting without editing the repository:
export SMARTAPI_BASE_URL='https://api.smartapi.shop/v1'
export SMARTAPI_IMAGE_OUTPUT_DIR="$HOME/Pictures/SmartAPI"For a direct Codex MCP configuration:
[mcp_servers.smartapi_images]
command = "node"
args = ["/absolute/path/to/smartapi-images/dist/index.js"]
env_vars = ["SMARTAPI_API_KEY", "SMARTAPI_BASE_URL", "SMARTAPI_IMAGE_OUTPUT_DIR"]
tool_timeout_sec = 360
enabled_tools = ["generate_image"]Never put a SmartAPI key in .mcp.json, config.toml, source files, logs, or Git.
generate_image accepts:
prompt: required image description
size: auto or any WIDTHxHEIGHT; SmartAPI reports the normalized effective size
quality: auto, low, medium, or high
output_format: png, jpeg, or webp
filename: optional safe filename without an extension
The tool never overwrites a file and never retries an ambiguous network or timeout failure. It returns the absolute file path, effective size, charged tokens, and SmartAPI request ID.
corepack pnpm typecheck
corepack pnpm test
corepack pnpm buildTests use a local mock HTTP server and never call SmartAPI.
Generate one image through the paid SmartAPI gpt-image-2 endpoint and save it as a local file. Use only when the user asks to create an image. The call spends SmartAPI balance.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Requested WIDTHxHEIGHT or auto. SmartAPI returns the normalized effective size. | auto |
| prompt | Yes | Detailed prompt describing the image to generate. | |
| quality | No | Image generation quality. | high |
| filename | No | Optional filename without extension. Existing files are never overwritten. | |
| output_format | No | File format for the generated image. | png |
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| request_id | Yes | |
| output_format | Yes | |
| charged_tokens | Yes | |
| effective_size | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it mentions the tool spends SmartAPI balance, confirms it saves a local file, and notes that existing files are never overwritten (from schema). Annotations are minimal, so the description effectively carries the burden of disclosure.
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 three efficient sentences, front-loaded with the core action. Every sentence adds value: action, usage condition, and cost/behavior. No fluff or 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 the tool has 5 parameters and an output schema, the description covers the essential behavioral aspects (endpoint, cost, saving) but does not mention the output format or the return structure. It is mostly complete for an agent to understand usage.
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 per-parameter details beyond the schema, but it provides overarching context (paid endpoint, local saving) that indirectly helps. No significant extra parameter-level meaning is added.
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 'generate' and the resource 'image', specifying the paid SmartAPI gpt-image-2 endpoint and that it saves as a local file. This is specific and distinguishes the tool from potential alternatives, even though no siblings are listed.
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 says 'Use only when the user asks to create an image.' This provides a clear condition for when the tool should be invoked. However, it does not mention when not to use it or discuss alternatives, but with no siblings the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0generate_imageOnly one tool exists, so there is no possibility of confusion between tools.
With a single tool, naming is trivially consistent.
One tool is very thin for a typical server, but it may be acceptable if the scope is strictly image generation via a paid endpoint.
The tool only covers generating an image; there are no tools for managing past images (list, delete) or configuring generation parameters beyond the prompt, leaving obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate AI images and videos from any compatible MCP client.
Generate images, video, and audio with Glif's media-generation agent
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Generate images with your own ChatGPT subscription (Plus, Pro or Team), without spending API credits
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/smrcdr/smartapi-images'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
