Skip to main content
Glama

Kartenbild erstellen (2 Entwürfe)

create_card_picture

Use this to make the picture for the front of a greeting card. Our picture tool makes 2 drafts, or 1 draft from photos. Each draft is shown as the printed card front. First ask the open questions of get_card_options brief, in one message. Give subjects with roles (an age only if the user gave it), never names. Give photos_decision in every call. Without it, the result is needs_answer: ask the user, then call again. Do not send health details or other sensitive details. Nothing is mailed or charged.

Input Schema

NameRequiredDescriptionDefault
styleNoOptional. A style id from get_card_options. Show the user the styles of get_card_options brief. The user chooses. Default: "loose-botanical-watercolour". With photo_design_id, use a style from get_card_options (picture_tool.photo_styles). Default then: "loose-watercolour-portrait".
wordsNoOptional. The exact words in the picture, for example "Happy 70th, Ruth". At most 40 characters. Use the words of the user. Without words, the picture has no text. No emojis. The card font cannot print them.
detailsYes1 to 3 personal details from the user for the motif: the place, the action, a hobby. For example: "her rose garden", "on a sled", "a village in the Alps". Ask the user. Do not invent details. Give who is in the picture in subjects.
languageNoGive the language of the conversation, for example en or de. The upload page and the order page use this language. Without it, the pages use the language of the account.
occasionNoOptional. The occasion: christmas, birthday, baby, thank-you, condolence, wedding, anniversary, get-well, housewarming, retirement, other. Default: "other".
subjectsNoWho and what the picture shows, at most 8. One entry for each person and each pet, not one for a group. Each: kind (person, pet, object or place) and role, for example "the mother", "a boy", "the family dog". age only if the user gave it, in any form ("15", "about 70"). photo: the number of the photo that shows it, in upload order. from_photo false: drawn without a photo. Never a name.
refine_ofNoFor other drafts of the same card: the brief_id of the earlier drafts.
scene_modeNoOnly with photos. "photo": repaint the one photo as it is, in the style. "new": put the people and pets into a new scene from details. Several single photos: "new".
style_sourceNoOptional. "user": the user chose the style. "proposed": you chose it, for example after "you decide".
photo_design_idNoOptional. The design_id of the user's photo upload. The user picks up to 5 photos at the upload link and ticks the one box. Then use a style from picture_tool.photo_styles.
photos_decisionNoRequired. The answer to the photo question. "uploaded": the user uploaded photos; give photo_design_id too. "declined": draw the people and pets without photos. "not_needed": the picture shows no real people and no pets.
photo_design_idsNoOptional. For one picture from 2 to 5 photos: the design_ids of the user's photos, in order. Each photo comes from an upload with the one box ticked. Do not give photo_design_id too.

Output Schema

NameRequiredDescriptionDefault
statusYes
next_stepYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / properties / details / description
      Previous value: -"1 to 3 personal details from the user for the motif. For example: \"Aunt Ruth loves her rose garden\", \"a beagle called Biscuit\", \"a village in the Alps\". Ask the user. Do not invent details."New value: +"1 to 3 personal details from the user for the motif: the place, the action, a hobby. For example: \"her rose garden\", \"on a sled\", \"a village in the Alps\". Ask the user. Do not invent details. Give who is in the picture in subjects."
    • addedInput schema / properties / photos_decision
      Added value: +{
      +  "description": "Required. The answer to the photo question. \"uploaded\": the user uploaded photos; give photo_design_id too. \"declined\": draw the people and pets without photos. \"not_needed\": the picture shows no real people and no pets.",
      +  "enum": [
      +    "uploaded",
      +    "declined",
      +    "not_needed"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / refine_of
      Added value: +{
      +  "description": "For other drafts of the same card: the brief_id of the earlier drafts.",
      +  "maxLength": 64,
      +  "type": "string"
      +}
    • addedInput schema / properties / scene_mode
      Added value: +{
      +  "description": "Only with photos. \"photo\": repaint the one photo as it is, in the style. \"new\": put the people and pets into a new scene from details. Several single photos: \"new\".",
      +  "enum": [
      +    "photo",
      +    "new"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / style / description
      Previous value: -"Optional. A style id from get_card_options. get_card_options lists the styles by family. Propose 2 styles from different families to the user. The user chooses. Default: \"loose-botanical-watercolour\". With photo_design_id, use a style from get_card_options (picture_tool.photo_styles). Default then: \"loose-watercolour-portrait\"."New value: +"Optional. A style id from get_card_options. Show the user the styles of get_card_options brief. The user chooses. Default: \"loose-botanical-watercolour\". With photo_design_id, use a style from get_card_options (picture_tool.photo_styles). Default then: \"loose-watercolour-portrait\"."
    • addedInput schema / properties / style_source
      Added value: +{
      +  "description": "Optional. \"user\": the user chose the style. \"proposed\": you chose it, for example after \"you decide\".",
      +  "enum": [
      +    "user",
      +    "proposed"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / subjects
      Added value: +{
      +  "description": "Who and what the picture shows, at most 8. One entry for each person and each pet, not one for a group. Each: kind (person, pet, object or place) and role, for example \"the mother\", \"a boy\", \"the family dog\". age only if the user gave it, in any form (\"15\", \"about 70\"). photo: the number of the photo that shows it, in upload order. from_photo false: drawn without a photo. Never a name.",
      +  "items": {
      +    "properties": {
      +      "age": {
      +        "maxLength": 30,
      +        "type": "string"
      +      },
      +      "from_photo": {
      +        "type": "boolean"
      +      },
      +      "kind": {
      +        "enum": [
      +          "person",
      +          "pet",
      +          "object",
      +          "place"
      +        ],
      +        "type": "string"
      +      },
      +      "photo": {
      +        "maximum": 5,
      +        "minimum": 1,
      +        "type": "integer"
      +      },
      +      "role": {
      +        "maxLength": 60,
      +        "minLength": 1,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "kind",
      +      "role"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 8,
      +  "type": "array"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

The annotations already declare a non-destructive, non-open-world, non-idempotent creation operation. The description adds useful behavior beyond that: it makes two drafts or one from photos, each draft is shown as the printed card front, a missing photos_decision returns needs_answer, and nothing is mailed or charged.

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?

The description is front-loaded with purpose and the key workflow. It is generally efficient, though it repeats draft-count and photo/style details that also appear in the schema.

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?

Given 12 parameters and an output schema, the description covers the critical preconditions, privacy restriction, and failure mode. It leaves detailed parameter workflows such as refine_of and scene_mode to the schema, which is acceptable because coverage is complete.

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 description coverage is 100%, so the baseline is 3. The description still adds important meaning for subjects (use roles, include age only if the user gave it, never names) and photos_decision (required in every call; its absence produces needs_answer), plus it routes style selection through get_card_options.

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?

The description states a specific verb and resource: make the picture for the front of a greeting card. It also clarifies the output form (2 drafts, or 1 draft from photos) and distinguishes itself from get_card_options by telling the agent to ask that tool's questions first.

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?

It gives clear workflow guidance: first ask the open questions of get_card_options in one message, always include photos_decision, and treat needs_answer as a signal to ask the user and call again. It does not explicitly compare this tool to prepare_card or send_card, so it stops short of full alternative guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources