Card Mailer

Design card

design_card

Destructive

Creates or edits a printed 5x7 postcard with a front greeting, optional photo, back message and sign-off. Downloads an attached photo or public HTTPS photo URL to cards.onmax.me. Without a photo, the greeting appears on a solid color. An existing design_id edits that design; omitted fields remain unchanged. The back message is user-written or user-approved text of up to 500 characters. Arranges supplied photos and text in a print template without generating images.

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": "design_card"
  }
}

Input Schema

Name	Required	Description
`photo`	No	Photo the user attached for the front.
`style`	No	classic (red), evergreen (green), winter (blue), minimal (white), thanks (warm, for thank-you cards).
`message`	No	Message printed on the back.
`greeting`	No	Front headline, e.g. "Happy Holidays", "Merry Christmas", "Thank You".
`sign_off`	No	Signature on the back, e.g. "Love, The Garcias".
`design_id`	No
`photo_url`	No	Public https URL of the front photo.
`remove_photo`	No

Output Schema

Name	Required	Description	Default
`kind`	Yes
`style`	Yes
`message`	Yes
`greeting`	Yes
`sign_off`	Yes
`design_id`	Yes
`has_photo`	Yes
`photo_warning`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedOct 22, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructive=true, idempotent=false and openWorld=true; the description adds real context on top: photos are downloaded from an attachment or public HTTPS URL into cards.onmax.me, and editing via design_id applies partial updates with omitted fields unchanged (which explains the non-idempotent hint). It does not say what happens to a previously uploaded photo when a new one is supplied, nor whether edits are reversible, which is the main remaining gap for a destructive tool.

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?

Six tight sentences, front-loaded with what is produced and followed by the operational details (photo fetching, edit semantics, text constraint). The final sentence restating that it arranges photos in a template without generating images is a slight redundancy with the opening, but overall there is little waste.

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 an 8-parameter, partially nested schema with an output schema present, the description covers the main invocation paths and the destructive edit behavior. It leaves remove_photo and the interaction between photo replacement and existing designs unexplained, which an agent would need when editing rather than creating.

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

Parameters5/5

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

With 75% schema coverage, the description still earns credit by explaining design_id's create-vs-edit and partial-update semantics, the photo/photo_url dual sourcing and the remote download destination, and the user-written/user-approved constraint on message that the schema does not capture. Only style and remove_photo are left to the schema, which handles them adequately.

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 description names a concrete verb and artifact – creating or editing a printed 5x7 postcard with front greeting, optional photo, back message and sign-off – and even bounds the scope negatively ("without generating images"). It is far more specific than the title, though it never references the mailing-oriented siblings (create_mailing, quote_mailing) to make the boundary explicit.

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

Usage Guidelines3/5

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

It gives useful conditional logic – supply design_id to edit an existing design, omit fields to leave them unchanged, and the fallback "without a photo, the greeting appears on a solid color" – but it never states when to use this tool versus a sibling like create_mailing or quote_mailing, nor any exclusions or prerequisites (e.g., that photo_url must be public HTTPS, which is only implied).

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

All Card Mailer 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?