Panda Greetings

Find card designs

find_card_designs

Read-onlyIdempotent

Use this when the user asks Panda Greetings to write a card message or to make a card, or wants card designs: write the message first (if they asked for one), then call this with it so it comes back inside real Panda Greetings designs for the occasion. Returns up to four designs, as a printed card or a printed card their whole team signs from one link, each opening on pandagreetings.com with the message inside, ready to edit and order; Panda Greetings prints the card and mails it in the US. Always include the designs' links in your reply. The answer says when a card ordered today arrives; if they need it by a date, say whether it makes it and with which shipping. To draw a brand-new design instead, use make_card_design. Do not use it for e-cards, gift cards, flowers or other gifts, or for a text or chat message that isn't a card.

Input Schema

TableJSON Schema

Name	Required	Description
`message`	No	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.
`occasion`	Yes	What 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_group`	No	True when several people will sign it, such as a team card for a coworker or a class card for a teacher.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No
`group`	Yes
`price`	Yes
`status`	No
`arrival`	No
`designs`	Yes
`product`	Yes
`occasion`	Yes
`messageIncluded`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 4, 2026

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"
+}

First observedOct 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, but the description adds substantial behavior the annotations cannot convey: up to four designs returned, two card variants (single printed card vs. one-link group signing), designs open on pandagreetings.com with the message embedded and are editable/orderable, US printing and mailing, and that the response states arrival date and shipping for date-sensitive requests. It also imposes a reply obligation ('Always include the designs' links in your reply').

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 trigger condition and dense with actionable detail; each sentence carries distinct information (trigger, ordering, return shape, output obligation, alternative, exclusions). It is long and somewhat run-on with semicolon chains, which costs a point, but there is little pure 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 tool with an output schema, the description need not explain return values, yet it still covers the operational essentials: ordering of calls, the alternative tool, excluded use cases, and the required reply behavior. An agent has everything needed to select and invoke it correctly.

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 the baseline is 3, but the description adds real meaning beyond the schema: the message must be drafted before this call and passed so it appears inside the returned designs, and the group-signing behavior clarifies what from_group triggers. It does not restate syntax, so it is above baseline rather than merely adequate.

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+resource (find card designs for an occasion), names the exact trigger ('user asks Panda Greetings to write a card message or to make a card'), and explicitly contrasts with the sibling make_card_design. An agent can distinguish it from make_card_design and make_card_from_image 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?

Gives the when (user wants a card message/design), the sequencing ('write the message first... then call this with it'), the alternative ('To draw a brand-new design instead, use make_card_design'), and explicit exclusions (e-cards, gift cards, flowers, non-card text/chat messages). Nothing is left to inference.

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

All Panda Greetings 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?