StockCake

Search StockCake Images

search_images

Read-onlyIdempotent

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 available for this query. Start with a short query; when total_results is small or off-target, retry with fewer keywords or different phrasing.

Input Schema

TableJSON Schema

Name	Required	Description
`mood`	No	Exact facet value — pick one from refinements.mood of a previous search_images result
`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
`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.

Output Schema

TableJSON Schema

Name	Required	Description
`page`	Yes
`results`	Yes
`has_more`	Yes
`refinements`	No	Exact mood/style facet values available for this query — pass one back as `mood` / `style` to narrow
`total_pages`	Yes
`license_note`	Yes
`total_results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 28, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description usefully adds that total_results spans the whole catalog rather than the page, and that refinements enumerates valid mood/style facet values for the query — behavior not visible in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three front-loaded sentences with no filler; the catalog-scope clarification and refinement strategy come first. Slightly terse on the retry triggers but every sentence earns its place.

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

Completeness4/5

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

With an output schema present the description needn't restate return values, and it correctly clarifies the one ambiguous field (total_results scope). For a 12-parameter tool with a required conversation_id handshake documented in-schema, coverage is adequate.

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

Parameters3/5

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

Schema description coverage is 83%, so the schema already documents most parameters, including mood/style refinements, query length, limit and the conversation_id protocol. The description's query-refinement advice largely echoes the query field's own description, adding little beyond the schema baseline.

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

Purpose4/5

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

The first sentence states a specific verb (search) and resource (StockCake image catalog) with the natural-language modality. It doesn't distinguish itself from the close sibling find_similar_images, but the purpose itself is unambiguous.

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

Usage Guidelines4/5

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

It gives concrete query-refinement strategy ('start short; when total_results is small or off-target, retry with fewer keywords or different phrasing'), which is real operational guidance. It does not, however, say when to prefer this over find_similar_images or generate_image.

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

All StockCake tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?