Click on "Deploy 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., "@SayMaker MCP Generate an image of a cozy cabin in the snow at sunset."
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.
Run SayMaker's image and video models from any MCP client — Claude, Cursor, Cline, Codex. Ask for a picture or a clip in chat, get the file back.
One credit balance covers the whole shelf: Veo 3.1, Kling 3.0, Seedance 2.0 and 2.5, Nano Banana 2, GPT Image 2.5, Seedream 5.0, Qwen Image 3, MiniMax H3, LTX 2.5, Wan 3.0 and more. Every run reports the exact credit cost it charged, and a run that fails for a technical reason is refunded.
Tool | What it does |
| Every image and video model, and the input each one takes |
| Text to image, with aspect ratio and resolution |
| Change one thing in a photo and keep the rest |
| Text to video, or animate a still you pass in |
| Poll a run submitted with |
| The URL to carry on in the browser |
Related MCP server: @genoooool/mcp-image-generator
npx saymaker-mcp{
"mcpServers": {
"saymaker": {
"command": "npx",
"args": ["-y", "saymaker-mcp"],
"env": { "SAYMAKER_API_KEY": "sk-..." }
}
}
}Point the client at npx -y saymaker-mcp (stdio transport) and set SAYMAKER_API_KEY in its environment.
Create one at saymaker.ai/settings/apikeys. A key runs on your own account: same models, same credit prices, same plan, and the runs land in your library at saymaker.ai/history.
Without a key the server still starts and runs on the signed-out free wallet, which covers one text-to-image run per browser-sized wallet and is capped per machine per day. Video and the paid image models need a key.
Video takes minutes, so generate_video returns a task id by default. Pass wait: true to block, or poll with get_task.
For an edit, describe the change and what must stay: "change the jacket to dark green, keep the face, pose and background exactly as they are". That second half is what decides whether the edit holds.
SAYMAKER_BASE_URL overrides the endpoint; only useful when testing against a local build of the site.
MIT licensed. Made by SayMaker — the AI video generator agent: say the result, it runs the steps.
Edit a photo you already have: change one thing and keep the rest. Pass the image URL and describe ONLY what should change, plus what must stay ("keep the face and background as they are") — that sentence is what decides whether the edit holds.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Wait for the result (default true). | |
| model | No | Model id from list_models. Defaults to Nano Banana 2. | |
| prompt | Yes | The change to make, and what must stay unchanged. | |
| image_url | Yes | Public URL of the image to edit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds useful insight: the prompt must specify what stays unchanged, and that sentence determines whether the edit holds. However, it omits other behavioral details like async return behavior, waiting, or failure modes.
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 brief, front-loaded, and every sentence contributes actionable information. The parenthetical example makes the key instruction concrete without padding.
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?
The tool has no annotations and no output schema, so the description needs to stand alone. It covers the core editing workflow well, but it does not mention result/return behavior or the wait parameter's purpose, which are relevant given the sibling get_task tool.
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%, giving baseline 3. The description adds value beyond the schema by explaining how to write the prompt (change + keep) with an example, which materially clarifies the prompt parameter's expected format.
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 action ('edit') and the resource ('a photo you already have'), which distinguishes it from generating new images. It does not explicitly name sibling tools, but 'you already have' makes the scope reasonably clear.
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?
It gives concrete usage instructions: pass the image URL and describe what should change and what must stay. However, it does not explicitly say when to use this tool instead of generate_image or generate_video, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt on saymaker.ai and return its URL. Runs on your SayMaker credits and reports the exact credit cost. Name subject, framing, light and material in the prompt — vague prompts cost the same as precise ones.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Wait for the result (default true). False returns a task id to poll. | |
| model | No | Model id from list_models. Defaults to Nano Banana 2. | |
| prompt | Yes | What the image should show. | |
| resolution | No | Output resolution where the model offers one: '1K', '2K' or '4K'. Bigger costs more credits. | |
| aspect_ratio | No | e.g. '1:1', '16:9', '9:16', '4:3', '3:4'. Default '1:1'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the transparency burden. It discloses cost behavior ('Runs on your SayMaker credits', 'reports the exact credit cost') and clarifies pricing invariance ('vague prompts cost the same as precise ones'). It doesn't address async/failure behavior, but the wait parameter's schema description covers task-id polling.
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?
Two sentences with no filler. The core purpose and return value are front-loaded, followed by actionable cost and prompt-quality guidance. Every clause earns its place.
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?
For a five-parameter tool with no output schema or annotations, the description covers purpose, return value, cost, and prompt-quality guidance. Parameter specifics are already in the schema. A minor gap is that the unconditional 'return its URL' does not mention the wait=false task-id path, though the wait parameter's schema description fills that in.
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 the baseline is 3. The description adds prompt-construction semantics beyond the schema by recommending that users name subject, framing, light, and material, and by noting that vague prompts have equal cost. This genuinely helps agents produce better prompts.
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 names a specific verb ('Generate'), resource ('an image from a text prompt'), platform ('saymaker.ai'), and result ('return its URL'). This clearly distinguishes it from siblings like edit_image and generate_video, whose purposes are different operations.
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?
It implies when to use it: whenever a new text-prompt image is needed. It offers no explicit when-not-to-use guidance or alternatives, such as using edit_image for existing images or generate_video for motion, so the selection context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a video clip from a prompt, or animate a still by passing image_url. Runs Veo 3.1, Kling 3.0, Seedance 2.0 and the rest of the SayMaker shelf on your own credits; many of them return sound in the same pass. Needs an API key. On a free account, pass model minimax-h3-fast (480p or 768p, 4 to 15 seconds).
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Wait for the result (default false — video takes minutes). | |
| model | No | Model id from list_models. Defaults to Seedance 2.0. | |
| sound | No | Ask for sound where the model writes it in the same pass (default true). | |
| prompt | Yes | The shot: what happens, where, how the camera moves. | |
| duration | No | Clip length in seconds where the model offers a choice, e.g. 4, 6, 8, 10 (MiniMax H3 Fast also 15). | |
| image_url | No | Optional first frame — makes this image-to-video. | |
| resolution | No | e.g. '480p', '720p', '1080p', '4k' ('480p' or '768p' on MiniMax H3 Fast). | |
| aspect_ratio | No | e.g. '16:9', '9:16'. Default '16:9'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does so well. It reveals that the tool runs models on the user's own credits, many return sound in the same pass, an API key is required, and free accounts have specific model/resolution/duration 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?
The description is three sentences with no wasted words. It front-loads the core purpose, then adds high-value details about models, sound, API key requirements, and free-tier limits 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 the absence of annotations and output schema, the description is impressively complete: it covers input variants, auth, model selection, cost implications, and free-tier constraints. It could still mention async behavior or how to fetch results via get_task, but the schema's wait parameter partially covers that gap.
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 schema already covers all 8 parameters at 100% coverage, so the baseline is 3. The description adds meaningful parameter context by highlighting image_url for image-to-video and giving concrete constraints for the free account, like minimax-h3-fast with 480p/768p and 4–15 seconds.
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 opens with a specific verb and resource: 'Generate a video clip from a prompt, or animate a still by passing image_url.' This clearly distinguishes the tool's purpose from siblings like generate_image and edit_image by focusing on video output and including the image-to-video variant.
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?
It provides clear context for when to use the tool: whenever a video clip is needed, either from a prompt or from a starting image. It gives practical usage guidance, like passing model minimax-h3-fast on a free account and using image_url for image-to-video, but it does not explicitly name alternatives or exclude cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a run submitted earlier and return its status and media URL when it is ready.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Keep polling until it finishes (default false). | |
| task_id | Yes | The task id returned by generate_image, edit_image or generate_video. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool polls and returns when ready, indicating a potential blocking behavior. It does not mention error handling, side effects, or safety profile, but 'poll' suggests a read-only operation, offering some 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?
A single sentence that is front-loaded with the primary action ('poll') and resource ('run'), and includes the key return values. Zero 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?
Although there is no output schema, the description explicitly states what is returned ('status and media URL'). It covers the essential need for an agent to use the tool. Minor gaps include no mention of timeout behavior or error conditions, but for a simple polling tool it is sufficiently complete.
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 the schema fully documents the parameters. The description adds no extra meaning for the parameters; it only describes the output. Baseline 3 is appropriate since the description doesn't compensate 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 uses a specific verb ('poll') and resource ('run'), and states the output ('status and media URL'). It clearly distinguishes from sibling generation tools (generate_image, generate_video) by focusing on checking an existing task rather than creating one.
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 phrase 'a run submitted earlier' implies it is used after generate_image or generate_video, providing clear context. However, it does not explicitly state when not to use it or mention alternatives, though sibling names make the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The image and video models SayMaker runs (Veo 3.1, Kling 3.0, Seedance 2.0, Nano Banana 2, GPT Image 2.5, Seedream 5.0, Qwen Image 3, Wan 3.0 and more), with the input each one takes. Use the returned id with generate_image, edit_image or generate_video.
| Name | Required | Description | Default |
|---|---|---|---|
| media | No | Only image models, or only video models. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns model ids and the input each model takes, and that the id is used downstream. It does not mention pagination, ordering, or whether the list is static or dynamic, but for a simple listing tool this is acceptable.
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?
Two sentences, front-loaded with the core purpose and a concrete list of examples, followed by the actionable instruction. 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?
For a simple list tool with one optional parameter and no output schema, the description is complete enough. It tells the agent what it returns and how to use the result. It could mention whether the list is exhaustive or just examples, but the phrase 'and more' covers that.
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% and the only parameter, media, has an enum and a clear description. The tool description adds context about the returned ids but does not need to explain the parameter further. 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?
The description clearly states the tool lists the image and video models SayMaker runs, names specific models, and says the returned id is used with generate_image, edit_image, or generate_video. This distinguishes it from sibling generation tools and gives a precise verb-resource pair.
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 to use the returned id with generate_image, edit_image, or generate_video, which tells the agent when this tool is relevant. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for a listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The URL to carry on in the browser: the agent that plans multi-step jobs from one sentence, a specific model page, or the image or video maker.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model id, when target is 'model'. | |
| target | No | Defaults to 'agent'. |
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 states 'The URL to carry on in the browser', which suggests the tool returns a URL or opens a browser, but it does not clarify whether it opens a new tab, requires user interaction, or what the exact output is. The behavior is ambiguous and under-specified.
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 a single sentence but is awkwardly phrased: 'The URL to carry on in the browser: the agent that plans multi-step jobs from one sentence, a specific model page, or the image or video maker.' The colon introduces a list that is not well structured and the phrasing is confusing. It is short but not well organized or easily scannable.
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?
With no annotations and no output schema, the description must be self-sufficient. It does not clearly state what the tool returns (e.g., a URL string) or what the agent should do with it. It also omits any prerequisites or error handling. For a simple tool with optional params, this is a notable gap.
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 already provides 100% coverage for both parameters: model ('Model id, when target is 'model'.') and target (enum with default 'agent'). The description adds some context about the targets by naming 'agent', 'image', 'video', and 'model page', but it does not add significant new meaning beyond the schema. Baseline of 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?
The title clearly states 'Open SayMaker in a browser', and the description mentions 'The URL to carry on in the browser' and lists the specific targets (agent, image, video, model). This makes the action and resource clear, and it is distinct from sibling tools like generate_image or get_task, which perform different operations.
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?
There is no explicit guidance on when to use this tool versus alternatives, but the tool's purpose is self-evident from the name and description. The description does not mention any exclusions or alternative tools, so usage is implied rather than explicitly stated.
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.
v0.1.0edit_imagegenerate_imagegenerate_videoget_tasklist_modelsopen_in_saymakerScored across 6 tools
Each tool targets a clearly distinct operation: generating an image, generating a video, editing an existing image, listing models, polling a task, and opening the web app. The only potential overlap is generate_video with an image_url versus edit_image, but the descriptions make the output modality and intent clear.
All tool names follow a consistent lowercase verb_noun pattern: edit_image, list_models, generate_image, generate_video, get_task, open_in_saymaker. The naming is predictable and makes the action and target resource immediately understandable.
Six tools is well-scoped for an image and video generation service. Each tool covers a necessary part of the workflow without redundant or filler operations.
The core lifecycle is covered: list available models, generate an image, edit an image, generate a video, poll for results, and continue in the browser. Minor gaps like an explicit cancel-task or credit-balance tool are absent, but agents can still complete the primary workflows.
Generate AI images and videos from any compatible MCP client.
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
