Skip to main content
Glama

GiftsToPrint

by com.giftstoprint
OverviewDiscussionsAdmin

Server Details

Order personalised newspaper-style birthday, anniversary and retirement posters as print files.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 24 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.5/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct role in the poster ordering workflow: search, form details, photo upload link, photo storage, and checkout creation. The only potential overlap is upload_photo and get_photo_upload_link, but their descriptions unambiguously separate the cases where each should be used.

Naming Consistency5/5

All tool names use snake_case with a leading verb (create, find, get, upload) and consistently describe the action and object. The pattern is predictable throughout, even when extra nouns are included for clarity.

Tool Count5/5

Five tools are exactly the right scope for a focused personalised poster ordering flow. Each tool earns its place with no redundancy or missing step in the core journey.

Completeness5/5

The tool set covers the full lifecycle an agent needs: discover posters, collect required details, handle photo upload in all common scenarios, and create a checkout for payment. No obvious gaps exist for the stated purpose of assisting with a poster purchase.

Available Tools

5 tools
create_poster_checkoutCreate the personalised checkoutAInspect

Validate every detail and create a Shopify checkout for one personalised poster with all the details attached. Returns checkout_url. Nothing is charged: open checkout_url for the user to review the order and pay on GiftsToPrint's own checkout. Before calling, read the details back to the user, including the photo_url so they can check it is the right photo, and confirm they understand they will receive a digital file to print (set confirm_digital_file to true). If a field is wrong, the error lists every problem at once so you can fix them in one go.

ParametersJSON Schema
NameRequiredDescriptionDefault
buyerYes
handleYesThe poster's handle, from find_posters.
photo_urlYesThe photo_url returned by upload_photo.
turnaroundYesstandard: ready the next working day, order Mon-Fri. rush_weekday: ready within 12 hours, order Mon-Fri. rush_weekend: ready within 24 hours, order Sat or Sun.
instructionsNoOptional note to the designers, e.g. how to crop the photo.
buyer_countryNoOptional ISO country code, so checkout opens in the buyer's currency.
personalisationYesThe fields from get_poster_form, keyed by their id (e.g. recipient_first_name, birth_day, birth_month).
confirm_digital_fileYesMust be true: the buyer understands the poster is a digital file to print, not a physical print.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only cover the generic safety profile (write, open-world, non-idempotent, non-destructive). The description adds materially: nothing is charged at this step, the user reviews and pays on GiftsToPrint's own checkout, and validation errors are returned all-at-once so they can be fixed in a single pass. These are non-obvious behavioral traits an agent could not infer from structured fields.

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-loads purpose and return value, then prerequisites, then error behavior. Sentences are dense but each carries distinct information; no obvious filler. Slightly long for the content, keeping it below a 5.

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?

With no output schema, the description supplies the key return value (checkout_url) and the follow-up action (open it for the user). For a write tool with annotations covering safety, the mixture of preconditions, consent requirement, non-charging behavior, and error semantics makes it complete enough to call correctly.

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

Parameters3/5

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

Schema coverage is 88%, so the schema already documents nearly every parameter, including the enumeration for turnaround and the semantics of personalisation. The description reinforces confirm_digital_file and the photo_url step but adds little syntax or format detail beyond what the schema provides, so the baseline 3 is appropriate.

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 ('Validate every detail and create a Shopify checkout for one personalised poster') and names the artifact returned ('checkout_url'). It is clearly distinguishable from siblings find_posters, get_poster_form, and upload_photo, which are inputs to this action rather than alternatives.

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?

Gives explicit preconditions for invocation: read details back to the user, verify photo_url is the right photo, and obtain consent by setting confirm_digital_file to true. It also ties inputs to their sibling tools (handle from find_posters, photo_url from upload_photo). It does not state when NOT to use the tool, so it falls short of a full 5.

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

find_postersFind a posterA
Read-onlyIdempotent
Inspect

Search GiftsToPrint's personalised newspaper-style posters. Each poster shows real headlines and events from one year, personalised with a name, photo and message, and is delivered as a print-ready digital file (nothing is posted). Birthday posters and wedding-anniversary posters exist per milestone and edition (e.g. 60th Birthday, Australian edition, 1966); retirement and dating-anniversary posters cover any year, chosen in the form. Pick the edition by where the recipient lives or grew up (US, UK, Canada or Australia). Returns each matching poster's handle, prices and product page. Next step: get_poster_form.

ParametersJSON Schema
NameRequiredDescriptionDefault
yearNoThe year the poster should cover (birth year, or wedding year).
editionNoCountry edition: which country's news the poster shows.
occasionNoWhat the poster celebrates.
milestoneNoThe birthday or anniversary number, e.g. 60 for a 60th.
buyer_countryNoOptional ISO country code of the buyer (e.g. "US", "AU") to show prices in their currency.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is already covered. The description adds valuable domain behavior beyond that: what a poster contains (headlines from one year, personalisation fields), that it's digital-only ('nothing is posted'), and the shape of the return value (handle, prices, product page).

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-loads the product definition, then packs occasion/edition rules and the next-step call into a compact block. Three sentences of dense but non-redundant prose; slightly could be trimmed but every sentence carries information.

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 a 5-param, zero-required search tool with no output schema, the description covers what the tool returns (handle, prices, product page), the delivery model, and the follow-up tool. It omits explicit pagination/limit behavior and whether all params are optional, but the coverage is strong enough for an agent to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so each parameter (year, edition, occasion, milestone, buyer_country) is already documented. The description adds domain context around editions ('pick by where the recipient lives or grew up') and which occasions are milestone-driven, but does not add parameter-level syntax beyond what the schema provides. Baseline 3 is appropriate.

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 (search) and resource (personalised newspaper-style posters) with unusual precision: it explains the product, its delivery form ('print-ready digital file, nothing is posted'), and explicitly names the next step tool get_poster_form. An agent can distinguish this from get_poster_form and create_poster_checkout without opening a schema.

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?

