meetwhen

create_event

Create a free, no-signup group-scheduling event (like When2meet) and get a shareable link. Give it candidate dates and a daily time window; it builds the availability grid. Send the returned url to everyone in the group — each person paints when they're free in their own timezone, and the best overlapping time surfaces automatically. Ideal when a user asks you to 'find a time' or 'set up a poll' for a meeting.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	'time' (default): find an overlapping hour within a daily window. 'day': a whole-day poll — respondents just mark which dates work, no time-of-day. Use 'day' when the user only needs to pick a date.
`dates`	Yes	Candidate dates as YYYY-MM-DD strings (1-21 days).
`title`	Yes	Event name, e.g. 'Team sync' or 'D&D night' (max 80 chars).
`timezone`	No	IANA timezone the hours are expressed in, e.g. 'America/New_York' (default UTC). Respondents still answer in their own local time.
`latest_hour`	No	Latest hour of day to consider, 1-24 (default 17). Must be greater than earliest_hour.
`slot_minutes`	No	Granularity of each time slot in minutes (default 30).
`earliest_hour`	No	Earliest hour of day to consider, 0-23 (default 9). Ignored when mode='day'.

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries full burden. It details the flow: give dates and time window, the system builds an availability grid, returns a URL, respondents mark availability in their own timezone, and the best time emerges. It also explains timezone and mode behaviors. No contradictions.

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 well-structured in two paragraphs, with a clear first sentence. It is slightly verbose but remains focused. Every sentence serves a purpose. Could be tightened, but it is easy to read and informative.

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?

Given the lack of output schema, the description adequately covers the return value as a 'shareable link' or 'returned url'. It explains the overall process, prerequisites (candidate dates and time window), and the outcome. It is complete for the tool's complexity.

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 description coverage is 100%, so baseline is 3. The description adds value by providing usage context for parameters (e.g., when to use 'day' mode vs 'time', default values for earliest_hour and latest_hour, and that respondents answer in their local time). It enhances understanding beyond the schema descriptions.

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 clearly states the tool creates a free, no-signup group-scheduling event similar to When2meet and provides a shareable link. It specifies the action (create), the resource (event), and the outcome (shareable link). The sibling tool get_event suggests retrieval, distinguishing this tool as creation.

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?

The description explicitly states it is 'ideal when a user asks you to find a time or set up a poll for a meeting,' providing clear usage context. It also differentiates between 'time' and 'day' modes. However, it does not explicitly state when not to use the tool or mention alternatives beyond the sibling.

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

All meetwhen tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

The two tools have clearly distinct purposes: create_event generates a new event, while get_event retrieves event details. No functional overlap exists.

Naming Consistency5/5

Both tools follow the consistent 'verb_noun' pattern (create_event, get_event), making them predictable and easy to use.

Tool Count3/5

With only 2 tools, the set feels minimal but not unreasonable for a simple polling service. It is on the low end of the typical 3-15 range.

Completeness4/5

The tools cover the core workflow of creating and viewing events, but lack update and delete functionality, which are minor gaps for a poll-like service.

Resources

Need Help?