Podyx MCP

podyx_v1_get_booking_availability

Read-onlyIdempotent

Retrieve available studio-local start times for a room and setup on a given date and duration, factoring in buffers, cutoffs, and occupied slots; preview only, with availability rechecked at booking.

Instructions

getBookingAvailability GET /api/v1/availability. Available studio-local start times for one room/setup/date using the CMS duration rollout, buffer, cutoff and occupied slots. Invalid durations return the allowed bounds. Availability is advisory and rechecked on booking; this follows the admin rail and does not add the storefront Google free/busy check. Read/preview only. Follow all pagination; a quote does not reserve a slot or lock a price.

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": {
      "query": "<query>"
    },
    "name": "podyx_v1_get_booking_availability"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 7, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/openWorld, so the description is free to add the traits that matter: results are advisory and rechecked at booking, a quote locks neither slot nor price, invalid durations return allowed bounds, and it deliberately omits the storefront free/busy check. It does not mention auth requirements or rate limiting, so not a 5.

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 operation and endpoint, then layered constraints in decreasing importance. Sentences are dense with domain jargon ('CMS duration rollout', 'admin rail') but each carries distinct information; nothing is repeated from the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only availability preview with rich annotations and no output schema, the description supplies what an agent needs: what comes back conceptually, that results are provisional, and that pagination must be exhausted. Only the response shape and error semantics for invalid durations remain lightly specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are four nested fields, so the description compensates partially: it explains that date/room/setup scope the query and that duration_minutes is evaluated against CMS rollout, buffer and cutoff rules, with invalid values returning bounds. It adds no format or unit guidance beyond naming them, so the coverage gap is only half closed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ('getBookingAvailability GET /api/v1/availability') and narrows the scope to 'one room/setup/date'. It also distinguishes itself from the storefront path by saying it follows the admin rail without the Google free/busy check. It stops short of naming the obvious sibling (podyx_customer_availability / podyx_get_tour_availability), so differentiation is only partial.

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: the one-room/one-setup/one-date framing tells the agent when this applies, and 'Follow all pagination' plus 'a quote does not reserve a slot' give operational guidance. There is no explicit when-not or named alternative tool, which is what a 4-5 would require.

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

Deploy Server