meetergo MCP server

Official

by meetergo

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Book an appointment

book_appointment

Destructive

Create a confirmed appointment from an available meeting slot and send calendar invitations to the attendee and guests. Requires a valid start, meeting type, and attendee email.

Instructions

Create a real appointment for a start present in the meeting type availability results and send invitations. An unlisted start is rejected. A confirmed bookingState means the appointment exists; pending_confirmation means it is not booked yet. Either fullName or both firstName and lastName are required.

Input Schema

TableJSON Schema

Name	Required	Description
`email`	Yes	Attendee email
`notes`	No	Answers to the booking form, keyed by question label, e.g. {"What do you want to discuss?": "Pricing"}
`phone`	No
`start`	Yes	Slot start returned by an availability query
`hostIds`	No	Only to pin a round-robin type to specific hosts. Left out, the meeting type decides.
`queueId`	No	Rarely needed — resolved from the meeting type by default.
`duration`	No	Length in minutes. Required only when the availability query used a duration override; otherwise the meeting type decides.
`fullName`	No	Use when the name cannot be split reliably
`lastName`	No
`timezone`	No	IANA timezone of the attendee, e.g. Europe/Berlin
`firstName`	No
`guestEmails`	No	Additional attendees invited alongside the main one (max 5)
`meetingTypeId`	Yes
`receiveReminders`	No	Send the attendee reminder emails. Defaults to true.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	appointmentId (confirmed only)
`message`	No	What still has to happen (pending only)
`startUtc`	No	The booked start, ISO 8601 UTC (confirmed only)
`bookingType`	No
`bookingState`	No	confirmed means the appointment exists; pending_confirmation means it does NOT yet
`provisionalBookingId`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed17 schema fields changedv0.6.25Aug 28, 2026

addedInput schema / properties / duration

Added value: +{
+  "description": "Length in minutes. Required only when the availability query used a duration override; otherwise the meeting type decides.",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / firstName
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / fullName

Added value: +{
+  "description": "Use when the name cannot be split reliably",
+  "type": "string"
+}

addedInput schema / properties / guestEmails

Added value: +{
+  "description": "Additional attendees invited alongside the main one (max 5)",
+  "items": {
+    "format": "email",
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

addedInput schema / properties / hostIds

Added value: +{
+  "description": "Only to pin a round-robin type to specific hosts. Left out, the meeting type decides.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / lastName
```
Added value: +{
+  "type": "string"
+}
```

removedInput schema / properties / name

Removed value: -{
-  "description": "Attendee full name",
-  "type": "string"
-}

addedInput schema / properties / notes / additionalProperties
```
Added value: +{
+  "type": "string"
+}
```

changedInput schema / properties / notes / description

Previous value: -"Context for the host"New value: +"Answers to the booking form, keyed by question label, e.g. {\"What do you want to discuss?\": \"Pricing\"}"

changedInput schema / properties / notes / type

Previous value: -"string"New value: +"object"

addedInput schema / properties / phone
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / queueId

Added value: +{
+  "description": "Rarely needed — resolved from the meeting type by default.",
+  "type": "string"
+}

addedInput schema / properties / receiveReminders

Added value: +{
+  "description": "Send the attendee reminder emails. Defaults to true.",
+  "type": "boolean"
+}

changedInput schema / properties / start / description

Previous value: -"Slot start, from get_availability"New value: +"Slot start returned by an availability query"

addedInput schema / properties / timezone / description

Added value: +"IANA timezone of the attendee, e.g. Europe/Berlin"

changedInput schema / required

Previous value: -[
-  "meetingTypeId",
-  "start",
-  "name",
-  "email"
-]New value: +[
+  "meetingTypeId",
+  "start",
+  "email"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "description": "Outcome of the booking attempt",
+  "properties": {
+    "bookingState": {
+      "anyOf": [
+        {
+          "enum": [
+            "confirmed",
+            "pending_confirmation"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "confirmed means the appointment exists; pending_confirmation means it does NOT yet"
+    },
+    "bookingType": {
+      "$ref": "#/properties/provisionalBookingId"
+    },
+    "id": {
+      "$ref": "#/properties/startUtc",
+      "description": "appointmentId (confirmed only)"
+    },
+    "message": {
+      "$ref": "#/properties/startUtc",
+      "description": "What still has to happen (pending only)"
+    },
+    "provisionalBookingId": {
+      "$ref": "#/properties/startUtc"
+    },
+    "startUtc": {
+      "description": "The booked start, ISO 8601 UTC (confirmed only)",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedv0.1.1Jul 29, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond annotations (not read-only, destructive), the description discloses concrete side effects and state semantics: it creates a real appointment, sends invitations, rejects invalid starts, and clarifies that pending_confirmation means the appointment is not booked. This is exactly the behavioral context an agent needs.

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

Conciseness5/5

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

Four short sentences, each earning its place: core action, validation rule, result-state interpretation, and a required-field condition. The most important purpose is front-loaded, with no filler.

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?

For a 14-parameter mutation with an output schema and annotations, the description covers the essential operational caveats: availability-sourced starts, rejection of invalid starts, ambiguity between confirmed and pending states, and mandatory attendee name input. Nothing critical is left to guesswork.

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?

With 71% schema coverage, the description adds meaningful cross-parameter logic that the schema cannot express: the start must come from availability results, and fullName can substitute for firstName plus lastName. It does not re-explain every parameter, but it compensates for the key conditional requirements.

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 opens with a specific action ('Create a real appointment') on a clear resource (an appointment for an availability start) and explicitly says it sends invitations. It also differentiates from scheduling-adjacent siblings by tying booking to availability results and noting unlisted starts are rejected.

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?

It clearly indicates when to use the tool: only for starts present in meeting type availability results, with an unlisted start rejected. It does not explicitly name alternatives like reschedule_appointment or create_one_time_booking_link, so it falls just short of full routing guidance.

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

Install Server

Other Tools

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/meetergo/meetergo-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server