SignUpSheet.page

Create date poll

create_date_poll

Creates a group scheduling poll on SignUpSheet.page: people open one link and answer yes, maybe or no for each date or time option, and the option that works for most people is highlighted. Returns the share link and the private organizer link, where the organizer can pick the final time and notify everyone who left an email. Use it when the user wants to find a date or time that works for a group, such as a meeting, dinner, reunion, parent night or study session. Not for sign-up slots or opinion polls without dates.

Input Schema

Name	Required	Description
`title`	Yes	e.g. 'Book club – November meeting'.
`options`	Yes	Date or date-and-time options to vote on. They are shown in date order.
`language`	No	Language of the pages and emails people will see. Use the language the user is writing in; 'en' if it is not in the list.
`timezone`	No	IANA time zone of the event, e.g. 'America/Chicago' or 'Europe/Madrid'. Needed when dates or times are given (reminders and calendar files use it).
`description`	No	Optional details (place, length). Plain text; web links are removed.
`organizer_name`	No	Name shown as the organizer, e.g. 'Dana'. Use the user's name if they gave it; otherwise omit.
`organizer_email`	No	Optional. Only an email address the user gave in this conversation. If set, both links are emailed to it so the private organizer link is not lost. Never guess an address.

Output Schema

Name	Required	Description
`kind`	Yes
`title`	Yes
`chip_in`	No
`language`	No
`timezone`	No
`warnings`	No
`flyer_url`	No	Printable QR-code flyer for the sheet.
`share_url`	Yes	Public link to send to participants.
`item_count`	No
`organizer_url`	No	Private management link for the person who asked. Left out only when a repeated request returns a sheet whose organizer link went to the organizer email (see organizer_url_note).
`emailed_links_to`	No	Masked address the links are being emailed to, or null.
`organizer_url_note`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare openWorldHint=true, idempotentHint=false, destructiveHint=false, so the description's added value is narrower: it discloses the two-link return contract (public share link vs private organizer link) and the downstream effect that the organizer can notify respondents by email. It does not say whether repeated calls create duplicate polls or how long links live, which keeps it below 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?

Four sentences, front-loaded with the action and mechanism before usage guidance and the exclusion. Slightly padded by the explanatory 'people open one link and answer...' clause, but every sentence contributes routing or behavioral information.

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 an output schema present, the description needn't document return shapes, and it still summarizes the key return (share link plus private organizer link). Annotations cover safety profile, schema covers all 7 parameters and limits, so nothing an agent needs to call correctly 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% and each parameter already carries its own constraints and examples, so the baseline is 3. The description adds no parameter-level detail beyond implying that options are dates/times and that organizer_email drives link delivery, which the schema already 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 a specific verb and resource ('Creates a group scheduling poll on SignUpSheet.page') and immediately describes the mechanism (yes/maybe/no per date, best option highlighted). The final sentence explicitly distinguishes it from the sibling sign-up-flow tooling by ruling out 'sign-up slots' and date-less opinion polls.

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 both inclusion criteria with concrete examples (meeting, dinner, reunion, parent night, study session) and an explicit exclusion ('Not for sign-up slots or opinion polls without dates'), which routes the agent to create_signup_sheet or another tool. This is the when/when-not pattern rather than implied usage.

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

All SignUpSheet.page 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?