Fair meeting times across time zones: find the overlap, convert times, make calendar links.
Scored across 6 tools
Each tool has a fairly distinct role, and descriptions explicitly map the workflow (search_cities → current/convert → find_best_meeting_time → create_meeting_link). The closest pair is convert_time vs find_best_meeting_time, but the descriptions clarify that one converts a known time while the other proposes candidate slots.
All names are lowercase snake_case and most follow a verb_noun pattern (convert_time, search_cities, create_meeting_link, find_best_meeting_time). The main deviation is dst_changes, a noun phrase with no verb, which is a minor inconsistency.
Six tools is well-scoped for a timezone/meeting-planning server, with each tool covering a clear capability (lookup, conversion, DST info, slot proposal, link generation). No redundant or trivial tools appear.
The surface covers the full meeting-planning lifecycle: finding cities, checking current/offset times, converting times, listing DST changes, proposing fair slots, and generating invitation links. Minor gaps exist (e.g., no explicit way to list supported time zones or manage saved cities), but core workflows are fully covered.
Convert one city's local time into one or more other cities. The result includes a https://timeofmeeting.com link for a 60-minute meeting. Choose a different length with create_meeting_link.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Cities to convert into. An array, or one comma-separated string. City name or a city id from search_cities. Spelling and accents are flexible. | |
| from | Yes | The city the clock time belongs to. City name or a city id from search_cities. Spelling and accents are flexible. | |
| time | Yes | Local time in the from city, YYYY-MM-DD HH:MM or YYYY-MM-DDTHH:MM. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the result includes a timeofmeeting.com link tied to a 60-minute meeting, which is not derivable from any structured field and is important since no output schema exists.
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?
Two sentences, zero waste, with the core conversion behavior front-loaded ahead of the sibling routing note. Every sentence 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?
Covers purpose, one key output artifact, and the sibling alternative, which is adequate for a simple 3-parameter read tool. It omits how multiple destination cities are returned and how DST is handled, but with a rich schema and simple semantics those gaps are minor.
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 100%, so from/to/time semantics (city name or id, accepted time formats, flexible spelling) are already fully documented in the schema. The description adds no parameter-level detail beyond that, which is the expected baseline when the schema does the heavy lifting.
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?
States a specific verb (convert) and resource (local time) with scope (one city into one or more others). An agent can distinguish this from search_cities or dst_changes without opening a schema.
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?
Explicitly routes the agent to create_meeting_link when a meeting length other than 60 minutes is needed, which is real when-to-use guidance. It stops short of distinguishing itself from find_best_meeting_time or current_time_in_cities, so no full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build the invitation for one chosen slot. duration_minutes is the meeting length, chosen now, with the same choices as the planner Duration control. title is an optional meeting name, e.g. Weekly sync. The first item is always the planner link: open this meeting on timeofmeeting.com (see and adjust it in the planner). formats then adds text to paste into a chat or email, a calendar file for Outlook, Apple Calendar and most calendar apps, an add-to-Google-Calendar link, or a QR code image someone can scan with a phone, in that order. Use this after find_best_meeting_time, or when the time is already known.
| Name | Required | Description | Default |
|---|---|---|---|
| start | Yes | ISO time with Z or an offset, or a local time in the first city (YYYY-MM-DD HH:MM). | |
| title | No | Optional meeting name, e.g. Weekly sync. It is the calendar event name and the first line of the text. When omitted, the invitation stays as it is now. | |
| cities | Yes | Two to eight cities. An array, or one comma-separated string. City name or a city id from search_cities. Spelling and accents are flexible. | |
| formats | No | Extras after the planner link, which is always included: open this meeting on timeofmeeting.com (see and adjust it in the planner). Returned in this order: text (text to paste into a chat or email), ics (calendar file for Outlook, Apple Calendar and most calendar apps), google (add-to-Google-Calendar link), qr (QR code image someone can scan with a phone). Default when omitted: ["text", "ics", "google"]. An empty array returns the planner link only. qr is included only when requested. | |
| duration_minutes | No | Meeting length in minutes, chosen when the invitation is made. Same choices as the planner Duration control: 15, 30, 45, 60, 90, 120, or any whole number from 5 to 1440 in steps of 5. Default 30. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real behavioral detail beyond that: the return is ordered with the planner link always first, formats are appended in a fixed order, and qr is only included when requested. This is useful output-shape disclosure, though it is largely restated from the schema rather than new.
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?
Purpose and the routing hint are front-loaded, but the sentence enumerating the four formats repeats the schema's enum descriptions almost verbatim ('text to paste into a chat or email, a calendar file for Outlook...'), which is duplication rather than added meaning. The paragraph is denser than it needs to be for the information it uniquely contributes.
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 no output schema, the description does explain what comes back (planner link first, then requested extras) and the default format set, which is what an agent needs after the call. Coverage is adequate for a 5-parameter, two-required, primitive-only tool with annotations already declaring its safety profile.
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 100%, so the schema already documents start, title, cities, formats and duration_minutes in detail. The description paraphrases the same facts ('duration_minutes is the meeting length... title is an optional meeting name') without adding syntax, constraints or format expectations beyond what the schema carries. Baseline 3 is appropriate.
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?
States a specific verb and resource ('Build the invitation for one chosen slot') and immediately distinguishes itself from the sibling that produces the slot, find_best_meeting_time. An agent can tell what artifact this produces (a planner link plus optional extras) without opening the schema.
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?
Explicitly routes the agent: 'Use this after find_best_meeting_time, or when the time is already known.' That covers both the dependent and independent branches, naming the sibling and the condition that selects this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current local time, offset, and work-hour band for each city. The result includes a https://timeofmeeting.com link.
| Name | Required | Description | Default |
|---|---|---|---|
| cities | Yes | One to eight cities. An array, or one comma-separated string. City name or a city id from search_cities. Spelling and accents are flexible. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds real behavioral context by disclosing the return payload: local time, offset, work-hour band, and an embedded https://timeofmeeting.com link. It doesn't cover ordering or error behavior for invalid city names, but it goes meaningfully beyond the annotations.
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?
Two short sentences, front-loaded with the core purpose. The second sentence about the meeting link is somewhat peripheral but still informational, so it doesn't feel wasteful enough to drop below a 4.
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 no output schema, the description must carry the return-value story, and it does outline the key fields (time, offset, work-hour band, link). Minor gaps remain around ordering, error handling for unresolvable cities, and what exactly a 'work-hour band' means.
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 coverage is 100%, so the schema already documents the single 'cities' parameter, including array/string flexibility and id support. The description only echoes the plural 'for each city' without adding format or limit detail, so the baseline 3 applies.
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?
Specific verb ('Show') plus resource ('current local time, offset, and work-hour band for each city') clearly states what the tool returns. It does not, however, differentiate itself from siblings like convert_time or find_best_meeting_time, so an agent must infer the boundary.
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 when-to-use guidance, no exclusions, and no mention of alternatives such as convert_time (converting a time) or find_best_meeting_time (finding a slot). Usage is only implied by the tool name and the word 'current'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List clock changes for one city. Defaults to the next year. Each change includes a https://timeofmeeting.com link. The range can be at most 366 days.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name or a city id from search_cities. Spelling and accents are flexible. | |
| end_date | No | Last day, YYYY-MM-DD. Defaults to 365 days later. | |
| start_date | No | First day, YYYY-MM-DD. Defaults to today (UTC). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real behavioral context beyond them: the default window is the next year, the range is capped at 366 days, and each result carries a timeofmeeting.com link.
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?
Three short sentences, zero filler, with the core action and scope front-loaded before the defaults and range limit. Every sentence carries distinct information.
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 no output schema, the description helpfully notes that each change includes a link, and it covers defaults and the range cap for a 3-parameter tool. It is largely complete, missing only return structure detail (fields per change) and any routing guidance to sibling tools.
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 100%, so city, start_date, and end_date are already fully documented, making 3 the baseline. The description restates the default window but adds no syntax or format detail beyond the schema, and its 'next year' phrasing slightly diverges from the schema's '365 days later'.
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?
States a specific verb and resource ('List clock changes') scoped to 'one city', which cleanly separates it from siblings like convert_time, current_time_in_cities, and search_cities. An agent can identify the tool's function without opening the schema.
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 gives useful operating context (defaults to next year, 366-day max range) but never states when to choose this tool over alternatives such as convert_time or find_best_meeting_time, nor any exclusions. Usage is only implied by the DST-specific scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose up to three fair meeting times while the slot is still being chosen. Ranking does not take a meeting length. Each slot has a score and the reasons. The result has one https://timeofmeeting.com link that opens the planner with those cities, and next_step, which says the user can choose a duration when creating the invitation. It does not include calendar files or a QR code. After a slot is chosen, call create_meeting_link.
| Name | Required | Description | Default |
|---|---|---|---|
| cities | Yes | Two to eight cities. An array, or one comma-separated string. City name or a city id from search_cities. Spelling and accents are flexible. | |
| end_date | No | Last day, YYYY-MM-DD. Defaults to six days after the start. At most 31 days. | |
| start_date | No | First day, YYYY-MM-DD. Defaults to today (UTC). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint false, closed-world), and the description adds substantial context beyond them: the ranking ignores meeting length, each slot returns a score plus reasons, and the result carries one planner link and a next_step. It also discloses what is NOT returned (calendar files, QR code), which preempts wrong expectations. No mention of permissions or error behavior, so not a full 5.
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?
Front-loads what the tool produces, then the output shape, then the routing instruction. Sentences are short and each carries information; the prose is slightly choppy ('Ranking does not take a meeting length') but nothing is padding.
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 no output schema, the description must sketch the return value, and it does: up to three scored slots with reasons, one timeofmeeting.com link, a next_step, and explicit exclusions. Combined with 100% schema coverage on the three inputs, an agent has enough to call it and interpret the result.
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 100% — cities (2-8, flexible spelling/ids) and both date bounds with defaults and the 31-day cap are fully documented in the schema. The description only adds the fact that ranking takes no meeting length, which clarifies the absence of a duration parameter but does not enrich the existing parameters.
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?
States a specific verb and resource ('propose up to three fair meeting times') and pins its lifecycle stage with 'while the slot is still being chosen.' This cleanly separates it from create_meeting_link, which the description says to call only after a slot is chosen.
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?
Gives both the when ('while the slot is still being chosen') and the explicit handoff ('After a slot is chosen, call create_meeting_link'), naming the sibling tool to route to. An agent knows exactly where this tool sits in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find cities by name. Each city includes its id, time zone, country, and a https://timeofmeeting.com link.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | City name, such as Bern or Zürich. Spelling and accents are flexible. A city id such as gn:2657896 is also accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. With no output schema, the description adds value by disclosing the returned payload (id, time zone, country, meeting link), but it says nothing about result limits, ranking, or exact-vs-fuzzy matching 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?
Two short sentences, purpose first, return payload second, with zero filler. Appropriately sized for a one-parameter lookup 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 simple read-only search with full parameter documentation and no output schema, the description covers what it does and what comes back. Only the result-set behavior (matching breadth, ordering, limits) is left unstated, which is a minor gap.
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 100% and the single parameter already documents flexible spelling, accents, and id acceptance, so the baseline is 3. The description's 'by name' framing actually undersells the schema's id-input capability and adds no syntax detail of its own.
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?
States a specific verb+resource ('Find cities by name') and enumerates the returned fields, so the agent knows this is a city-resolution lookup. It does not explicitly differentiate itself from siblings like current_time_in_cities or convert_time, which also take city inputs, leaving the boundary slightly implicit.
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 when-to-use guidance and no mention of the obvious composition pattern (resolving a city id/name before calling convert_time, dst_changes, or find_best_meeting_time). Usage is only implied by the verb 'Find'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
convert_timecreate_meeting_linkcurrent_time_in_citiesdst_changesfind_best_meeting_timesearch_citiesTime zone conversion, meeting-slot finding across countries, DST checks and .ics invites. All.
Find meeting times that overlap working hours across IANA time zones, DST-aware. Free tier.
Find a time a group can meet: no-login availability poll that picks the best meeting slot.
Merged free/busy, find mutual time, propose bookings with human approval. Never event contents.
Add one secure layer between your agents and this server.
