Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@when2meet-mcp Fill this when2meet poll from my Google Calendar and skip mornings before 10"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that reads and fills when2meet scheduling polls over plain HTTP — no browser automation, no OAuth.
Built for use with Cursor, Claude Desktop, or any MCP client. Pair it with a calendar MCP to auto-mark your availability from Google Calendar, Outlook, or a weekly class schedule.
Paste a when2meet link and ask your agent:
Fill this poll from my calendar — skip mornings before 10
The server will:
Load the poll — slot grid, participants, local time range
Compute free slots from busy blocks (weekly schedule or ISO calendar intervals)
Preview (dry_run=true by default)
Submit a positional availability bitmask to when2meet
Related MCP server: Meeting Scheduler
when2meet has no public API, but the participant UI uses three simple POST endpoints:
Endpoint | Purpose |
| Read slot grid + group availability |
| Sign in with name (+ optional password) → person ID |
| Write full |
This MCP wraps those calls with validation, timezone handling, and safety defaults.
Python 3.11+
Network access to when2meet.com
git clone <repo-url>
cd when2meet-mcp
pip install -e .Optional dev dependencies:
pip install pytest
pytestAdd to ~/.cursor/mcp.json (or Claude Desktop config). Set cwd to wherever you cloned the repo:
{
"mcpServers": {
"when2meet": {
"command": "python3",
"args": ["-m", "when2meet_mcp.server"],
"cwd": "/Users/jasoncharwin/Projects/when2meet-mcp",
"env": {
"WHEN2MEET_AGENT_NAME": "Composer"
}
}
}
}WHEN2MEET_AGENT_NAME is the label used when submitting under an alternate name (e.g. Jason Charwin (Composer) when the main entry has a password). Set it to Claude, GPT-4, Gemini, etc. Defaults to Cursor.
See mcp.json.example for a copy-paste template.
Tool | Description |
| Poll metadata, participants, time range, inferred week start |
| Fill from recurring |
| Fill from ISO calendar busy intervals + optional all-day dates |
| Validate slot indices before submitting |
| Sign in and save availability |
| Find overlapping free times across participants |
No calendar API needed — match by weekday + local time from poll labels:
fill_from_weekly_schedule(
url="https://www.when2meet.com/?12345678-AbCdE",
name="Alex Kim",
on_name_conflict="alternate_suffix",
busy_blocks=[
{"day": "Monday", "start": "09:00", "end": "10:15"},
{"day": "Monday", "start": "10:30", "end": "15:00"},
{"day": "Wednesday", "start": "09:00", "end": "10:15"},
],
buffer_minutes=5,
block_before="10:00",
dry_run=true
)1. get_poll(url)
2. [calendar MCP] → busy_times as ISO intervals
3. compute_availability_from_busy_times(
url=url,
busy_times=[{"start": "2026-03-09T14:00:00-04:00", "end": "2026-03-09T15:00:00-04:00"}],
all_day_dates=["2026-03-10"],
buffer_minutes=5,
)
4. submit_availability(url, name, slot_indices, dry_run=true)
5. submit_availability(..., dry_run=false, password="...")Wrong password on existing name → on_name_conflict="alternate_suffix" submits as Name (Agent)
15-minute slot boundaries → overlap-based matching
Buffer time → buffer_minutes expands busy blocks
Daily limits → block_before / block_after
All-day events → all_day_dates
Accidental submit → dry_run=true default on write tools
Invalid slot indices → validated with warnings
Full positional bitmask → always sends complete 0/1 string (required by when2meet)
Unmarked participants → excluded from overlap by default
when2meet's HTTP interface is undocumented and may change
Cannot delete participant rows via API (only clear availability)
Poll grid does not expose absolute calendar dates on the participant page
Event times are stored in UTC; evening slots may be outside the grid in your local timezone
Password-protected participant names require the user to provide the password
when2meet-mcp/
├── when2meet_mcp/
│ ├── client.py # HTTP client + poll parsing
│ ├── scheduling.py # Slot matching, validation, warnings
│ ├── auth.py # Login + password fallback
│ ├── agent.py # Agent name attribution
│ └── server.py # MCP tool definitions
├── tests/
├── pyproject.toml
└── mcp.json.examplepython3 -m when2meet_mcp.serverMIT — see LICENSE.
This project is not affiliated with when2meet. It uses reverse-engineered HTTP endpoints for personal automation. Use responsibly.
Compute free slots from ISO calendar busy intervals.
Args: url: when2meet poll URL busy_times: List of {start, end} ISO-8601 datetimes when busy timezone: IANA timezone for comparisons week_start_date: Date of column 0 (YYYY-MM-DD). Inferred from today if omitted. all_day_dates: Optional list of YYYY-MM-DD all-day busy dates buffer_minutes: Expand busy intervals by this many minutes block_before: Daily cutoff like "10:00" block_after: Daily cutoff like "18:00"
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timezone | No | America/New_York | |
| busy_times | Yes | ||
| block_after | No | ||
| block_before | No | ||
| all_day_dates | No | ||
| buffer_minutes | No | ||
| week_start_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does convey that this is a computation ('Compute free slots') and explains key transformations like buffer expansion and daily cutoffs. However, it does not state whether the url is fetched over the network, whether the operation is read-only, or what side effects, if any, occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose statement followed by a tight argument list with no filler. Every line conveys necessary information for invoking the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a computation-focused tool, the description covers the core purpose and all parameter semantics, and the presence of an output schema means return values need not be described. It is slightly incomplete only in usage guidance and behavioral side-effect disclosure, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by documenting all eight parameters with types and meanings. It clarifies the ISO-8601 shape of busy_times, the IANA timezone default, the week_start_date inference behavior, all-day dates, buffer_minutes, and daily cutoffs. This exceeds what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: 'Compute free slots from ISO calendar busy intervals.' It also provides a parameter list that reinforces the function's scope. However, it does not explicitly distinguish itself from siblings like find_common_availability or preview_availability, leaving some differentiation to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over its siblings. There is no mention of alternatives, exclusions, or the specific scenario where computing availability from busy times is preferable to finding common availability or previewing availability. The usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill a poll from recurring weekly busy blocks (best for class schedules).
Matches by weekday + local time from poll labels — no week_start_date needed.
Args: url: when2meet poll URL name: Your name on the poll busy_blocks: List of {day, start, end} e.g. {"day":"Monday","start":"09:00","end":"10:15"} timezone: IANA timezone for slot labels password: Per-event password if returning to an existing name buffer_minutes: Expand each busy block by this many minutes before/after block_before: Daily cutoff like "10:00" — treat earlier slots as busy block_after: Daily cutoff like "18:00" — treat later slots as busy dry_run: Preview only (default true for safety) on_name_conflict: error | alternate_suffix | create_new agent_name: Model label for alternate name, e.g. Claude (default: WHEN2MEET_AGENT_NAME env)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| name | Yes | ||
| dry_run | No | ||
| password | No | ||
| timezone | No | America/New_York | |
| agent_name | No | ||
| block_after | No | ||
| busy_blocks | Yes | ||
| block_before | No | ||
| buffer_minutes | No | ||
| on_name_conflict | No | error |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses dry_run default true for safety, on_name_conflict resolution modes, password requirement when returning to an existing name, and expansion/blocking semantics for buffer_minutes, block_efore, and block_after. It could add more about side effects on repeated calls, but key behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a concise summary line, a key matching note, and a flat args list. Every line adds information needed to invoke the tool correctly; no filler or repetition. Despite length, it earns its space for an 11-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, schema-poor, annotation-free tool, the description is nearly complete: it covers matching logic, all parameters, safety default, and conflict handling. Minor gaps remain around edge cases (e.g., overlapping busy blocks, exact suffix format for alternate_suffix), but an output schema exists and the essential invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry all parameter meaning. It does: all 11 parameters are individually explained with types, defaults, examples, and special values (e.g. on_name_conflict options, buffer, block_cutoffs, agent_name defaulting to env var). This exceeds what the sparse schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Fill a poll from recurring weekly busy blocks' and adds a clear use case ('best for class schedules'). It also distinguishes itself by noting it matches by weekday + local time and needs no week_start_date, cementing its unique role among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly scopes usage to recurring weekly busy blocks and class schedules, and explains the matching mechanism (weekday + local time) rather than dates. It doesn't explicitly name sibling tools as alternatives or list when-not-o-use conditions, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find times when participants overlap.
Args: url: when2meet poll URL timezone: IANA timezone for slot labels participant_names: Optional subset of names min_participants: Minimum number of people free (default: all selected) only_marked_participants: Exclude participants who have not marked any slots
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timezone | No | America/New_York | |
| min_participants | No | ||
| participant_names | No | ||
| only_marked_participants | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects, input requirements, and operational behavior. It only lists parameters and a terse summary, without stating that it reads a poll, what happens with invalid URLs, or any mutation/read-only guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-line summary followed by a bullet-style Args list with no filler. Each parameter line adds distinct information, and the structure is scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The parameter semantics are well covered and an output schema exists, so the agent can understand the return shape. However, the lack of usage guidance and behavioral disclosure (e.g., that this reads a third-party poll, or how failures are handled) leaves meaningful gaps for a tool with five parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args block explains all five parameters with meaningful semantics: URL is the when2meet poll, timezone is IANA for slot labels, participant_names is an optional subset, min_participants controls the threshold, and only_marked_participants excludes unmarked users. This goes well beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair ('Find times when participants overlap') and identifies the when2meet poll context. It is clear, but it does not explicitly differentiate from sibling tools like compute_availability_from_busy_times, which could also produce availability overlaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over the listed siblings, and no exclusions or prerequisites are stated. The only implicit signal is the 'when2meet poll URL' parameter, which suggests the input context but does not say when this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a when2meet poll: title, participants, time range, and optional slot grid.
Args: url: Full when2meet URL, e.g. https://www.when2meet.com/?38093485-OZAlv timezone: IANA timezone for slot labels (e.g. America/New_York) include_slots: If true, include all slot indices (can be 300+ entries)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timezone | No | America/New_York | |
| include_slots | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It does warn that include_slots can return hundreds of entries and clarifies timezone affects labels, but it doesn't explicitly state that this is a read-only network fetch or describe failure behavior for invalid URLs/polls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A one-line summary is followed by a compact Args block with no redundant prose. Every sentence carries useful information, including the scale warning about slot indices.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and all three parameters documented, the description is functionally sufficient to call the tool correctly. It lacks only a brief relationship note to sibling tools and explicit error/network caveats, which keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section compensates fully: url gets a concrete example, timezone gets an IANA example, and include_slots explains the large-output consequence. This adds real meaning beyond the JSON schema's bare property names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific verb (load) and resource (when2meet poll) and lists the returned data: title, participants, time range, and optional slot grid. This clearly differs from sibling tools that compute or submit availability, so an agent can distinguish it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence states when to call get_poll versus siblings like find_common_availability or preview_availability, nor any prerequisite or exclusion. The only usage signal is the implied retrieval role, which is not enough guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate slot indices and preview availability before submitting.
Args: url: when2meet poll URL slot_indices: Zero-based indices to mark available timezone: IANA timezone for labels
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timezone | No | America/New_York | |
| slot_indices | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the action validates and previews rather than submits, which implies no mutation, but it does not explicitly state that no poll changes are made or describe invalid-index error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence purpose is front-loaded and the Args bullets are minimal and informative. The arg list duplicates schema names but is warranted because the schema has no field descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param preview tool with an output schema, it covers purpose and all parameter semantics. It is less complete on routing: no explicit relation to submit_availability and no explicit statement that it does not modify the poll, which matters given there are no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the Args block adds valuable meaning: 'Zero-based indices' disambiguates slot_indices, and 'IANA timezone for labels' explains timezone's role. url's meaning is obvious from its name and context but is still included.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pair: validate slot indices and preview availability, and the 'before submitting' clause distinguishes it from the sibling submit_availability. It could be stronger by explicitly naming that sibling, but the intended operation is recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'before submitting' gives an implied usage context: call this as a dry-run ahead of submission. It does not name any alternative tools or state when not to use it, so an agent must infer routing from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign in and mark availability on a when2meet poll.
Args: url: when2meet poll URL name: Your name as it should appear on the poll slot_indices: Zero-based slot indices to mark available password: Per-event password for returning participants timezone: IANA timezone used when loading the poll dry_run: Preview only (default true for safety) on_name_conflict: error | alternate_suffix — when password fails for existing name agent_name: Model label for alternate name, e.g. Claude (default: WHEN2MEET_AGENT_NAME env)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| name | Yes | ||
| dry_run | No | ||
| password | No | ||
| timezone | No | America/New_York | |
| agent_name | No | ||
| slot_indices | Yes | ||
| on_name_conflict | No | error |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the safe default with 'dry_run: Preview only (default true for safety)', explains name-conflict behavior, and notes password and timezone handling. It could be more explicit about permanent effects when dry_run is false, but the safety default and conflict behavior are valuable disclosures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured as a one-line purpose followed by a compact argument list. Each parameter gets a single useful line, and no filler or redundant prose softens the value. The safety rationale for dry_run is the only extra detail and it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no annotations and zero schema coverage, this description is remarkably complete. It explains all parameters, relevant defaults, conflict handling, and safety behavior. The presence of an output schema means return values do not need to be described here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. Every parameter is explained in useful terms: 'Zero-based slot indices', 'IANA timezone', 'when password fails for existing name', and the meaning of on_name_conflict values. This far exceeds the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb-resource pair: 'Sign in and mark availability on a when2meet poll.' This clearly distinguishes it from sibling tools like get_poll, preview_availability, and find_common_availability, which have different purposes. The additional argument documentation reinforces the operational scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening sentence provides clear context: the tool is for marking availability, so an agent can infer when to use it. It does not explicitly name sibling alternatives or state when not to use it, but the purpose is unambiguous enough that the use case is recognizable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct phase: read poll, analyze group overlap, compute/fill from busy times, preview, and submit. The two busy-time tools are differentiated by weekly recurring vs one-off ISO inputs, but their names alone could still cause some confusion.
Most tools follow a clear verb_noun snake_case pattern like get_poll, submit_availability, and preview_availability. The longer names fill_from_weekly_schedule and compute_availability_from_busy_times deviate by adding prepositional phrases, making the pattern slightly inconsistent.
Six tools cover reading, analysis, two input modes, preview, and submission without redundancy or bloat. This is a well-scoped and focused set for a when2meet MCP server.
The set covers the main workflow: load a poll, find availability, compute personal availability, preview, and submit. Obvious gaps like creating a poll or explicitly clearing existing availability are absent, but they may be outside the intended URL-driven scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-first meeting schedule polls for humans and agents. Create polls, vote, find times.
Free no-signup group scheduling (a modern When2meet): share one link, find a time for everyone.
Group scheduling: create a plan link, mark availability, get best times, lock the final time.
Merged free/busy, find mutual time, propose bookings with human approval. Never event contents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Thespaceblade/when2meet-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
