Zovo Love Story Poster

Generate anniversary poster

generate_anniversary_poster

Read-onlyIdempotent

Use this when the user wants to know how many days they have been together, an "our story in numbers" or relationship stats poster, an anniversary gift printable, a days-together counter, or the date of a milestone such as "when is our 1,000th day", "our 100th day" or "500 weeks together". Pass start_date (first date, the day they met, wedding day) and, when given, start_time, time_zone, names and occasion (together, married, engaged, friends, family). Returns the days, weeks, months, years, hours, full moons, weekends, leap days and anniversaries, the next round milestones with dates, a printable poster PDF (Letter, A4, A3, 12x18 in) and an ICS file with those milestones. Does not invent dates: ask for the start date if it is missing. Does not accept future start dates or dates before 1900. Not for countdowns to a future event or for age calculations of a single person.

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

Input Schema

Name	Required	Description
`as_of`	No	Optional date to count to, e.g. "2026-12-25" for a gift given that day. Default: today.
`names`	No	Optional names printed as the poster headline, e.g. "Alex & Sam".
`theme`	No	Colour theme: blush (default), ivory, sage or midnight.
`title`	No	Optional small heading, e.g. "Our story in numbers" (default) or "Five years of us".
`occasion`	No	together (default), married, engaged, friends or family. Sets the wording, e.g. "1,000 days married".
`page_size`	No	Poster size: "Letter" (default), "A4", "A3" or "12x18" (inches). Portrait.
`time_zone`	No	Optional IANA time zone where it began, e.g. "America/Chicago" or "Europe/London". Makes hours count clock changes and dates full moons locally; also sets "today". Default: America/New_York for today, UTC for full moon dates.
`date_order`	No	Optional order for dates like 03/04/2019: "mdy" (US, default) or "dmy".
`milestones`	No	How many upcoming milestones to list and put in the calendar file, 1 to 20. Default 8.
`start_date`	No	The day the story began (first date, the day you met, wedding day), e.g. "2019-06-14" or "June 14, 2019". Must not be in the future.
`start_time`	No	Optional time of day it began, e.g. "19:30" or "7:30 pm". Used for the hours count; default midnight.
`count_first_day`	No	true to count the first day as day 1 (Korean couple style: the 100th day is start + 99 days). Default false: days elapsed, the 1,000-day mark is start + 1,000 days.
`reminder_days_before`	No	Days before each milestone for the calendar reminder (at 09:00), 0 to 60. Default 7.

Output Schema

Name	Required	Description	Default
`days`	Yes
`as_of`	Yes
`hours`	Yes
`names`	Yes
`theme`	Yes
`title`	Yes
`weeks`	Yes
`months`	Yes
`occasion`	Yes
`warnings`	Yes
`weekends`	Yes
`ymd_text`	Yes
`downloads`	Yes
`leap_days`	Yes
`page_size`	Yes
`time_zone`	Yes
`full_moons`	Yes
`hours_note`	Yes
`milestones`	Yes
`start_date`	Yes
`start_time`	Yes
`assumptions`	Yes
`as_of_source`	Yes
`anniversaries`	Yes
`start_weekday`	Yes
`next_full_moon`	Yes
`day_number_today`	Yes
`milestones_shown`	No
`next_anniversary`	Yes
`years_months_days`	Yes
`reminder_days_before`	Yes
`weeks_remainder_days`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish that this is a safe, read-only, idempotent, closed-world operation. The description adds useful behavioral constraints beyond the annotations: it refuses future start dates and dates before 1900, does not invent dates, and explains that it returns calculated stats, milestone dates, a printable PDF, and an ICS file. It does not discuss error handling or formatting limits in more detail, which keeps it from a 5.

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 the trigger conditions and then moves through inputs, outputs, and exclusions in a logical order. It is dense and longer than most tool descriptions, with some repeated milestone examples, but the length is largely justified by the tool's breadth.

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 complex 13-parameter tool with an output schema, the description covers the core intent, key inputs, validation constraints, exclusions, and returned artifact types. It does not highlight some secondary parameters, but the schema supplies those details, and the description is complete enough for correct invocation.

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 all 13 parameters thoroughly. The description highlights start_date, start_time, time_zone, names, and occasion with some meaningful context, but it omits several parameters such as as_of, theme, page_size, milestones, count_first_day, and reminder_days_before. With the schema doing the heavy lifting, 3 is the appropriate baseline.

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: generating an anniversary poster from relationship start dates, with concrete use cases like days-together counts, milestone dates, and printable gifts. It also distinguishes the tool from adjacent intents such as future-event countdowns and single-person age calculations.

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?

It gives explicit when-to-use guidance across common phrasings, including 'our story in numbers', anniversary printable, days-together counter, and milestone dates. It also states exclusions and the required behavior when start_date is missing, so the agent knows both when to call it and when not to.

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

All Zovo Love Story Poster 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?