Podyx MCP

podyx_get_external_checkout

Read-onlyIdempotent

Retrieve an external checkout by UUID to inspect studio-collected funds, original acceptance, and current coverage or action state; read-only and no provider proof required.

Instructions

Get external checkout GET /api/v2/external-checkouts/{id}. A studio collection UUID belongs to the tenant independently of each key-bound HTTP receipt. Report only studio-collected money; native Stripe/Square/cash tenders cannot be externally settled. No provider integration or provider proof is required. Inline complete booking selections use current customer policy. Booking refusal retains collected money and an action obligation; it never claims a refund happened. Same immutable collection facts are a financial no-op across keys; repair is a separate resolution command. GET separates original immutable acceptance from current coverage/action state. New commercial entry is deployment-disabled until external recovery/projection readiness; current authority and owned recovery remain required after disablement. 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_get_external_checkout"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 7, 2026

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered; the description reinforces this with 'Read/preview only'. It adds genuinely useful behavioral context beyond annotations: that identical immutable collection facts are a no-op across keys, that GET separates original acceptance from current coverage/action state, and that refusal retains money rather than implying a refund. However, the phrasing is so domain-jargon-heavy ('key-bound HTTP receipt', 'projection readiness') that the practical meaning for an agent is hard to extract, so it earns credit without reaching 4.

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

Conciseness2/5

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

Eight sentences of dense, abstract prose for a single-id read endpoint, with no bullet structure or front-loading of the practical guidance. Several sentences ('New commercial entry is deployment-disabled until external recovery/projection readiness') read as internal engineering policy that does not help an agent decide or invoke. The endpoint statement is correctly first, but the remainder is not economical.

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?

There is no output schema, so the description should say what a caller gets back; instead it only gestures at 'original immutable acceptance from current coverage/action state' without describing the response, and never explains pagination handling despite saying 'Follow all pagination'. Behavioral warnings about money retention and action obligations are present, which keeps it above minimum, but the return-side gap and unstated parameter scoping leave it short of complete.

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%, so the description bears the burden for the single `path.id` parameter. It partially compensates by framing the identifier as 'a studio collection UUID [that] belongs to the tenant independently of each key-bound HTTP receipt', which tells the agent what kind of id to supply. It says nothing about how key scoping affects the lookup result or about the nested path wrapper.

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?

The opening sentence names a specific verb and resource plus the underlying endpoint: 'Get external checkout GET /api/v2/external-checkouts/{id}'. That is enough to identify the operation, but the definition never distinguishes it from near-identical siblings such as podyx_get_checkout, podyx_get_external_payment_report, or podyx_get_external_subscription_cycle, so an agent cannot tell which of these to open from the text alone.

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

Usage Guidelines2/5

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

There is scope language ('Report only studio-collected money; native Stripe/Square/cash tenders cannot be externally settled') but no explicit when-to-use or when-not-to-use instruction, and no named alternative. The closest thing to routing guidance is an oblique note that 'repair is a separate resolution command', which never names the sibling tool an agent should call instead.

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

Deploy Server