Skip to main content
Glama

Find card designs

find_card_designs
Read-onlyIdempotent

Finds ready-made Panda Greetings printed card designs for an occasion, for when the user wants a greeting card or card designs from Panda Greetings, such as a farewell card a team signs or a birthday card for their mom. Takes the occasion, whether several people will sign it, and the card message if there is one, which is placed inside each design. Returns up to four designs, each with a link that opens it on pandagreetings.com with the message inside, ready to edit and order as a printed card, or as a printed card a whole team signs from one link; Panda Greetings prints it and mails it in the US. Also returns the day a card ordered today would arrive with free Standard and with Priority shipping. It doesn't cover e-cards, gift cards, flowers or other gifts, or a text or chat message that isn't a card.

Input Schema

NameRequiredDescriptionDefault
messageNoThe card message the user wrote or approved, as it goes inside the card: a greeting and a sign-off with the names if known, else [Recipient] and [Your Name], which are filled in when they order. Leave it out if there isn't one yet.
occasionYesWhat the card is for. Pick the closest match; for a holiday, its own name (christmas, hanukkah, valentines-day…), and holiday only when no other fits.
from_groupNoTrue when several people will sign it, such as a team card for a coworker or a class card for a teacher.

Output Schema

NameRequiredDescriptionDefault
noteNo
groupYes
priceYes
statusNo
arrivalNo
designsYes
productYes
occasionYes
rememberNo
messageIncludedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / remember
      Added value: +{
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / message / description
      Previous value: -"The card message the user wrote or approved, to put inside the card. Leave it out if there isn't one yet."New value: +"The card message the user wrote or approved, as it goes inside the card: a greeting and a sign-off with the names if known, else [Recipient] and [Your Name], which are filled in when they order. Leave it out if there isn't one yet."
    • addedOutput schema / properties / arrival
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "orderedToday": {
      +      "type": "string"
      +    },
      +    "priority": {
      +      "type": "string"
      +    },
      +    "standard": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "orderedToday",
      +    "standard",
      +    "priority"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safe-read profile (readOnly, idempotent, closed-world); the description goes well beyond that by disclosing the result cap (up to four designs), the per-design link behavior, the one-link team-signing mode, the fact that Panda Greetings prints and mails in the US only, and that shipping-arrival dates for free Standard and Priority are returned. These are operational constraints an agent could not derive from the annotations or schema.

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 core purpose and target user are front-loaded in the first clause, and every subsequent sentence adds scope, exclusions or delivery behavior. It is dense and runs long in a single paragraph, with mild repetition of 'Panda Greetings', but no sentence is filler.

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?

For a three-parameter lookup with an output schema already covering return shape, the description supplies the remaining context an agent needs: the occasion/message/group semantics, the four-design cap, the ordering and mailing model, the US-only constraint, and the exclusions. Nothing material 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 description coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it clarifies that the message is placed inside each design and that the boolean flag means several people will sign it. It maps all three parameters to user-facing intent rather than merely restating field names.

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 verb (Finds) and resource (ready-made Panda Greetings printed card designs) scoped to an occasion, and immediately bounds the domain by excluding e-cards, gift cards, flowers and non-card messages. An agent can tell exactly what this tool returns without opening the 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?

Gives an explicit use condition (when the user wants a greeting card or card designs from Panda Greetings) with concrete examples (farewell card a team signs, birthday card for mom), and an explicit when-not list (e-cards, gift cards, flowers, other gifts, plain text/chat messages). Nothing is left to inference even though there are no sibling tools to route to.

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