Podyx MCP

podyx_packages_bundle_rights

Read-onlyIdempotent

Retrieve bundle rights and effective session lengths for a client to preview package access, purchased snapshots, and current ledger allowances.

Instructions

Bundle rights GET /api/v2/clients/{id}/bundle-rights. 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_bundle_rights"
  }
}

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.2/5.0

Behavior4/5

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

The annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond them, especially the authority-gated billing portal URL, read-only key visibility, pagination requirements, and the fact that quotes do not reserve slots or lock prices. Some of its behavioral details concern sibling redemption and cancellation flows rather than this GET tool, which keeps it from 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.

Conciseness2/5

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

The endpoint and read-only nature are front-loaded, but the description becomes a dense run-on covering redemption atomicity, cancellation routes, plan changes, external declines, and other sibling concerns. Much of that text does not help an agent invoke this particular GET tool and crowds out the missing query-parameter guidance.

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?

The description provides substantial domain context about rights determination, delivery state visibility, and authority gating, and there is no output schema to explain return values. However, for a read tool with nested query parameters and no schema descriptions, it is not complete enough because most query parameters remain semantically unexplained.

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%, so the description must explain the query parameters. It only signals the path id through the endpoint template and mentions pagination generally; it leaves service_id, member_package_id, duration_minutes, and the distinction between page/per_page and addons_page/addons_per_page undocumented.

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 description names a specific verb and resource: 'Bundle rights GET /api/v2/clients/{id}/bundle-rights.' It also clarifies that the package kind is fixed by the route, which helps distinguish bundle rights from subscription rights. It does not explicitly name the closest sibling alternatives, but the core operation is clear.

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?

The description says 'Read/preview only' and indicates that redemption, paid extras, cancellation, and plan changes follow separate flows or are unsupported. That gives useful when-to-use and when-not-to-use context, but it never directly says when to choose this tool over podyx_packages_bundle_quote or podyx_packages_subscription_rights.

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

Deploy Server