Photos and a brief in, finished social-media designs out. First design free, no account.
Scored across 4 tools
create_designs intentionally overlaps with search_templates + fill_template, but its description explicitly says it composes both so the agent needn't call them. The remaining boundary (search for options vs. fill a known template id vs. upload local photos) is clearly drawn. Only mild residual ambiguity about when to prefer the composite over the two-step path.
All four names follow a clean verb_noun snake_case pattern: create_designs, fill_template, search_templates, upload_images. The only nit is plural vs. singular nouns, which does not impair predictability.
Four tools is tight and well-scoped for a template-design service: find, fill, composite, and asset upload. Each earns its place with no filler or redundant utility tools.
Covers the full workflow: search templates, upload local assets, render a known template, and get multiple finished options in one call. Missing pieces like design history or re-editing are handled by returned edit links, so there are no real dead ends.
The whole job in one call: give it a SEARCH QUERY you have written, your photo URLs and the words you want on the design, and it finds templates that fit, renders each with your photos and your copy, and returns several finished designs to choose between. Use this when someone wants options — it is search and render together, so there is no need to call search_templates and fill_template yourself. Templates that hold every photo you supplied are preferred, so pass all of them. Photos attached in the conversation go in photos; photos already on the web go in images. Each returned design spends one agentic token.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The words to put ON the designs — headline first, then any supporting lines. WRITE THESE YOURSELF from the brief: a template ships with the designer's placeholder copy, and leaving it means a coffee shop opening goes out reading whatever they typed. Keep a headline to a few words; templates lay out short lines. | |
| brief | Yes | The SEARCH QUERY for the template catalogue — you write it, we do not build it from anything else. Title Case phrases separated by commas, the way the catalogue describes itself: "Birthday Party, Friends, Celebration, Confetti, Party Invite". Five or six covering occasion, subject and mood. Written this way it scores about 0.11 higher than the same intent as a sentence, and a single word is worst of all. If you were given photos, look at them and let what you see inform the phrases. | |
| count | No | How many finished designs to return. Default 5, at most 10. | |
| images | No | Publicly reachable image URLs, in placement order. | |
| photos | No | Photos the person attached in this conversation, in placement order. Use this OR images, not both. | |
| segment | No | Optional shape filter, e.g. story or carousel. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| upsell | No | |
| options | Yes | |
| matchedBy | No | |
| remaining | No | |
| requested | No | |
| entitlement | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: each returned design spends one agentic token (a cost signal), templates holding all photos are preferred, and photos vs. web images are separate channels. It does not cover failure modes or what happens when no template fits, so not 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?
Front-loaded with 'the whole job in one call' and then the mechanics; every sentence carries useful information. It is somewhat dense in the closing sentences, where the photos/images and token cost points are packed together.
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 shape need not be explained. For a composite, 6-parameter tool it covers the origin of the brief, photo channel choice, count limits, cost, and the sibling alternatives — nothing an agent needs is missing.
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 baseline is 3, but the description adds guidance the schema lacks: pass all photos because full-coverage templates are preferred, and images/photos are an OR-choice. It adds meaning rather than restating field definitions.
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 composite verb+resource: it searches templates, renders them with supplied photos and copy, and returns several finished designs. It explicitly distinguishes itself from search_templates and fill_template, so an agent can tell it apart from siblings 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?
Says explicitly when to use it ('when someone wants options') and why alternatives are unnecessary ('there is no need to call search_templates and fill_template yourself'). Both the condition and the excluded path are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a finished image: give it a template id from search_templates and the photo URLs to place, and it returns the rendered design. Photos are placed into the template's image slots in the order given, so pass them in the order you want them to appear. Photos attached in the conversation go in photos; photos already on the web go in images. Each render spends one agentic token.
| Name | Required | Description | Default |
|---|---|---|---|
| images | No | Publicly reachable image URLs, in placement order. | |
| photos | No | Photos the person attached in this conversation, in placement order. Use this OR images, not both. | |
| coverId | Yes | Template id, from a search_templates result. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| upsell | No | |
| options | Yes | |
| matchedBy | No | |
| remaining | No | |
| requested | No | |
| entitlement | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, openWorld=true, destructive=false), the description discloses two things the agent could not infer: placement is positional and order-sensitive, and each render consumes one agentic token — an important cost signal before calling. It stops short of saying whether renders are persisted, retrievable later, or reversible.
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 compact sentences, front-loaded with the action and result, then the ordering rule, then the param split, then the cost. Every clause carries information an agent needs; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description needn't detail return values, and it covers the workflow prerequisite, ordering semantics, and cost. The only gap is failure behavior — what happens if a URL is unreachable or a slot count doesn't match the photos supplied.
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 all three parameters are already documented, including the photos-vs-images exclusivity and ordering. The description restates that guidance in prose with slightly more vivid framing ('pass them in the order you want them to appear') but adds no new constraint, 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 opens with a specific verb and artifact ('Render a finished image') and explains the two inputs that produce it, so the operation is unambiguous. It references search_templates as the source of the id but does not explicitly distinguish this tool from create_designs or upload_images, which keeps it 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 gives concrete routing guidance: get the template id from search_templates, and choose `photos` for conversation attachments vs `images` for web URLs. What is missing is an explicit statement of when to use this instead of create_designs, or when a render is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find design templates. YOU write the query, and its wording decides the match: the catalogue describes each template as Title Case phrases separated by commas, and a query in that same register scores about 0.11 higher than the same intent written as a sentence. Write five or six phrases covering the occasion, the subject and the mood — "Coffee Shop, Cafe Vibes, Grand Opening, Latte Art, Cafe Aesthetic" rather than "grand opening of a neighbourhood coffee shop". A single word is worst of all. Returns templates with an id to fill and a link a person can open to keep editing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many templates to return. Default 5. | |
| query | Yes | Title Case phrases separated by commas, the way the catalogue describes itself. Five or six covering occasion, subject and mood. | |
| segment | No | Optional shape filter, e.g. story or carousel. |
| Name | Required | Description |
|---|---|---|
| templates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description goes beyond them by disclosing that query wording materially changes match quality (a stated scoring delta) and describing the return shape (id plus an editable link). Pagination or ordering behavior is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence and the rest is actionable guidance. The catalogue-register rule is stated once and then restated with two examples, so there is mild redundancy that could be tightened.
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 not be spelled out. Query composition is covered thoroughly; limit and segment are documented in the schema. The only real gap is the absence of routing guidance against the sibling 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 100%, so the baseline is 3. The description earns above baseline by adding rationale and a worked example for how the query string should be composed, which the schema merely asserts in one line. It adds little for limit or segment beyond what the schema states.
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?
A specific verb and resource ("Find design templates") plus a note that results carry an id to fill, which implicitly separates it from create_designs, fill_template and upload_images. It never names a sibling explicitly, so the differentiation is inferable 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is heavily focused on how to phrase the query, which is useful, but it gives no when-to-use/when-not guidance relative to fill_template or create_designs. Usage is implied by the search framing rather than explicitly scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this FIRST when the photos are on the caller's machine rather than already on the web — our renderer fetches over the network and cannot read a local path. Simplest way: read each file and pass it in files as base64; the reply gives you a publicUrl per photo to hand straight to create_designs, with nothing else to run. If you would rather upload the bytes yourself, pass count instead and you get presigned links to PUT to. Costs nothing either way.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Only when uploading the bytes yourself: how many links to mint. | |
| files | No | The photos themselves, base64 encoded. We store them and hand back a url each. Use this unless you have a reason not to. | |
| mimeType | No | The images' media type, e.g. image/png or image/jpeg. |
| Name | Required | Description |
|---|---|---|
| howTo | Yes | |
| slots | No | |
| imageUrls | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, openWorldHint=false and destructiveHint=false, so the safety profile is partly covered; the description adds the non-obvious constraint that the renderer cannot read local paths, that both paths are network-mediated, and that there is no cost. It does not say whether uploaded files persist, expire, or are scoped to a session, which is the main remaining behavioral unknown for a write tool.
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-loads the imperative 'Call this FIRST' and the reason, then walks the two paths in order of preference. Mostly tight, though 'Costs nothing either way' and the closing aside add little and could be trimmed.
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 elaboration beyond the useful mention of publicUrl. The description covers the trigger condition, both invocation modes, the cost expectation, and the downstream handoff to create_designs — everything an agent needs to call this 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 100%, so the baseline is 3, but the description adds real semantic value the schema does not: `files` and `count` are alternative modes rather than a combined payload, and each yields a different kind of answer (publicUrl per photo vs. presigned PUT links). That mutual-exclusivity explanation is exactly what prevents a malformed call.
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 concrete verb+resource (mint/get upload links for photos that live on the caller's machine) and immediately distinguishes itself from the rest of the toolset by naming create_designs as the downstream consumer. An agent can tell from the first sentence that this is the ingestion entry point, not a design-creation 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?
Gives the explicit trigger (photos on the local filesystem, not already on the web, because the renderer fetches over the network), then lays out both modes and when to pick each: base64 `files` by default, `count` only if you want to PUT the bytes yourself. The 'Use this unless you have a reason not to' default plus the named next step (create_designs) leaves nothing to inference.
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.
create_designsfill_templatesearch_templatesupload_imagesMake ad creatives, social media posts and banners from a brief. Editable designs you can reuse.
Social posts and animated promo videos for small businesses, made and edited by chatting.
Social media posts for small businesses from their own photos. Owner approves every post.
Turn a product photo into a finished ad image with copy, or get 10 ad headlines. Free, no signup.
Add one secure layer between your agents and this server.
