Photos and a brief in, finished social-media designs out. First design free, no account.
Scored across 4 tools
create_designs is explicitly a superset of search_templates + fill_template ('there is no need to call search_templates and fill_template yourself'), so three of the four tools occupy overlapping search/render territory. The descriptions do supply clear guidance on when to pick the composite vs. the primitives, which keeps it workable, but the boundaries are not cleanly disjoint.
All four tools follow a uniform verb_noun snake_case pattern (create_designs, fill_template, search_templates, upload_images). No mixing of conventions or vague bare verbs.
Four tools is lean but each maps to a distinct step in the design pipeline (search, render, composite, upload). It is on the thin side for the apparent scope, and collapsing search+render into create_designs means fewer, larger tools rather than a gap.
The core workflow — get local photos in, find templates, render designs — is covered end to end, including a publicUrl handoff between upload_images and the render tools. There is no way to list, edit, or delete prior designs, but editing is offloaded to a browser link, so remaining gaps are minor.
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?
Annotations declare readOnlyHint=false and destructiveHint=false, so the write/non-safe profile is already known; the description adds real context beyond that: a per-design token cost, the template-preference behavior ("Templates that hold every photo you supplied are preferred, so pass all of them"), and the photos-vs-images routing rule. It does not cover failure modes or what happens if no template matches, which keeps it short of 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?
Purpose and the workflow are front-loaded in the first sentence, and each subsequent sentence carries usable information (alternative routing, photo preference, image-source split, token cost). It is a dense single paragraph rather than a structured list, which slightly hurts skimmability but not substance.
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 6-parameter, one-required, output-schema-backed tool, the description covers purpose, alternatives, cost, and the trickiest routing decision (two mutually exclusive photo sources). Return values are deferred to the output schema appropriately; the only omission is what the tool does when no suitable template is found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the prose adds meaning on top of the schema: it clarifies the photos-vs-images split ("Photos attached in the conversation go in `photos`; photos already on the web go in `images`") and reinforces the requirement to pass all photos for better template matching. It adds routing logic rather than restating types.
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 compound verb+resource: searches templates, renders each with supplied photos and copy, and returns several finished designs. It explicitly positions itself against siblings, saying it is "search and render together, so there is no need to call search_templates and fill_template yourself," so an agent can distinguish it 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?
Gives an explicit selection condition ("Use this when someone wants options") and names the two alternatives it replaces (search_templates, fill_template). It also adds a budget guideline — "Each returned design spends one agentic token" — which lets an agent decide how many designs to request.
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?
Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower, yet the description still adds real behavioral context: 'Each render spends one agentic token,' which is a cost/consumption fact an agent needs before calling. It also explains that slot placement follows array order, a side-effect an agent must reason about.
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 paragraph that leads with the action and output before explaining ordering and the photos/images split. Every sentence carries information, though the ordering rule is stated twice within the paragraph, which is slightly redundant.
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-value documentation is not required, and the description covers inputs, the photos/images choice, ordering, and per-call token cost. The only gap is failure behavior — what happens on an invalid template id or unreachable URL — which is minor given the structured coverage.
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 all three parameters, including 'in placement order' for both arrays and the 'Use this OR images, not both' constraint. The description's parameter information largely restates that, adding no new syntax or format detail, so the baseline 3 is correct.
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 concrete verb and resource — 'Render a finished image' — and ties it to its input source ('a template id from search_templates') and its output ('returns the rendered design'). It cleanly separates this from search_templates, but never distinguishes it from the sibling create_designs, which is the most likely confusion point.
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 clear operational context: obtain coverId from search_templates, pass photos in the order they should appear, and it encodes the selection rule between the two input arrays ('Photos attached in the conversation go in `photos`; photos already on the web go in `images`'). No exclusions are stated — nothing says when to prefer create_designs instead — so it stops 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.
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_imagesWorld-class creative social media content studio, powered by AI.
Create, schedule, and publish on-brand social posts to Instagram, LinkedIn, TikTok, and more.
On-brand product photos, model try-ons, video reels & banners from a brief + brand kit.
On-brand carousels, captions and scheduled posts for Instagram, LinkedIn and TikTok.
Add one secure layer between your agents and this server.
