Capable

Reschedule meeting

reschedule_meeting

DestructiveIdempotent

Moves a booked meeting to a new time in place. The existing calendar event is patched, so the video call link, the attendees and the invite stay the same, and the invitee gets a "your meeting moved to {new time}" email; the invitee doesn't re-pick. The new time is freebusy-checked against every host and refused if one is busy; the host's saved workday, buffers and minimum notice are not re-applied, because the host is the authority over their own meeting. Duration carries over unless you pass new_duration_min. A meeting still awaiting the invitee's pick returns a not_confirmed error. Returns the meeting's full state, the new when-label and the video call link.

Get the new time from find_times when the host's calendar needs checking, and confirm it with the user before calling.

When to use: The user wants a confirmed meeting at a different time. For a meeting the invitee hasn't picked yet, cancel it and propose new times instead.

Example: Move my 2pm with Sara to Thursday at the same time.

Input Schema

Name	Required	Description
`new_start`	Yes	ISO 8601 start of the new time (e.g. a find_times slot's starts_at, or a specific time the user named). Must be in the future and different from the current start.
`meeting_id`	Yes	The confirmed meeting's id, from search_records or get_record.
`new_duration_min`	No	Optional new duration in minutes. Omit to keep the meeting's current length.

Output Schema

Name	Required	Description	Default
`code`	No
`note`	No
`slots`	No
`meeting`	No
`guidance`	No
`meet_link`	No
`timed_out`	No
`meeting_id`	No
`rescheduled`	No
`new_when_label`	No
`co_host_repair_needed`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```

Changed1 schema field changedOct 20, 2026

removedInput schema / properties / meeting_id / pattern

Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Changed8 schema fields changedOct 19, 2026
- removedOutput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
- removedOutput schema / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / meet_link / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / meet_link / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / meeting / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / meeting / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / slots / items / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / slots / items / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
First observedOct 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses rich behavior: the video link/attendees/invite are preserved, an invitee-facing 'meeting moved' email is sent, the new time is freebusy-checked against every host, and host workday/buffers/minimum-notice are deliberately NOT re-applied. It also documents the not_confirmed error for pending picks. No contradiction with annotations.

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

Conciseness4/5

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

Front-loaded with the core action, then behavior, then routing, then example. Information-dense and well-organized, though slightly long, with minor redundancy between 'invite stays the same' and 'the invitee doesn't re-pick'.

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?

An output schema exists, so return values needn't be documented, yet the description helpfully notes they include full meeting state, the when-label and the video link. Error behavior, prerequisites, and alternatives are all covered for a destructive-ish mutation tool.

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?

Schema coverage is 100%, so the schema already documents all three parameters. The description still adds value by explaining new_duration_min's carry-over default ('Duration carries over unless you pass new_duration_min') and the freebusy validation applied to new_start, going beyond the schema's field-level notes.

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+resource+scope: 'Moves a booked meeting to a new time in place', and clarifies the event is patched rather than recreated. This clearly distinguishes it from siblings like propose_meeting, send_meeting_invite, and cancel_meeting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Explicit 'When to use' section scopes it to confirmed meetings at a different time, and names the alternative for the unconfirmed case ('cancel it and propose new times instead'). It also routes the agent to find_times for the new slot and instructs confirming with the user before calling.

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

All Capable 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?