DataToRAG

gws-mcp__calendar_suggest_time

Read-only

Suggests meeting times when everyone named is free. Takes the attendees' addresses, a duration and a time range, and reads their free/busy along with the connected account's own. Returns candidate start and end times inside working hours, in order of time, each as an ISO time and as a local time in the time zone used. Working hours default to 9 to 17 in the account's primary calendar time zone, and weekends are skipped unless include_weekends is true. Starts fall on the quarter hour. An attendee whose free/busy cannot be read (another organization that does not share it, or a misspelled address) is listed under could_not_check, and the suggestions then leave that person out. The range can span at most 31 days. Nothing is booked; calendar_create_event books a chosen slot.

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": {
      "attendees": "<attendees>",
      "duration_minutes": "<duration_minutes>",
      "time_min": "<time_min>",
      "time_max": "<time_max>"
    },
    "name": "gws-mcp__calendar_suggest_time"
  }
}

Input Schema

Name	Required	Description
`account`	No	Optional email address of the connected account to use (e.g. 'user@gmail.com'). If omitted, the default account is used.
`time_max`	Yes	End of the range to search (ISO 8601), at most 31 days after time_min.
`time_min`	Yes	Start of the range to search (ISO 8601).
`attendees`	Yes	Comma-separated email addresses of the people to find a time for.
`time_zone`	No	The IANA time zone working hours are read in, such as "Europe/London" (default: the primary calendar's time zone).
`include_self`	No	Whether the connected account's own calendar counts as busy time (default: true).
`max_suggestions`	No	The most slots to return (default: 5, at most 20).
`duration_minutes`	Yes	How long the meeting is, in minutes (5 to 480).
`include_weekends`	No	Whether Saturdays and Sundays can be suggested (default: false).
`working_hours_end`	No	The hour the working day ends, 1 to 24 (default: 17).
`working_hours_start`	No	The hour the working day starts, 0 to 23 (default: 9).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, and the description carries the rest of the behavior: it reads attendees' free/busy plus the connected account's own, applies 9-to-17 working hours in the primary calendar's time zone, skips weekends by default, aligns starts to the quarter hour, and caps the range at 31 days. It also discloses the failure mode via could_not_check for unreadable or misspelled attendees and states that those people are dropped from results.

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?

The core behavior and output shape lead, followed by defaults, edge cases, and the sibling boundary. Six dense sentences with no filler, though the working-hours/weekend defaults could be tightened since the schema already documents them.

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 11 parameters and no output schema, the description does the necessary work: it explains what candidates look like (ISO and local times, ordered by time), what working-hours assumptions are applied, and what happens when attendee data is unavailable. Nothing an agent needs in order to call it correctly or interpret results 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 baseline is 3, and the description adds genuine meaning on top: it explains that attendees are addresses whose free/busy is read, that working hours come from the account's primary calendar time zone, and that results are quarter-hour aligned. It does not elaborate on max_suggestions or include_self beyond what the schema already says, so it stops short of a 5.

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 first sentence gives a specific verb and resource ('Suggests meeting times') plus the scope condition ('when everyone named is free'). It is immediately distinguishable from calendar_freebusy (raw availability) and calendar_create_event (booking), so an agent can choose it 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?

It clearly draws the workflow boundary with 'Nothing is booked; calendar_create_event books a chosen slot', naming the alternative that follows this tool. It does not explicitly state when to prefer calendar_freebusy for raw availability data, so the exclusion is slightly incomplete.

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

All DataToRAG 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.