Zaps

Turn your photos into finished designs

create_designs

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.

Input Schema

Name	Required	Description
`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.

Output Schema

Name	Required	Description	Default
`note`	No
`upsell`	No
`options`	Yes
`matchedBy`	No
`remaining`	No
`requested`	No
`entitlement`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Zaps 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.