Podyx MCP

podyx_v1_get_session

Read-onlyIdempotent

Retrieve a studio session by UUID to view its derived status, persisted booking status, linked payments, and optional details, guests, files, or brief; use pagination for complete results.

Instructions

getSession GET /api/v1/sessions/{id}. History-aware sessions, including fact-backed cancellations and roomless studio tours. Dates and times are studio-local. A session ID identifies a slot and differs from its booking ID. Status is the derived session state; booking_status is the persisted purchase state. Original payment status describes only the first linked payment, not later add-on charges. 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": {
      "path": "<path>"
    },
    "name": "podyx_v1_get_session"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes
`query`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 7, 2026

TDQS

B3.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds genuine domain context: timestamps are studio-local, `status` is derived versus `booking_status` being persisted, and original payment status covers only the first linked payment. Those are non-obvious semantics an agent could not get from the schema. The trailing line about quotes not reserving a slot is off-topic for a GET and slightly muddies the otherwise clean behavioral picture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence restates the endpoint path verbatim and earns little, and the closing sentence about quotes is irrelevant to a read operation. The middle is dense and front-loaded with useful semantics, but the block reads as a stitched-together set of caveats rather than a structured definition.

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

Completeness3/5

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

With no output schema, the description does carry some return-value burden by explaining status, booking_status, and payment status. However, for a tool with a nested `path` object and an `include` selector that materially changes the payload, the definition leaves the agent guessing about response composition and section restriction behavior.

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

Parameters2/5

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

Top-level schema description coverage is 0% and the description says nothing about the `path.id` UUID requirement or, more importantly, the `query.include` sections (details, links, guests, files, brief) that shape the response. It offers only a generic "follow all pagination" hint, which the schema's own per-page clamping notes already imply. The most consequential parameter is left unexplained by the prose.

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?

"getSession GET /api/v1/sessions/{id}" names a specific verb and resource, and the line "A session ID identifies a slot and differs from its booking ID" distinguishes this from the booking-oriented siblings (podyx_v1_get_booking, podyx_v1_list_bookings). It never names list_sessions as the alternative for enumerating, but the purpose itself is unambiguous.

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 agent learns it must hold a session ID (not a booking ID) to call this. There is no explicit "use this when X, use list_sessions when Y" routing, and "Follow all pagination" is the only operational instruction. Adequate but leaves alternative selection to inference.

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

Deploy Server