Gives clear context: use this to find posters by year, occasion/milestone, and edition, and directs the agent to get_poster_form as the next step. It doesn't explicitly state when NOT to use it versus upload_photo or get_photo_upload_link, but for a product-catalog search tool the routing is sufficiently clear.

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

get_poster_formGet the details a poster needsA
Read-onlyIdempotent
Inspect

List exactly what to collect from the user for one poster: names, dates, optional message, and the photo, plus the turnaround options and prices. Ask the user for anything you don't already know. Don't invent names or dates. Next step: upload_photo, then create_poster_checkout.

ParametersJSON Schema
NameRequiredDescriptionDefault
handleYesThe poster's handle, from find_posters.
buyer_countryNoOptional ISO country code of the buyer, for local prices.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description goes beyond them with concrete behavioral rules for the agent: prompt the user for missing data, never fabricate names or dates, and follow the upload/checkout sequence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the payload of what to collect, followed by behavioral guardrails and the next-step handoff. Every sentence carries distinct information with no filler.

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 a read-only, two-parameter, no-output-schema tool, the description covers what the call yields (the collection requirements plus turnaround and pricing options) and where it fits in the workflow. It stops short of describing the shape or ordering of the returned list, but nothing essential for correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters (handle from find_posters, optional buyer_country for local prices). The description mentions prices and turnaround options, loosely echoing buyer_country's purpose, but adds no syntax or mapping detail beyond the schema, so the baseline 3 applies.

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: it lists exactly what must be collected from the user for one poster (names, dates, optional message, photo, turnaround options, prices). It is clearly distinguishable from siblings like find_posters or create_poster_checkout because it is framed as the requirements-gathering step that precedes them.

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 routes the agent explicitly: 'Next step: upload_photo, then create_poster_checkout,' and tells the agent to ask the user for anything unknown and not invent names or dates. That is clear context plus sequencing, though it never states a case where this tool should not be called.

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

upload_photoUpload the photo for the posterAInspect

Store the photo that will be printed on the poster, and return the photo_url to pass to create_poster_checkout. Only use a photo the user has given in THIS conversation. Never reuse a photo or link from memory or an earlier conversation, and never use a product or poster image. If the user hasn't given a photo yet, ask them for one instead of calling this. Give exactly one of: photo (a file the user attached in this chat), image_url (a public https link to the image), image_base64, or upload_id (from get_photo_upload_link, once the user says they've uploaded). If you can't send the user's photo any of these ways, call get_photo_upload_link instead of asking the user for a link. JPEG, PNG or WebP, up to 20MB. Photos are kept for 12 months so the poster can be made and revised, then deleted automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
photoNoA photo the user attached in this chat (ChatGPT file reference).
image_urlNoPublic https:// address of the image.
upload_idNoThe upload_id from get_photo_upload_link, after the user has uploaded on that page.
image_base64NoThe image file encoded as base64 (a data: URL prefix is fine).

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare the write/open-world/non-idempotent profile; the description supplies the operational detail beyond that — accepted formats (JPEG/PNG/WebP), 20MB cap, and the 12-month retention/deletion policy. That data-lifecycle disclosure is exactly what annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Opens with what it does and the return value, then layers constraints and the fallback path. Every sentence carries a distinct rule (source restriction, exclusivity, format limits, retention); nothing is padding.

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?

No output schema exists, yet the description states the return value (photo_url) and which sibling consumes it, closes the input-exclusivity question, and covers the no-photo-pending branch. Nothing an agent needs to call this correctly 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 the baseline is 3, but the description adds a genuinely new constraint the schema cannot express: exactly one of photo/image_url/image_base64/upload_id, plus the precondition that upload_id must come from get_photo_upload_link after the user uploads. It does not restate the per-parameter meanings, which the schema already covers.

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 and resource ('Store the photo that will be printed on the poster') and explicitly names the downstream sibling create_poster_checkout as the consumer of the returned photo_url. An agent can separate this from get_photo_upload_link and the other poster tools without inspecting schemas.

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 explicit when-to-use, when-not-to-use, and an alternative: only photos from THIS conversation, never reuse from memory or earlier chats, never product/poster images, ask the user instead if no photo, and call get_photo_upload_link when the photo can't be sent directly. This is a full routing decision tree.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updates
    • Addedget_photo_upload_link
    • Changedupload_photo3 fields changed
      • addedInput schema / $defs
        Added value: +{
+  "OpenAIFile": {
+    "additionalProperties": false,
+    "properties": {
+      "download_url": {
+        "type": "string"
+      },
+      "file_id": {
+        "type": "string"
+      },
+      "file_name": {
+        "type": "string"
+      },
+      "mime_type": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "download_url",
+      "file_id"
+    ],
+    "type": "object"
+  }
+}
      • addedInput schema / properties / photo
        Added value: +{
+  "$ref": "#/$defs/OpenAIFile",
+  "description": "A photo the user attached in this chat (ChatGPT file reference)."
+}
      • addedInput schema / properties / upload_id
        Added value: +{
+  "description": "The upload_id from get_photo_upload_link, after the user has uploaded on that page.",
+  "pattern": "^[0-9a-f]{32}$",
+  "type": "string"
+}
  2. 4 tool updates
    • First observedcreate_poster_checkout
    • First observedfind_posters
    • First observedget_poster_form
    • First observedupload_photo

Related MCP Connectors

Related MCP Servers

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