Dayze — Life Context

Get Birthdays

get_birthdays

Read-only

Whose birthday is coming up or was just missed: the user's contacts with a birthday in a window (days_back before and days_ahead after today, 30 each, or from/to), in the account timezone. upcoming (days_until) and recent (days_since), soonest first then closest: birthday_on, age_turning (null when the year is unknown), birthday_precision, relationship, tier, is_favorite, last_in_touch, in_touch_since_birthday. Counts contacts without a birthday. Excludes Me, never-share and deceased contacts (include_deceased adds them as remembrance). ($0.05; API key required)

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

Input Schema

Name	Required	Description
`to`	No	Window end YYYY-MM-DD (instead of days_ahead). At most 366 days in all.
`from`	No	Window start YYYY-MM-DD (instead of days_back).
`limit`	No	Per list (default 25).
`days_back`	No	Days before today, for missed birthdays (default 30).
`days_ahead`	No	Days after today (default 30).
`include_deceased`	No	Add deceased contacts, marked remembrance (default false).

Output Schema

Name	Required	Description
`note`	No
`count`	Yes
`today`	No	Today in the account timezone (YYYY-MM-DD).
`recent`	No
`window`	No	{ from, to }: the inclusive civil window.
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`timezone`	No
`upcoming`	No
`truncated`	No
`without_day`	No	{ count, hint }: contacts with only a birth year or year and month.
`inspect_note`	No	How to cite: link each record with its inspect_url, never a link built from an id; which record types here have no Dayze page.
`recent_count`	No
`upcoming_count`	No
`remembrance_note`	No
`missing_birthdays`	No	{ count, hint }: contacts without a birthday in Dayze.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well past the readOnly/destructive/openWorld annotations: it discloses exclusion rules (Me, never-share, deceased), the sort order (soonest first, then closest), derived fields with null semantics (age_turning null when year unknown), a side output (count of contacts without a birthday), and the cost/auth requirement.

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 purpose and window before the field inventory, and every clause carries information. The middle section drifts into a dense comma-separated field dump with fragments like 'upcoming (days_until) and recent (days_since)', which is harder to parse than the opening.

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 reporting tool with a full output schema, the description covers windowing, exclusions, ordering, cost and auth, which is everything needed to call it correctly. The enumerated return fields partially duplicate the output schema, but they are annotated with derivation rules the schema would not convey.

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 genuine meaning on top: the default window is 30/30, from/to replaces days_back/days_ahead, and include_deceased changes exclusion behavior rather than merely filtering. It also clarifies the timezone basis for the window, which the schema never states.

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?

Opens with the concrete question it answers ('Whose birthday is coming up or was just missed') and then names the exact resource: the user's contacts with a birthday inside a bounded window, in the account timezone. There is no sibling birthday tool, and the scope (contacts, window semantics, exclusions) is unambiguous.

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 states the use case, gives the default window (30 days back / 30 ahead) and the alternative explicit from/to mode, and explains when include_deceased applies ('as remembrance'). It also flags prerequisites the agent needs before calling (API key required, $0.05 cost). It does not name a competing tool to route away from, but none exists in the sibling list.

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

All Dayze — Life Context 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.