Skip to main content
Glama
Sign In

Marsell

by com.getmarsell
OverviewDiscussionsAdmin

Make pictures

make_pictures

Makes pictures in the project's look, as many as asked, from an idea and/or products. Spends the owner's tokens at the price of the picture model they chose. Without confirm: true it only quotes the price; with it, it starts making them. They land in Create for the owner to keep. A picture of a real place, landmark or artwork is made from real photographs of it; when none can be trusted, it waits in Create for a photo from the owner instead of being invented. The owner is asked once per place, and Marsell looks again every ten minutes for free: once a photo of it arrives (get_upload_link, kind picture, captioned with the place), the waiting pictures are made from it. The business's own characters and places (get_brand lists them) are made from their own pictures, in the look the idea calls for, when the idea has them in it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "make_pictures"
  }
}

Input Schema

NameRequiredDescriptionDefault
ideaNoWhat the pictures show, in a sentence.
countNoHow many pictures, 1 or more; 2 when left out. The quote grows with it.
confirmNotrue to spend the tokens and make them; otherwise a quote.
projectNoThe project's id or exact name. Optional when the account has one project.
product_idsNoProducts to feature, by their ids in get_brand's products.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only say this is a non-read-only, non-destructive, closed-world tool; the description adds the substance an agent actually needs, chiefly that calling it spends the owner's tokens at their chosen model's price. It also discloses the two-phase quote/purchase behavior, where results land, and the asynchronous waiting state with its photo-upload trigger via get_upload_link. That is well beyond what the annotations cover.

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

Conciseness3/5

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

The core action and the confirm mechanic are front-loaded, which is correct. But the back half is one long run of clauses covering places, characters, polling intervals, and upload captions, and the final sentence about the business's own characters is hard to parse on first read.

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

Completeness4/5

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

For a costly, partly asynchronous generation tool with no output schema, the description covers the essentials: cost, gating flag, destination, and the deferred/photo-blocked path. What is missing is failure handling and how the agent should report the quoted price or the waiting state back to the owner.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description still adds real meaning: product_ids is tied back to get_brand's products, project is implied optional when the account has a single project, and confirm is reframed in terms of what actually happens rather than just its type. The idea and count semantics are mostly restated from the schema, which keeps it from a 5.

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 opening sentence gives a specific verb and resource ("Makes pictures") plus the source material ("from an idea and/or products") and the output location ("land in Create"). That is enough to separate it from an upload-style sibling, but it never names an alternative such as add_pictures, so the differentiation is inferred rather than stated.

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?

The confirm flag is framed as the decision point ("Without confirm: true it only quotes the price; with it, it starts making them"), and the real-place/landmark case spells out the prerequisite: a trusted photograph, otherwise the tool waits in Create. It also tells the agent the owner is asked once per place and that polling is free every ten minutes. It stops short of explicitly routing to picture_price for a standalone quote or to add_pictures for uploading existing images.

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

All Marsell toolsInspect
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