opencode-image-mcp

Add a custom provider

add_provider

Idempotent

Register any OpenAI-compatible image endpoint, auto-discover its image models, and save it for reuse in image generation.

Instructions

Use this when the user names an endpoint like https://api.example.com/v1. The server probes {base_url}/models, figures out which models can produce images, saves the provider to the config file, and makes it available to generate_image immediately and on every future run.

Parameters

id: Short handle used in provider:model specs (e.g. example). Lowercase letters, digits, - and _. base_url: The OpenAI-compatible API root, e.g. https://api.example.com/v1. api_key: Optional bearer token, stored in the gitignored config file so it survives restarts. Prefer api_key_env if you would rather keep the secret in an environment variable. api_key_env: Name of an env var holding the key (ignored when api_key is given). Leave both unset for endpoints that need no auth. default_model: Model id to use by default. If omitted and exactly one image model is found, it is selected automatically. dialect: auto (default), images (/images/generations) or chat (/chat/completions with image modalities). auto uses the Images API and transparently falls back to chat-completions on 404/405. make_default: Also set this provider's model as the global default model. discover: Set false to skip the /models probe (required for endpoints that do not implement it).

Returns the discovered models plus any warnings; inspect models and, if there are several, call set_default_model to choose one.

Input Schema

TableJSON Schema

Name	Required	Default
`id`	Yes
`api_key`	No
`dialect`	No	auto
`base_url`	Yes
`discover`	No
`size_style`	No
`api_key_env`	No
`make_default`	No
`default_model`	No
`extra_headers`	No
`exclude_models`	No
`include_models`	No
`aspect_ratio_mode`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only indicate non-read-only, open-world, and idempotent behavior. The description adds substantial useful details: it probes `/models`, falls back from Images API to chat-completions on 404/405, saves the provider to the config file, stores API keys in a gitignored file, and survives restarts.

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?

The description is long but well-structured, front-loads the main use case, and uses a parameter list for clear scanning. Each section adds necessary behavior or context, though a few bullet items could be tightened to reduce overall length.

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

Completeness4/5

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

For a 13-parameter tool with zero schema descriptions, the description covers the core workflow, required parameters, authentication, discovery, fallback behavior, persistence, and next steps via `set_default_model`. It is not fully complete because several optional parameters remain undocumented, and the behavior for duplicate provider IDs is not stated.

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

Parameters4/5

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

With schema description coverage at 0%, the description carries the parameter-documentation burden and does so well for 8 of 13 parameters, adding constraints, examples, defaults, and interaction rules such as `api_key_env` being ignored when `api_key` is given. However, `size_style`, `extra_headers`, `include_models`, `exclude_models`, and `aspect_ratio_mode` receive no explanation, leaving some gaps.

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

Purpose5/5

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

The opening sentence names a specific verb and resource: 'Register any OpenAI-compatible image endpoint and remember it for later.' It also clarifies the tool's role relative to siblings by stating it makes the provider available to `generate_image` immediately and on future runs.

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

Usage Guidelines5/5

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

The description explicitly says when to use the tool: 'Use this when the user names an endpoint like `https://api.example.com/v1`.' It also gives concrete guidance on auth alternatives, skipping discovery with `discover=false`, and tells the agent to call `set_default_model` if multiple models are returned.

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

Deploy Server