Search millions of CC0 public-domain AI images: previews, dimensions, provenance, license.
Scored across 13 tools
Each tool targets a distinct resource+action pair: search vs similar-find vs fetch vs download are clearly separated, generate_image vs create_video differ by medium, and resize_image (aspect ratio) vs upscale_image (resolution) are explicitly contrasted in descriptions. No two tools appear interchangeable.
All 13 tools follow a consistent snake_case verb_noun pattern (search_images, generate_image, get_job, upscale_image, send_feedback, etc.). No mixed conventions or vague standalone verbs.
13 tools sit squarely in the well-scoped range, and each covers a necessary facet (discovery, metadata, download, generation, editing, video, account, models, licensing, jobs, feedback). Nothing looks redundant or filler.
Core lifecycle is covered end-to-end: search/find → inspect → download, plus generation, editing, video, job polling, account, models, and licensing. Minor gaps remain (e.g., no listing/deleting of your own edited images or batch operations), but agents can work around them.
Generate a short video from a prompt and/or a start image with one of StockCake's video models (list_models). Priced per second of output; charges credits. Video usually takes longer than the 20 s inline wait: expect a pending result and poll get_job. Re-sending identical arguments within 2 hours returns the same job (reused: true) instead of charging again. Requires a free StockCake account (the host will prompt to sign in).
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Tier key from list_models (e.g. 720p, 1080p, 768p) | |
| model | No | Video model id from list_models (default: H3 Max) | |
| prompt | No | Required unless start_image is given | |
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| start_image | No | Animate from this image (stock id or your edited image id) | |
| aspect_ratio | No | Text-to-video only; a start image sets the ratio | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. | |
| negative_prompt | No | ||
| duration_seconds | No | Clip length; must be one of the model's durations |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: per-second credit pricing, the fact that generation exceeds the 20 s inline wait and will return pending, and a 2-hour dedup window that returns the same job with reused: true. The idempotentHint=false annotation is qualified rather than contradicted – the dedup is time-bounded, so outside 2 hours a new job is created.
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?
Five dense sentences, front-loaded with what the tool does before cost, async behavior, dedup, and auth. No filler and no repetition of the schema.
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?
An output schema exists, so return values need no explanation; the description covers the parts that matter for a costly, long-running, open-world generation call: billing, async polling, idempotency, and auth. An agent has everything needed to invoke it 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 90%, so the schema already documents nearly every parameter including tier, model, aspect_ratio's text-to-video restriction, and duration_seconds. The description adds only that output is priced per second (implying cost scales with duration_seconds), which is marginal value over 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?
States a specific verb and resource ('Generate a short video from a prompt and/or a start image') plus the model source (StockCake's video models via list_models). An agent can immediately distinguish this from the sibling generate_image tool without opening the schema.
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?
Routes the agent to two siblings with explicit conditions: list_models for model/tier ids and get_job for polling once the result is pending. It also declares the auth prerequisite (free StockCake account, host sign-in prompt). It never explicitly says when to prefer generate_image over video, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-resolution download link for a StockCake image (CC0) or one of your edited images. Unmetered — no credits. format "png" returns the lossless sibling when one exists (falls back to jpg). Requires a free StockCake account (the host will prompt to sign in).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Stock image id or your own edited image id | |
| format | No | Default jpg (the original) | |
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the bar is lower. The description adds real behavioral context beyond them: it is unmetered/no-credit, requires sign-in, and explains png fallback behavior. It does not cover pagination or response shape, but the output schema exists.
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 sentences, front-loaded with the core purpose, then cost, then format/auth caveats. No filler or repetition; it is tight though slightly dense.
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 read-only download tool with full schema coverage and an output schema, the description covers auth, billing, and format behavior adequately. Nothing essential is missing, though return/download mechanics are left to the output schema.
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?
With 100% schema description coverage the baseline is 3, and the description meaningfully exceeds it by explaining the 'format' parameter semantics: png returns the lossless sibling when one exists and falls back to jpg. That is genuine meaning the schema's one-line 'Default jpg' does not convey.
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 and resource ('Full-resolution download link for a StockCake image... or one of your edited images') and scopes it to full-resolution CC0/edited assets, which implicitly separates it from get_image, resize_image, and upscale_image. It does not explicitly name a sibling to contrast against, so it stops short of a 5.
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 supplies useful context ('Unmetered — no credits') and a prerequisite ('Requires a free StockCake account'), but gives no explicit when-to-use/when-not guidance or alternative routing versus the sibling tools. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find images visually similar to a given StockCake image id (from search_images results). total_results is the number of similar results returned on this page, not a catalog-wide count.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric image id from a previous result | |
| page | No | Page number, 1-5 | |
| limit | No | Results to return, 1-12 (default 12). Ask for fewer to save tokens. | |
| locale | No | Site locale for the user (default en). Titles and page links are localized; descriptions are English. | |
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| results | Yes | |
| has_more | Yes | |
| refinements | No | Exact mood/style facet values available for this query; counts = how many of the current matches carry each value. mood and style are exact filters (both together keep only their intersection), so a small count means a small result set — rephrase the query instead. |
| total_pages | Yes | |
| license_note | Yes | |
| total_results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful caveat that total_results counts only similar results on the page, not catalog-wide, but does not extend to pagination limits, auth, or other 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?
Two tight sentences, front-loaded with the core action and followed by the one semantic caveat an agent could otherwise misread. Nothing is wasted.
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 an output schema present, rich annotations, and 100% schema description coverage, the description does not need to re-explain parameters or returns. It is complete for its role, only lacking explicit alternative routing that would lift it further.
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 each of the 7 parameters (page limits, locale, context, conversation_id mechanics) fully documented in the schema itself. The description adds no parameter syntax or meaning beyond that, so the baseline 3 applies.
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+resource+scope: 'find images visually similar to a given StockCake image id'. Referencing '(from search_images results)' ties it to the sibling that produces the input, implicitly separating it from text search. It is clear, though it never explicitly names an alternative tool it is not.
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?
Tagging the id as coming 'from search_images results' implies the workflow (search first, then find similar), but there is no explicit when-to-use/when-not guidance or named alternatives. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a new image from a prompt with one of StockCake's AI models (list_models). Charges credits; free credits work with every model. Waits up to 20 s, then returns a job_id for get_job. Re-sending identical arguments within 2 hours returns the same job (reused: true) instead of charging again. Optional reference images guide the composition (the number allowed depends on your plan). Requires a free StockCake account (the host will prompt to sign in).
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Tier key from list_models (e.g. 1k, 2k, standard). Default: the model's default tier. | |
| model | No | Model id from list_models. Default: the site default model (GPT Image 2.6 Standard). | |
| prompt | Yes | ||
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| aspect_ratio | No | ||
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. | |
| reference_images | No | Stock image ids or your own edited image ids used as references |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
The signed-in user's plan, credit balance (free / subscription / purchased), next resets and download quality. Requires a free StockCake account (the host will prompt to sign in).
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so safety is covered. The description adds useful behavioral context beyond annotations: authentication is required via a free StockCake account and the host will prompt sign-in. It does not need to explain return format because an output schema exists.
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 account fields returned and followed by the authentication prerequisite. Every sentence contributes useful information with no filler.
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 read-only account tool with an output schema and rich annotations, the description is nearly complete: it explains what is returned and the sign-in requirement. The only minor gap is explicit usage guidance about when an agent should call it.
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 schema already documents context, llm_model, and conversation_id. The description adds no parameter-level meaning beyond the schema, which is acceptable given full coverage but not above baseline.
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 the exact resource—the signed-in user's account—and enumerates the returned values: plan, credit balance, next resets, and download quality. An agent can immediately tell this is the account-information tool rather than an image, video, search, or license tool.
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 usage by stating the tool returns plan and credit information, and it notes the sign-in prerequisite. However, it does not explicitly say when to call this versus other tools or when not to call it, leaving the agent to infer usage from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one image with full metadata: an inline preview the model can see (unless include_preview is false), real pixel dimensions, AI-generation provenance (prompt, dates, style), license details, and attribution snippets. Also shows the signed-in user's own edited images (ids ≥ 10000000000, as returned by generate_image, resize_image and upscale_image).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric image id (from search results), one of your own edited image ids (from a generate / resize / upscale result; needs the signed-in account), or the image's CDN uuid | |
| locale | No | Site locale for the user (default en). Titles and page links are localized; descriptions are English. | |
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. | |
| include_preview | No | Default true. Set false to skip the inline preview image and save tokens. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| tags | Yes | |
| title | Yes | |
| license | Yes | |
| page_url | Yes | |
| dimensions | Yes | Full-resolution pixel size; null when unknown |
| provenance | Yes | |
| attribution | Yes | |
| description | Yes | |
| preview_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real behavioral context beyond them: the response includes a model-visible inline preview whose token cost can be avoided via include_preview=false, and that edited-image ids require an authenticated account. It stops short of describing failure behavior for unknown ids.
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 dense sentences with no filler, front-loaded with the return payload an agent most needs to decide whether to call it, followed by the id-space clarification. Every clause carries 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?
With a full annotation set, 100% schema coverage and an output schema, the description is nearly complete for a read-by-id tool: it covers return contents, accepted id forms, and the preview toggle. The only missing piece is explicit routing against sibling retrieval/download tools, which is a guidance rather than completeness 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?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning: it explains that the preview is inline and model-visible (why include_preview matters) and maps the id space to its sources, including the ≥10000000000 edited-image range. This reinforces and contextualizes the schema rather than merely repeating it.
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?
States a specific verb and resource ('Fetch one image with full metadata') and enumerates exactly what comes back: inline preview, pixel dimensions, AI provenance, license details, attribution snippets. It also distinguishes this tool from the generation siblings by clarifying that edited-image ids are the ones returned by generate_image, resize_image and upscale_image.
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?
Usage is implied rather than stated: the mention that ids come 'from search results' or from generate/resize/upscale results tells the agent where a valid id originates, and names those siblings. But there is no explicit when-to-use-this-vs-alternative guidance (e.g., get_image vs download_image vs find_similar_images), and no exclusions or prerequisites beyond the parenthetical about needing a signed-in account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status and result of a generate_image / upscale_image / resize_image / create_video job you started (pending, completed with URLs, or error with refund state). Requires a free StockCake account (the host will prompt to sign in).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld/non-destructive, so the bar is lower; the description adds real value by disclosing the account/auth requirement ('requires a free StockCake account, host will prompt to sign in') and the possible outcome states including an error with refund state, which the annotations do not convey.
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 tightly packed sentences, front-loaded with purpose and scoped to the originating tools, with the auth caveat following. No filler; every clause carries 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?
An output schema exists so return values needn't be described, yet the description still summarizes outcome states, and it covers the auth prerequisite. The only minor gap is not stating where job_id originates, though 'job you started' implicitly ties it to the creator tools.
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 75%, and the description adds no syntax or source detail for job_id beyond 'job you started'; context, llm_model, and conversation_id are documented in the schema itself. Baseline 3 applies since the schema does the heavy lifting and the description does not extend it.
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?
States a specific verb+resource (get job status and result) and names the exact sibling tools whose jobs it tracks (generate_image, upscale_image, resize_image, create_video). An agent can distinguish it from those creators and from get_image/get_account without opening any schema.
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?
Strongly implies the when-to-use ('a ... job you started'), i.e. poll after kicking off one of the named async tools. It doesn't explicitly state when not to use it or name a polling alternative, but there is no competing status tool among the siblings, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
License and usage terms for all StockCake images (site-wide CC0 / public domain).
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real substance by stating the license is site-wide CC0/public domain, but says nothing about auth needs, rate limits, or scope boundaries.
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 tight sentence with the key term (CC0 / public domain) front-loaded in parentheses. Zero filler.
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 read-only informational tool whose safety profile is fully covered by annotations, the description adequately conveys what is returned (license and usage terms). Minor gap: it doesn't state the response shape or whether terms vary per image, though the 'site-wide' wording implies uniformity.
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 context, llm_model, and conversation_id are fully documented in the schema, including edge cases ('pass unknown — never guess'). The description adds no parameter meaning, so the baseline 3 applies.
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 the resource ('License and usage terms for all StockCake images') and scopes it ('site-wide CC0 / public domain'). It reads distinctly from the image-manipulation siblings, though it never explicitly names a differentiating sibling, which keeps it just short of a 5.
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 when-to-use guidance, no prerequisites, and no mention of alternatives among the eleven siblings. An agent can infer it is for license questions, but nothing routes it explicitly against e.g. get_image or search_images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Image and video models available to generate_image / create_video with the credit price of every tier. Every model is usable with any credits; video is priced per second. Requires a free StockCake account (the host will prompt to sign in).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Return only one catalog | |
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety burden is light. The description adds two genuinely non-obvious traits: an account/sign-in requirement enforced by the host, and the pricing rules (all models usable with any credits, video priced per second).
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 short sentences with zero filler; the catalog scope and pricing model come first, and the prerequisite (account sign-in) is saved for the end where it acts as a call-out.
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?
An output schema exists so return values need no explanation, and the description covers auth and pricing quirks that the schema does not. It leaves slightly unclear whether the conversation_id handshake is mandatory for a read-only listing call, which is the only meaningful 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?
Schema description coverage is 100%, including the kind enum and elaborate context/llm_model/conversation_id guidance, so the schema does the heavy lifting. The description mentions both image and video catalogs but adds no syntax or filtering guidance beyond that, making 3 the correct baseline.
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?
Names the resource (image and video models with per-tier credit price) and ties it to the sibling operations it feeds, generate_image and create_video. The stated purpose is clear, though it is phrased as a noun phrase rather than saying outright that it returns a browsable catalog.
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 link to generate_image / create_video implies this is a pre-generation model-selection step, but the description never states when to call it versus just calling generate_image directly. No exclusions or alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change an image's aspect ratio by extending the canvas with AI (GPT Image 2.6) — the subject is kept, new area is generated. Charges credits. Output is the model's native size — about 1.5 megapixels, up to 1536 px on the long edge — whatever the source size; the result reports exact dimensions. For print or larger web use, run upscale_image on the result. Waits up to 20 s, then returns a job_id for get_job. Re-sending identical arguments within 2 hours returns the same job (reused: true) instead of charging again. Requires a free StockCake account (the host will prompt to sign in).
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | A StockCake image id (from search_images), one of your own edited image ids (from a previous result), or a job_id. Never a URL. | |
| prompt | Yes | What should fill the extended canvas, e.g. 'extend the sandy beach and sky; keep the subject unchanged, do not crop or stretch' | |
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| aspect_ratio | Yes | Target ratio | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses credit charging, a bounded ~1.5 MP / 1536 px output regardless of source, a 20 s synchronous wait then async job_id handoff, and a 2-hour dedupe window. The dedupe note sits in mild tension with idempotentHint=false, but since the caching is time-bounded and the first call still charges credits, this is a nuance rather than a contradiction.
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?
Front-loaded with the purpose and packed with distinct operational facts, none of which are filler. It is a single dense paragraph, though, so the cost, latency, sizing, and auth facts would scan faster as separate clauses or bullets.
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?
Covers everything an agent needs before calling a credit-charging, open-world generation tool: cost, latency, output size limits, follow-up tool (get_job), escalation path (upscale_image), auth requirement, and dedupe behavior. Return shape is left to the existing output schema, which is appropriate.
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 every parameter (including the unusual llm_model and conversation_id fields) is already documented in the schema. The description adds operational context such as the output dimension behavior but no additional meaning about individual arguments, so the baseline of 3 applies.
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?
States a specific operation (change aspect ratio by extending the canvas with AI outpainting), names the underlying model, and clarifies that the subject is preserved while new area is generated. It also distinguishes itself from the sibling upscale_image by routing that use case explicitly.
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?
Explicit routing: use upscale_image on the result for print or larger web use, poll get_job when the 20 s wait expires, and note that a free StockCake account is required with a host-side sign-in prompt. It also tells the agent that identical re-sends within 2 hours are deduplicated, which is direct guidance on a non-obvious invocation pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Natural-language search over StockCake's catalog. total_results is the total number of matches across the whole catalog, not just this page. refinements lists exact mood/style values for this query with counts (how many current matches carry each); both are exact filters, so a small count means few results. Start with a short query; when total_results is small or off-target, retry with fewer keywords or different phrasing.
| Name | Required | Description | Default |
|---|---|---|---|
| mood | No | Exact facet value — pick one from refinements.mood of a previous search_images result (check refinements.counts.mood first: it is a hard filter, not a boost) | |
| page | No | Page number, 1-5 | |
| type | No | ||
| color | No | Dominant color, e.g. a hex value like #ff0000 | |
| limit | No | Results to return, 1-12 (default 12). Ask for fewer to save tokens. | |
| query | Yes | Short subject, 2–5 words (e.g. 'red vintage rocket'). Long sentences hurt recall: start short, add one qualifier at a time; if results are thin, drop keywords or rephrase. | |
| style | No | Exact facet value — pick one from refinements.style of a previous search_images result (check refinements.counts.style first: it is a hard filter, not a boost) | |
| locale | No | Site locale for the user (default en). Titles and page links are localized; descriptions are English. | |
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| orientation | No | ||
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| results | Yes | |
| has_more | Yes | |
| refinements | No | Exact mood/style facet values available for this query; counts = how many of the current matches carry each value. mood and style are exact filters (both together keep only their intersection), so a small count means a small result set — rephrase the query instead. |
| total_pages | Yes | |
| license_note | Yes | |
| total_results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine beyond-schema context: total_results is a catalog-wide count, and refinements mood/style are hard filters where small counts mean few matches. It does not discuss rate limits or pagination limits (page max 5), keeping it from a 5.
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?
Four front-loaded sentences, each carrying information: search scope, two output-field clarifications, and query strategy. No filler or repetition, though the output-field sentences sit slightly ahead of more actionable query guidance.
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 12-parameter search tool with an output schema already present, the description covers the non-obvious behavioral contract (count semantics, hard-filter facets, retry strategy). Return values needn't be explained given the output schema. Minor gap: no mention of the page 1-5 ceiling or result-set interplay with limit.
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 83%, so the schema already carries most parameter meaning (facet semantics, locale, limits, conversation_id protocol). The description's added text explains output fields (total_results, refinements) rather than parameters, so it adds little parameter-level meaning beyond the baseline.
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?
States a specific verb and resource ('Natural-language search over StockCake's catalog'), which is clear on its own. It does not name or distinguish against potential sibling confusion such as find_similar_images or generate_image, so it stops short of a 5.
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?
Provides real usage guidance for query crafting and retrying ('Start with a short query; when total_results is small or off-target, retry with fewer keywords'), which is better than nothing. However it never says when to choose this tool over siblings like find_similar_images or generate_image, so routing guidance is implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send feedback about this server to its developers. Most important: report a missing capability whenever no available tool fits your task, even if you can work around it (feedback_type "missing_capability"). Also welcome: a tool that failed or confused you, an unhelpful error, or something that worked well. This records the feedback; it does not add or change tools. Do not include user PII or sensitive content.
| Name | Required | Description | Default |
|---|---|---|---|
| details | No | Optional longer context: what you tried, exact parameter values, the error text you saw, and any workaround you used. Omit when the summary says it all. | |
| summary | Yes | One self-contained sentence. For 'missing_capability': the capability you needed, e.g. 'No tool to delete multiple cohorts in one call.' For 'issue': the tool and the problem, e.g. 'query-trends rejects relative date ranges with an unclear error.' | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| sentiment | No | Optional: how the experience felt overall. | |
| tool_name | No | Optional: the existing tool this feedback is about (for 'issue' or 'praise'). Leave empty for 'missing_capability' - the point is that no tool fits. | |
| feedback_type | Yes | What kind of feedback this is. Use 'missing_capability' when the tool you needed does not exist in the tool list - nothing failed, the capability is absent (this is the most valuable report; send it even if you found a workaround). Use 'issue' when an existing tool behaved badly: it failed, returned a confusing error, or its description or schema misled you. Use 'praise' when something worked notably well. Use 'other' for anything else. | |
| task_completed | No | Optional: whether you still completed the user's task despite the problem. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. | |
| friction_points | No | Optional: the specific moments that slowed you down, as short bullet-like sentences, quoting exact tool names, parameters, or error text. | |
| suggested_improvement | No | Optional: the concrete change that would have helped, e.g. the tool to add, the description to reword, or the error message to improve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover readOnly/idempotent/non-destructive, so the safety profile is handled, and the description adds the crucial behavioral fact that this records feedback without adding or changing tools, plus a PII/sensitive-content prohibition. It does not mention whether feedback is reviewed, rate limits, or what happens after submission, but for a fire-and-forget reporting tool that is a minor gap.
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?
Four tight sentences that front-load the primary instruction (report missing capabilities whenever no tool fits) before the secondary cases and the important constraints. Every sentence carries non-redundant information, including the PII warning placed last as a guardrail.
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 feedback-reporting tool with no output schema and full schema description coverage, the description supplies exactly the missing pieces: the priority ordering of feedback types, the fact that nothing is added or changed, and the content restriction. Nothing an agent needs in order to call it correctly is absent.
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 already documents all ten parameters thoroughly, including enum values, examples, and edge-case instructions (conversation_id must be passed unchanged and never invented, llm_model must be 'unknown' rather than guessed). The description adds no parameter meaning beyond what is in the schema, so the baseline 3 is correct and 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?
States a specific verb+resource (send feedback to developers) with an unusually clear statement of primary purpose, weights the missing_capability case explicitly, and distinguishes itself from every sibling (all image/video tools) by being the only meta/reporting tool.
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 names when to use it (report missing capability whenever no tool fits, even with a workaround) and enumerates the other cases (failed tool, confusing error, praise, other) with feedback_type values attached. Conditions are attached to categories, so the agent knows which type to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upscale a StockCake image or one of your edited images 2x, 4x or 8x (lossless PNG output). Charges credits. Waits up to 20 s, then returns a job_id for get_job. Re-sending identical arguments within 2 hours returns the same job (reused: true) instead of charging again. Requires a free StockCake account (the host will prompt to sign in).
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | A StockCake image id (from search_images), one of your own edited image ids (from a previous result), or a job_id. Never a URL. | |
| scale | Yes | ||
| context | Yes | In one sentence, what is the user trying to make or find? | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost (charges credits), latency ceiling (20 s), the async handoff to get_job, the 2-hour dedupe window returning the same job with reused: true without re-charging, and the auth prerequisite. That is far more than the annotations convey; the only tension is that this dedupe behavior reads as effectively idempotent while idempotentHint is false, but the annotation is a hint and the description is explicit and more useful.
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?
Front-loaded with what is produced and at which scales, then cost, latency, polling path, dedupe, and auth in short declarative clauses. Every sentence carries a distinct operational fact with no filler.
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?
Output schema exists, so return shape need not be described; the description still covers the essentials an agent needs before calling: credits spent, timeout behavior, follow-up tool (get_job), repeat-call semantics, and the account requirement.
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 80% and the image, context, llm_model and conversation_id parameters are already documented in the schema, including the 'never a URL' rule. The description only echoes the 2x/4x/8x scale options and adds no new syntax or format guidance for the 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?
States a specific verb and resource (upscale a StockCake or edited image) plus the exact scale factors and output format (lossless PNG), which implicitly separates it from sibling resize_image. It does not name the sibling alternative explicitly, so an agent must infer the boundary.
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?
Gives clear operational context: it charges credits, blocks up to 20 s, then hands off a job_id to get_job, and requires a free account. It does not state when to prefer this over resize_image or what happens on non-square/oversized inputs, so no explicit exclusion is provided.
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.
generate_image1 field changedInput schema / properties / model / descriptionPrevious value: -"Model id from list_models. Default: the site default model for subscribers, a low-cost model otherwise."New value: +"Model id from list_models. Default: the site default model (GPT Image 2.6 Standard)."create_video1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "job_id": {
- "type": "string"
- },
- "status": {
- "const": "completed",
- "type": "string"
- },
- "video": {
- "additionalProperties": false,
- "properties": {
- "duration_seconds": {
- "type": [
- "number",
- "null"
- ]
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "url",
- "duration_seconds"
- ],
- "type": "object"
- }
- },
- "required": [
- "job_id",
- "status",
- "video",
- "credits_charged"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "job_id": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "status": {
- "const": "pending",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "credits_charged",
- "message"
- ],
- "type": "object"
- },
- {
- "additionalProperties": {},
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "reused": {
+ "const": true,
+ "type": "boolean"
+ },
+ "status": {
+ "const": "completed",
+ "type": "string"
+ },
+ "video": {
+ "additionalProperties": false,
+ "properties": {
+ "duration_seconds": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "duration_seconds"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "video",
+ "credits_charged"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "reused": {
+ "const": true,
+ "type": "boolean"
+ },
+ "status": {
+ "const": "pending",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "credits_charged",
+ "message"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+]generate_image1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "image": {
- "additionalProperties": false,
- "properties": {
- "dimensions": {
- "anyOf": [
- {
- "additionalProperties": false,
- "properties": {
- "height": {
- "type": "number"
- },
- "width": {
- "type": "number"
- }
- },
- "required": [
- "width",
- "height"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "Output pixel size; null when the file could not be probed"
- },
- "id": {
- "description": "Edited image id — pass it to get_image (preview), download_image, or as an image reference",
- "type": [
- "number",
- "null"
- ]
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "url",
- "dimensions"
- ],
- "type": "object"
- },
- "job_id": {
- "type": "string"
- },
- "status": {
- "const": "completed",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "image",
- "credits_charged"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "job_id": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "status": {
- "const": "pending",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "credits_charged",
- "message"
- ],
- "type": "object"
- },
- {
- "additionalProperties": {},
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "image": {
+ "additionalProperties": false,
+ "properties": {
+ "dimensions": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "height": {
+ "type": "number"
+ },
+ "width": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Output pixel size; null when the file could not be probed"
+ },
+ "id": {
+ "description": "Edited image id — pass it to get_image (preview), download_image, or as an image reference",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "dimensions"
+ ],
+ "type": "object"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "reused": {
+ "const": true,
+ "type": "boolean"
+ },
+ "status": {
+ "const": "completed",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "image",
+ "credits_charged"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "reused": {
+ "const": true,
+ "type": "boolean"
+ },
+ "status": {
+ "const": "pending",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "credits_charged",
+ "message"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+]resize_image1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "image": {
- "additionalProperties": false,
- "properties": {
- "dimensions": {
- "anyOf": [
- {
- "additionalProperties": false,
- "properties": {
- "height": {
- "type": "number"
- },
- "width": {
- "type": "number"
- }
- },
- "required": [
- "width",
- "height"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "Output pixel size; null when the file could not be probed"
- },
- "id": {
- "description": "Edited image id — pass it to get_image (preview), download_image, or as an image reference",
- "type": [
- "number",
- "null"
- ]
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "url",
- "dimensions"
- ],
- "type": "object"
- },
- "job_id": {
- "type": "string"
- },
- "status": {
- "const": "completed",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "image",
- "credits_charged"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "job_id": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "status": {
- "const": "pending",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "credits_charged",
- "message"
- ],
- "type": "object"
- },
- {
- "additionalProperties": {},
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "image": {
+ "additionalProperties": false,
+ "properties": {
+ "dimensions": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "height": {
+ "type": "number"
+ },
+ "width": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Output pixel size; null when the file could not be probed"
+ },
+ "id": {
+ "description": "Edited image id — pass it to get_image (preview), download_image, or as an image reference",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "dimensions"
+ ],
+ "type": "object"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "reused": {
+ "const": true,
+ "type": "boolean"
+ },
+ "status": {
+ "const": "completed",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "image",
+ "credits_charged"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "reused": {
+ "const": true,
+ "type": "boolean"
+ },
+ "status": {
+ "const": "pending",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "credits_charged",
+ "message"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+]upscale_image1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "image": {
- "additionalProperties": false,
- "properties": {
- "dimensions": {
- "anyOf": [
- {
- "additionalProperties": false,
- "properties": {
- "height": {
- "type": "number"
- },
- "width": {
- "type": "number"
- }
- },
- "required": [
- "width",
- "height"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "Output pixel size; null when the file could not be probed"
- },
- "id": {
- "description": "Edited image id — pass it to get_image (preview), download_image, or as an image reference",
- "type": [
- "number",
- "null"
- ]
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "url",
- "dimensions"
- ],
- "type": "object"
- },
- "job_id": {
- "type": "string"
- },
- "status": {
- "const": "completed",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "image",
- "credits_charged"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "job_id": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "status": {
- "const": "pending",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "credits_charged",
- "message"
- ],
- "type": "object"
- },
- {
- "additionalProperties": {},
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "image": {
+ "additionalProperties": false,
+ "properties": {
+ "dimensions": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "height": {
+ "type": "number"
+ },
+ "width": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Output pixel size; null when the file could not be probed"
+ },
+ "id": {
+ "description": "Edited image id — pass it to get_image (preview), download_image, or as an image reference",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "dimensions"
+ ],
+ "type": "object"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "reused": {
+ "const": true,
+ "type": "boolean"
+ },
+ "status": {
+ "const": "completed",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "image",
+ "credits_charged"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "reused": {
+ "const": true,
+ "type": "boolean"
+ },
+ "status": {
+ "const": "pending",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "credits_charged",
+ "message"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+]generate_image1 field changedInput schema / properties / model / descriptionPrevious value: -"Model id from list_models. Default: the site default for subscribers, the free model otherwise."New value: +"Model id from list_models. Default: the site default model for subscribers, a low-cost model otherwise."get_account1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "balance": {
- "additionalProperties": false,
- "properties": {
- "free": {
- "type": "number"
- },
- "purchased": {
- "type": "number"
- },
- "subscription": {
- "type": "number"
- },
- "total": {
- "type": "number"
- }
- },
- "required": [
- "total",
- "free",
- "subscription",
- "purchased"
- ],
- "type": "object"
- },
- "formats": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "is_entitled": {
- "type": "boolean"
- },
- "max_download_multiplier": {
- "type": "number"
- },
- "next_reset": {
- "additionalProperties": false,
- "properties": {
- "free": {
- "type": [
- "string",
- "null"
- ]
- },
- "subscription": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "free",
- "subscription"
- ],
- "type": "object"
- },
- "plan": {
- "type": "string"
- },
- "tier": {
- "type": [
- "string",
- "null"
- ]
- },
- "upgrade_url": {
- "type": "string"
- }
- },
- "required": [
- "plan",
- "tier",
- "is_entitled",
- "balance",
- "next_reset",
- "max_download_multiplier",
- "formats",
- "upgrade_url"
- ],
- "type": "object"
- },
- {
- "additionalProperties": {},
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "balance": {
+ "additionalProperties": false,
+ "properties": {
+ "free": {
+ "type": "number"
+ },
+ "purchased": {
+ "type": "number"
+ },
+ "subscription": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "free",
+ "subscription",
+ "purchased"
+ ],
+ "type": "object"
+ },
+ "is_entitled": {
+ "type": "boolean"
+ },
+ "max_download_multiplier": {
+ "type": "number"
+ },
+ "next_reset": {
+ "additionalProperties": false,
+ "properties": {
+ "free": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "subscription": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "free",
+ "subscription"
+ ],
+ "type": "object"
+ },
+ "plan": {
+ "type": "string"
+ },
+ "tier": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "upgrade_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "plan",
+ "tier",
+ "is_entitled",
+ "balance",
+ "next_reset",
+ "max_download_multiplier",
+ "upgrade_url"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+]create_video1 field changedInput schema / properties / tier / descriptionPrevious value: -"Tier key from list_models (e.g. 720p, 1080p, 720p-audio)"New value: +"Tier key from list_models (e.g. 720p, 1080p, 768p)"create_video1 field changedInput schema / properties / model / descriptionPrevious value: -"Video model id from list_models (default: MiniMax H3)"New value: +"Video model id from list_models (default: H3 Max)"find_similar_images3 fields changedOutput schema / properties / refinements / descriptionPrevious value: -"Exact mood/style facet values available for this query — pass one back as `mood` / `style` to narrow"New value: +"Exact mood/style facet values available for this query; counts = how many of the current matches carry each value. mood and style are exact filters (both together keep only their intersection), so a small count means a small result set — rephrase the query instead."Output schema / properties / refinements / properties / countsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "mood": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "style": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "mood",
+ "style"
+ ],
+ "type": "object"
+}Output schema / properties / refinements / requiredPrevious value: -[
- "mood",
- "style"
-]New value: +[
+ "mood",
+ "style",
+ "counts"
+]generate_image1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "image": {
- "additionalProperties": false,
- "properties": {
- "id": {
- "description": "Edited image id — pass it to download_image or as an image reference",
- "type": [
- "number",
- "null"
- ]
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "url"
- ],
- "type": "object"
- },
- "job_id": {
- "type": "string"
- },
- "status": {
- "const": "completed",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "image",
- "credits_charged"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "job_id": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "status": {
- "const": "pending",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "credits_charged",
- "message"
- ],
- "type": "object"
- },
- {
- "additionalProperties": {},
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "image": {
+ "additionalProperties": false,
+ "properties": {
+ "dimensions": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "height": {
+ "type": "number"
+ },
+ "width": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Output pixel size; null when the file could not be probed"
+ },
+ "id": {
+ "description": "Edited image id — pass it to get_image (preview), download_image, or as an image reference",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "dimensions"
+ ],
+ "type": "object"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "status": {
+ "const": "completed",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "image",
+ "credits_charged"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "const": "pending",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "credits_charged",
+ "message"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+]get_image2 fields changedInput schema / properties / id / anyOfPrevious value: -[
- {
- "exclusiveMinimum": 0,
- "maximum": 2147483647,
- "type": "integer"
- },
- {
- "maxLength": 64,
- "minLength": 4,
- "type": "string"
- }
-]New value: +[
+ {
+ "exclusiveMinimum": 0,
+ "maximum": 9007199254740991,
+ "type": "integer"
+ },
+ {
+ "maxLength": 64,
+ "minLength": 4,
+ "type": "string"
+ }
+]Input schema / properties / id / descriptionPrevious value: -"Numeric image id (from search results) or the image's CDN uuid"New value: +"Numeric image id (from search results), one of your own edited image ids (from a generate / resize / upscale result; needs the signed-in account), or the image's CDN uuid"resize_image1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "image": {
- "additionalProperties": false,
- "properties": {
- "id": {
- "description": "Edited image id — pass it to download_image or as an image reference",
- "type": [
- "number",
- "null"
- ]
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "url"
- ],
- "type": "object"
- },
- "job_id": {
- "type": "string"
- },
- "status": {
- "const": "completed",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "image",
- "credits_charged"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "job_id": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "status": {
- "const": "pending",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "credits_charged",
- "message"
- ],
- "type": "object"
- },
- {
- "additionalProperties": {},
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "image": {
+ "additionalProperties": false,
+ "properties": {
+ "dimensions": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "height": {
+ "type": "number"
+ },
+ "width": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Output pixel size; null when the file could not be probed"
+ },
+ "id": {
+ "description": "Edited image id — pass it to get_image (preview), download_image, or as an image reference",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "dimensions"
+ ],
+ "type": "object"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "status": {
+ "const": "completed",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "image",
+ "credits_charged"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "const": "pending",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "credits_charged",
+ "message"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+]search_images5 fields changedInput schema / properties / mood / descriptionPrevious value: -"Exact facet value — pick one from refinements.mood of a previous search_images result"New value: +"Exact facet value — pick one from refinements.mood of a previous search_images result (check refinements.counts.mood first: it is a hard filter, not a boost)"Input schema / properties / style / descriptionPrevious value: -"Exact facet value — pick one from refinements.style of a previous search_images result"New value: +"Exact facet value — pick one from refinements.style of a previous search_images result (check refinements.counts.style first: it is a hard filter, not a boost)"Output schema / properties / refinements / descriptionPrevious value: -"Exact mood/style facet values available for this query — pass one back as `mood` / `style` to narrow"New value: +"Exact mood/style facet values available for this query; counts = how many of the current matches carry each value. mood and style are exact filters (both together keep only their intersection), so a small count means a small result set — rephrase the query instead."Output schema / properties / refinements / properties / countsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "mood": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "style": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "mood",
+ "style"
+ ],
+ "type": "object"
+}Output schema / properties / refinements / requiredPrevious value: -[
- "mood",
- "style"
-]New value: +[
+ "mood",
+ "style",
+ "counts"
+]send_feedbackupscale_image1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "image": {
- "additionalProperties": false,
- "properties": {
- "id": {
- "description": "Edited image id — pass it to download_image or as an image reference",
- "type": [
- "number",
- "null"
- ]
- },
- "url": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "url"
- ],
- "type": "object"
- },
- "job_id": {
- "type": "string"
- },
- "status": {
- "const": "completed",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "image",
- "credits_charged"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "credits_charged": {
- "type": "number"
- },
- "job_id": {
- "type": "string"
- },
- "message": {
- "type": "string"
- },
- "status": {
- "const": "pending",
- "type": "string"
- }
- },
- "required": [
- "job_id",
- "status",
- "credits_charged",
- "message"
- ],
- "type": "object"
- },
- {
- "additionalProperties": {},
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "image": {
+ "additionalProperties": false,
+ "properties": {
+ "dimensions": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "height": {
+ "type": "number"
+ },
+ "width": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "width",
+ "height"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Output pixel size; null when the file could not be probed"
+ },
+ "id": {
+ "description": "Edited image id — pass it to get_image (preview), download_image, or as an image reference",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "url",
+ "dimensions"
+ ],
+ "type": "object"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "status": {
+ "const": "completed",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "image",
+ "credits_charged"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "credits_charged": {
+ "type": "number"
+ },
+ "job_id": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "status": {
+ "const": "pending",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job_id",
+ "status",
+ "credits_charged",
+ "message"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+]create_video1 field changedInput schema / properties / model / descriptionPrevious value: -"Video model id from list_models (default: Veo 3.1 Fast)"New value: +"Video model id from list_models (default: MiniMax H3)"get_account1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "balance": {
- "additionalProperties": false,
- "properties": {
- "free": {
- "type": "number"
- },
- "purchased": {
- "type": "number"
- },
- "subscription": {
- "type": "number"
- },
- "total": {
- "type": "number"
- }
- },
- "required": [
- "total",
- "free",
- "subscription",
- "purchased"
- ],
- "type": "object"
- },
- "formats": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "is_entitled": {
- "type": "boolean"
- },
- "max_download_multiplier": {
- "type": "number"
- },
- "next_reset": {
- "additionalProperties": false,
- "properties": {
- "free": {
- "type": [
- "string",
- "null"
- ]
- },
- "subscription": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "required": [
- "free",
- "subscription"
- ],
- "type": "object"
- },
- "plan": {
- "type": "string"
- },
- "tier": {
- "type": [
- "string",
- "null"
- ]
- },
- "upgrade_url": {
- "type": "string"
- },
- "user_id": {
- "type": "string"
- }
- },
- "required": [
- "user_id",
- "plan",
- "tier",
- "is_entitled",
- "balance",
- "next_reset",
- "max_download_multiplier",
- "formats",
- "upgrade_url"
- ],
- "type": "object"
- },
- {
- "additionalProperties": {},
- "properties": {
- "code": {
- "type": "string"
- },
- "message": {
- "type": "string"
- }
- },
- "required": [
- "code",
- "message"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "balance": {
+ "additionalProperties": false,
+ "properties": {
+ "free": {
+ "type": "number"
+ },
+ "purchased": {
+ "type": "number"
+ },
+ "subscription": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "free",
+ "subscription",
+ "purchased"
+ ],
+ "type": "object"
+ },
+ "formats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "is_entitled": {
+ "type": "boolean"
+ },
+ "max_download_multiplier": {
+ "type": "number"
+ },
+ "next_reset": {
+ "additionalProperties": false,
+ "properties": {
+ "free": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "subscription": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "free",
+ "subscription"
+ ],
+ "type": "object"
+ },
+ "plan": {
+ "type": "string"
+ },
+ "tier": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "upgrade_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "plan",
+ "tier",
+ "is_entitled",
+ "balance",
+ "next_reset",
+ "max_download_multiplier",
+ "formats",
+ "upgrade_url"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+ }
+]create_videodownload_imagefind_similar_imagesgenerate_imageget_accountget_imageget_jobget_license_infolist_modelsresize_imagesearch_imagesupscale_imageSearch, organize, and publish AI-generated images and video with provenance and lineage.
Image search for AI agents: 1.85M openly licensed images with source, license and attribution.
Generate, edit, and explore AI images. Flux, Imagen, LoRA identity swap, upscale, and more.
Search 497,000+ public domain paintings, prints and drawings from 72 museums, with museum records.
Add one secure layer between your agents and this server.