Skip to main content
Glama
meetergo

meetergo MCP server

Official
by meetergo

Get available slots

get_availability
Read-onlyIdempotent

Find bookable start times for a meeting type within a date range, using validated slots that booking accepts.

Instructions

Return a meeting type's bookable starts within a date range. The slotsStartUtc values are the starts accepted by booking validation; calendar events alone are not availability.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYesEnd of the search window
startYesStart of the search window
hostIdsNoOnly to narrow a round-robin type to specific hosts. Left out, the meeting type decides.
queueIdNoRarely needed — resolved from the meeting type by default.
timezoneNoIANA timezone, e.g. Europe/Berlin. Defaults to the host.
meetingTypeIdYesMeeting type identifier
meetingDurationNoOverride the meeting type duration in minutes where the meeting type allows it. A booking for this result requires the same duration value.
existingAppointmentIdNoWhen checking slots for a reschedule, so the current booking does not block itself

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
datesNo
timezoneNo
slotsStartUtcNoEvery bookable start, ISO 8601 UTC, sorted and deduplicated. Book only from this list.

Schema Changelog

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

  1. Changed11 schema fields changedv0.6.25
    • addedInput schema / properties / end
      Added value: +{
      +  "description": "End of the search window",
      +  "type": "string"
      +}
    • addedInput schema / properties / existingAppointmentId
      Added value: +{
      +  "description": "When checking slots for a reschedule, so the current booking does not block itself",
      +  "type": "string"
      +}
    • removedInput schema / properties / from
      Removed value: -{
      -  "description": "Start of the search window",
      -  "type": "string"
      -}
    • addedInput schema / properties / hostIds
      Added value: +{
      +  "description": "Only to narrow a round-robin type to specific hosts. Left out, the meeting type decides.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / meetingDuration
      Added value: +{
      +  "description": "Override the meeting type duration in minutes where the meeting type allows it. A booking for this result requires the same duration value.",
      +  "exclusiveMinimum": 0,
      +  "type": "integer"
      +}
    • changedInput schema / properties / meetingTypeId / description
      Previous value: -"From list_meeting_types"New value: +"Meeting type identifier"
    • addedInput schema / properties / queueId
      Added value: +{
      +  "description": "Rarely needed — resolved from the meeting type by default.",
      +  "type": "string"
      +}
    • addedInput schema / properties / start
      Added value: +{
      +  "description": "Start of the search window",
      +  "type": "string"
      +}
    • removedInput schema / properties / to
      Removed value: -{
      -  "description": "End of the search window",
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "meetingTypeId",
      -  "from",
      -  "to"
      -]New value: +[
      +  "meetingTypeId",
      +  "start",
      +  "end"
      +]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "description": "Bookable slots for the requested window",
      +  "properties": {
      +    "dates": {
      +      "anyOf": [
      +        {
      +          "items": {
      +            "additionalProperties": true,
      +            "description": "One day of availability",
      +            "properties": {
      +              "date": {
      +                "$ref": "#/properties/timezone"
      +              },
      +              "spots": {
      +                "description": "Raw per-day slots as the API returned them"
      +              }
      +            },
      +            "type": "object"
      +          },
      +          "type": "array"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "slotsStartUtc": {
      +      "anyOf": [
      +        {
      +          "items": {
      +            "type": "string"
      +          },
      +          "type": "array"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "description": "Every bookable start, ISO 8601 UTC, sorted and deduplicated. Book only from this list."
      +    },
      +    "timezone": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observedv0.1.1

TDQS

A4.2/5.0
Behavior4/5

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

The description adds meaning beyond the readOnlyHint/idempotentHint annotations by explaining what the returned slotsStartUtc values represent and that they are the starts accepted by booking validation. This clarifies important semantics that an agent would otherwise have to infer. It does not contradict 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.

Conciseness5/5

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

The description is two sentences with no fluff. The core function is front-loaded, and the important caveat about calendar events is placed second. Every sentence earns its place.

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?

For an 8-parameter tool with a high-quality schema, annotations, and an output schema present, the description covers the essential behavioral nuance and scope. It doesn't explain return format or pagination, but the output schema can carry that responsibility. The only slight gap is not explicitly addressing how start/end are interpreted, though the schema names them clearly.

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?

The input schema already documents all parameters with 100% coverage, including optional behaviors like meetingDuration and existingAppointmentId. The description does not add further parameter-level details, which is acceptable given the high schema coverage. Baseline of 3 applies.

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 uses a specific verb ('Return') and identifies the exact resource ('a meeting type's bookable starts') and scope ('within a date range'). It is clearly distinct from sibling tools like list_appointments or get_appointment. The added sentence about slotsStartUtc further grounds the purpose in what makes this tool unique.

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 makes clear this is the tool to use when you need bookable start times for a meeting type, and it gives a scoping detail ('within a date range'). The warning that 'calendar events alone are not availability' implicitly steers agents away from treating calendar data as a substitute, which is a useful usage hint. However, it does not explicitly name any sibling tool as an alternative.

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

Latest Blog Posts

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