Skip to main content
Glama
Sign In

Prubex

by com.prubex
OverviewDiscussionsAdmin

Get free/busy times

calendar_get_free_busy
Read-onlyIdempotent

Returns busy intervals between start and end across all your calendars at once (true availability), and for other attendees where one of your accounts can see them. Only accounts with the calendar.attendee_free_busy capability (see accounts_list) look other people up, usually colleagues in the same organisation; an attendee none of them can see has no entry in items and is named in warnings with ATTENDEE_NOT_VISIBLE, so treat their time as unknown, not free. Use it to check whether people are free; to get candidate slots use calendar_find_meeting_times. Times are ISO 8601: with an offset (2026-11-02T09:00:00+02:00), or without one to mean time_zone; all-day events use dates, and their end is the day after the last day. Example: { "start": "2026-11-03T08:00:00+02:00", "end": "2026-11-03T18:00:00+02:00" }.

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": {
      "start": "<start>",
      "end": "<end>"
    },
    "name": "calendar_get_free_busy"
  }
}

Input Schema

NameRequiredDescriptionDefault
endYesWindow end (exclusive): ISO 8601 date-time or date.
startYesWindow start: ISO 8601 date-time or date.
attendeesNoOther people's email addresses to check too (up to 20). Anyone your accounts cannot see is named in `warnings`, not `items`.
time_zoneNoIANA time zone for dates in and out, e.g. "Africa/Johannesburg". Defaults to the workspace time zone, which prubex_overview returns as `time_zone`.
profile_idNoOnly accounts in this profile (`prf_…` from profiles_list).
account_idsNoOnly these accounts (`acc_…`). Omit to cover every account you can reach.

Output Schema

NameRequiredDescriptionDefault
itemsYes
warningsNoAccounts that failed or timed out, and attendees no account could see (ATTENDEE_NOT_VISIBLE); everything else is still here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare this as a safe idempotent read, so the description goes beyond by disclosing the visibility failure mode: an invisible attendee has no entry in `items` and appears in `warnings` with ATTENDEE_NOT_VISIBLE, and must be treated as unknown rather than free. That partial-result behavior is exactly what an agent needs to avoid misreading availability.

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 behavior and the sibling routing, then caveats and format details. It is dense with substantive content, though the ISO 8601 sentence and inline JSON example run long and partly duplicate the schema patterns and the sample values already conveyed by the format explanation.

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 spelled out, yet the description still explains the two result channels (`items` vs `warnings`) that determine interpretation. With safety, routing, timezone, and partial-result semantics all covered, nothing material for correct invocation 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 already documents all six parameters and the baseline would be 3. The description adds genuine meaning: offset-bearing vs offset-less timestamps meaning `time_zone`, date-only values for all-day events, and the exclusive end being the day after the last day, plus a worked example. Minor residual gap is that it never mentions the 20-attendee cap or profile/account scoping, which live only in the schema.

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 ('Returns busy intervals') with explicit scope: across all your calendars at once, plus attendees where visibility permits. It also explicitly contrasts itself with the sibling it is not (calendar_find_meeting_times), so an agent can route without opening either schema.

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?

Gives a direct when-to-use ('Use it to check whether people are free') and names the alternative for the adjacent task ('to get candidate slots use calendar_find_meeting_times'). It also flags the precondition for attendee lookups (calendar.attendee_free_busy capability) rather than leaving it to discovery.

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

All Prubex toolsInspect
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