findtime.io MCP Server

Approve a booking request

approve_booking_request

DestructiveIdempotent

Approves a host's booking request. findtime.io adds it to the host's Google Calendar and Google sends the invite. Answers needs_calendar_connect when Calendar isn't connected, needs_payment when the account has no meeting allowance, needs_sync for an unfinished approval whose retry resumes the same event, or conflict when the request changed. Without confirm: true, the operation changes nothing and returns a read-back with status needs_confirmation. confirm: true executes the same operation after the person has confirmed that read-back. Every result has a status listed in the output schema. temporarily_unavailable indicates a temporary service failure.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "requestId": "<requestId>",
      "lifecycleVersion": "<lifecycleVersion>"
    },
    "name": "approve_booking_request"
  }
}

Input Schema

Name	Required	Description
`confirm`	No	true indicates the person confirmed the read-back returned by the same operation with confirmation omitted.
`message`	No	Optional note to the guest.
`requestId`	Yes	requestId from an earlier answer.
`_endUserId`	No	Optional opaque per-call end-user attribution token populated by the MCP host, not the LLM. Accepts a non-PII hash or token, excluding raw email addresses, names, or platform user IDs.
`googleMeet`	No	true adds a Google Meet link to the event.
`lifecycleVersion`	Yes	Request lifecycleVersion from the latest inbox response. A stale value returns conflict.

Output Schema

Name	Required	Description	Default
`hint`	No
`link`	No
`error`	No
`retry`	No
`reason`	No
`status`	Yes
`request`	No
`summary`	No
`readBack`	No
`freeMeetings`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructive/open-world/idempotent, but the description adds substantial value beyond them: it names the external side effect (Google Calendar invite sent), enumerates the non-success statuses (needs_calendar_connect, needs_payment, needs_sync, conflict, temporarily_unavailable), and documents the no-op/read-back behavior when confirm is absent. This is rich behavioral disclosure the annotations don't carry.

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 and effect, then the confirm protocol, then statuses. Every sentence carries information, though the status enumeration is dense and could be slightly tighter.

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?

With an output schema present, return values needn't be explained, yet the description still references the status set, and it fully covers the mutation's effect, error modes, and confirmation protocol. Nothing needed to call it correctly is missing.

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 documents all six parameters and a baseline 3 would be acceptable. The description goes further, explaining the confirm state machine and that lifecycleVersion staleness yields conflict, adding real meaning over the schema hints.

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 resource ('Approves a host's booking request') and clarifies the downstream effect (added to Google Calendar, invite sent). An agent can distinguish this from siblings like decline_booking_request or cancel_booking without opening any 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?

The two-step confirm workflow is spelled out clearly: calling without confirm returns a read-back and changes nothing; the agent then calls again with confirm:true. It gives clear context for use but doesn't explicitly contrast with the alternative decline/cancel tools or state exclusions, keeping it below a 5.

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

All findtime.io MCP Server 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.