Time of Meeting

Create a meeting link

create_meeting_link

Read-only

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. The calendar file is https://timeofmeeting.com/c?q=. Use this after find_best_meeting_time, or when the time is already known.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`link`	Yes
`error`	No
`items`	Yes
`local`	Yes
`start`	Yes
`title`	Yes
`cities`	Yes
`candidates`	No
`same_day_window`	Yes
`duration_minutes`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "candidates": {
+      "items": {
+        "properties": {
+          "country": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "id": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": "string"
+          },
+          "region": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "cities": {
+      "items": {
+        "properties": {
+          "country": {
+            "type": "string"
+          },
+          "kind": {
+            "type": "string"
+          },
+          "link": {
+            "type": "string"
+          },
+          "local": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "offset": {
+            "type": "string"
+          },
+          "region": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "weekend": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "zone": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "zone",
+          "local",
+          "offset",
+          "kind",
+          "link"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "duration_minutes": {
+      "type": "integer"
+    },
+    "error": {
+      "type": "string"
+    },
+    "items": {
+      "items": {
+        "properties": {
+          "description": {
+            "type": "string"
+          },
+          "format": {
+            "enum": [
+              "link",
+              "text",
+              "ics",
+              "google",
+              "qr"
+            ],
+            "type": "string"
+          },
+          "mime_type": {
+            "type": "string"
+          },
+          "text": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "format",
+          "description"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "link": {
+      "type": "string"
+    },
+    "local": {
+      "items": {
+        "properties": {
+          "kind": {
+            "type": "string"
+          },
+          "local_end": {
+            "type": "string"
+          },
+          "local_start": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "weekend": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "name",
+          "local_start",
+          "local_end",
+          "kind",
+          "weekend"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "same_day_window": {
+      "type": "string"
+    },
+    "start": {
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "link",
+    "items",
+    "start",
+    "title",
+    "duration_minutes",
+    "cities",
+    "local",
+    "same_day_window"
+  ],
+  "type": "object"
+}

First observedOct 17, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral detail beyond that: the planner link is always the first returned item, formats are appended in a fixed order, qr is opt-in, and the calendar file is served from https://timeofmeeting.com/c?q=. That is useful disclosure of return composition.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is well front-loaded, but the middle sentence is a long enumeration of the four formats that duplicates the schema verbatim, and the calendar-file URL sentence is a fragment awkwardly placed mid-paragraph. Several sentences do not earn their place given the 100% schema coverage.

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?

An output schema exists, so the description did not need to narrate return values, yet it does so partially (link ordering) rather than completely. For a five-parameter read-only link builder with full schema coverage, nothing critical to correct invocation 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%, so the schema already documents every parameter including formats ordering, defaults, and duration constraints. The description mostly restates these ('duration_minutes... same choices as the planner Duration control', 'title is optional... e.g. Weekly sync'), adding only marginal meaning, which lands at the baseline 3.

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?

States a specific verb and artifact: 'Build the invitation for one chosen slot,' and immediately scopes it to the planner link plus optional formats. An agent can distinguish it from find_best_meeting_time (which picks the slot) 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes usage: 'Use this after find_best_meeting_time, or when the time is already known,' naming the sibling and the precondition. It stops short of stating when *not* to use it or what to do if the slot is still undecided beyond the implied routing.

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

All Time of Meeting 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?