Tabflows

Get open Tabflows demo times

get_demo_availability

Read-only

Open times on the Tabflows demo calendar, grouped by meeting length, soonest first. Every start time is a UTC ISO timestamp, whatever timezone is passed. An answer lists at most 20 times per meeting length: start sets a later date to read from, such as next week, and when truncated is true, nextStart is the start that returns the times after the cut. timezone is the person's IANA timezone: a start date is read in it, it picks the month monthOffset counts from, and the same timezone passed to book_demo sets the time zone of the booking and the invitation. A start time can be booked only with the durationMinutes it is listed under. Availability changes between calls, so times from an earlier answer may no longer be open.

Input Schema

Name	Required	Description
`start`	No	Earliest time to list: a YYYY-MM-DD date read in timezone, or the nextStart of an earlier answer. Defaults to now.
`timezone`	Yes	IANA timezone the times are read in, e.g. "America/New_York"
`monthOffset`	No	Month to start reading at: 0 for this month (the default), 1 for next month, 2 for the one after

Output Schema

Name	Required	Description	Default
`message`	Yes
`timezone`	Yes
`nextStart`	No
`truncated`	Yes
`bookDemoUrl`	Yes
`availability`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 13, 2026

changedInput schema / properties / monthOffset / description

Previous value: -"0 for this month (the default), 1 for next month, 2 for the one after"New value: +"Month to start reading at: 0 for this month (the default), 1 for next month, 2 for the one after"

addedInput schema / properties / start

Added value: +{
+  "description": "Earliest time to list: a YYYY-MM-DD date read in timezone, or the nextStart of an earlier answer. Defaults to now.",
+  "maxLength": 35,
+  "type": "string"
+}

addedOutput schema / properties / nextStart
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / truncated
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "timezone",
-  "availability",
-  "bookDemoUrl",
-  "message"
-]New value: +[
+  "timezone",
+  "availability",
+  "truncated",
+  "bookDemoUrl",
+  "message"
+]

AddedSep 16, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and destructiveHint, and the description adds substantial behavior beyond them: a hard cap of 20 times per meeting length, nextStart/truncated pagination semantics, the volatility warning that earlier answers may be stale, and the invariant that all times are UTC ISO regardless of the timezone passed.

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-loads the core purpose, then proceeds through output shape, parameter behavior, and the booking constraint, with no filler sentences. It is dense and somewhat long for a single paragraph, but each clause carries operational information.

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?

Given an output schema already documents the return object, the description supplies exactly the non-schema facts an agent needs: truncation handling, timezone propagation, and the durationMinutes booking constraint.

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% (baseline 3), and the description still adds cross-parameter meaning: timezone governs how start is read, which month monthOffset counts from, and carries forward to book_demo. It does not restate format constraints (maxLength, monthOffset bounds) that the schema already carries.

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 ('open times on the Tabflows demo calendar') plus the shape of the answer ('grouped by meeting length, soonest first'), which lets an agent separate it from book_demo or get_demo_booking_link at a glance.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: an agent infers it calls this to find a slot before book_demo, and the description ties them together by saying a listed time 'can be booked only with the durationMinutes it is listed under'. There is no explicit when-to-use/when-not framing or named alternative (e.g. when to use get_demo_booking_link instead).

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

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