Podyx MCP

podyx_packages_subscription_redemption

Read-onlyIdempotent

Fetches a subscription redemption by ID for read-only preview of package rights, session lengths, delivery status, and advisory quotes.

Instructions

Subscription redemption GET /api/v2/subscription-redemptions/{id}. Package kind is fixed by the route. Purchased snapshots and current ledger allowance determine rights and effective session lengths. Quotes are advisory. Redemption atomically creates all sessions and required delivery intents, or writes nothing. Paid extras use the existing separate session add-on purchase flow. Current authority is checked on replay. Cancellation uses the existing subscription cancellation routes. Native provider work is deferred; management GET exposes pending, ready or failed delivery. A ready billing portal URL is disclosed only to a key with current subscriptions:manage authority; read-only keys retain state and capability visibility without the live instruction. Plan changes, pause and resume are unsupported. Paid external decline retains an actionable refund obligation without executing a refund. 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_packages_subscription_redemption"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 7, 2026

TDQS

C2.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, yet the description still adds real behavior: authority is re-checked on replay, a billing portal URL is disclosed only to keys with subscriptions:manage authority while read-only keys see state without the live instruction, and an external decline leaves a refund obligation without executing a refund. The sentence 'Redemption atomically creates all sessions and required delivery intents, or writes nothing' describes underlying transaction semantics and sits in tension with a read-only GET, but the trailing 'Read/preview only' and the annotations resolve it, so this is ambiguity rather than outright contradiction.

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?

The description is a single dense paragraph of unrelated assertions — pagination, refund obligation, portal URL disclosure, unsupported plan changes — with the operative purpose buried behind domain jargon. Sentences do not build in priority order, and several ('Quotes are advisory', 'Follow all pagination') belong to other tools.

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?

For a one-parameter GET with no output schema, the description does clarify delivery states (pending, ready, failed) and permission-gated disclosure, which is useful. But it omits what the redemption payload contains (sessions, delivery intents, effective session lengths) and how this read relates to the quote and rights siblings, so it is only partially complete.

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?

Schema description coverage is 0% for a nested path.id UUID object, so the description must carry the meaning of the parameter. The route template '{id}' only weakly implies the id is the redemption identifier; the description never says where the id comes from (e.g., a quote or redemption response) or what happens on an unknown id.

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

Purpose3/5

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

The opening 'Subscription redemption GET /api/v2/subscription-redemptions/{id}' anchors the tool to a route and resource, so a reader can infer it retrieves a redemption by id. However, the description never plainly states the action ('retrieve'/'read'), and it gives no differentiation from the closely named siblings podyx_packages_subscription_quote, podyx_packages_subscription_rights and podyx_packages_subscription_management.

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?

The guidance is about domain boundaries, not tool selection: 'Cancellation uses the existing subscription cancellation routes', 'Plan changes, pause and resume are unsupported'. There is no statement of when to call this instead of the quote, rights, or management siblings, and 'Follow all pagination' is an instruction with no decision value for a single-id GET.

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

Deploy Server