Podyx MCP

podyx_list_bundle_plan

Read-onlyIdempotent

Lists bundle plans with pagination and filters for public/private scope plus authoring or offer views, enabling inspection of bundle availability and pricing.

Instructions

List bundle-plans GET /api/v2/bundle-plans. Packages owns JSON normalization, scoped references, computed prices, version snapshots and lifecycle. Public authoring permits repairable drafts and never grants. Omitted options/addons preserve; [] clears. Authoring scope=private/all also requires clients:read. view=offers uses current public purchasability and excludes private plans; images and terms are available for display. options_page/options_per_page and addons_page/addons_per_page independently bound nested collections. Private commands require clients:read. Direct grants separately require grant. Subscription sales require resend_payment_link; bundle sales use create/update authority. Explicit bundle payment-link saves use the shared default validity window when omitted, including private edits; resends preserve the stored deadline. Bundle grants remain open-ended; subscription private deadlines and targets are immutable. Archive deactivates without changing prior purchases. UUID Idempotency-Key required; replay checks current authority and returns immutable acceptance only. GET reads current state. Read/preview only. Follow all pagination; a quote does not reserve a slot or lock a price.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "podyx_list_bundle_plan"
  }
}

Input Schema

Name	Required	Description	Default
`query`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 7, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and the description's 'GET reads current state. Read/preview only.' is consistent with them. But the bulk of the text discloses behavior that does not apply to this operation and is actively misleading for a read-only list: 'UUID Idempotency-Key required', 'Direct grants separately require grant', 'Archive deactivates', and resend/payment-link rules. The one genuinely useful disclosure is that 'a quote does not reserve a slot or lock a price' plus the instruction to follow all pagination; return shape and what 'current state' contains are never described.

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?

Purpose is front-loaded in sentence one, but the remainder is a dense wall of roughly a dozen unorganized domain rules copied from write and quote endpoints, with no headers, bullets, or logical grouping. Much of that text does not earn its place in a list tool's definition and dilutes the two or three facts an agent actually needs.

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

Completeness2/5

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

This is a complex listing tool: twelve nested pagination/filter parameters, no output schema, and no per-parameter documentation. The description never says what a listed bundle-plan contains or how the nested options/addons/included_items collections are shaped, and it omits include_inactive despite referencing archived plans elsewhere. It compensates partially on authorization and pagination but leaves the agent unable to predict the response.

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 twelve nested query properties, so the description must carry the load. It does explain some: view=offers vs authoring, the clients:read requirement for scope, and that options_page/options_per_page and addons_page/addons_per_page 'independently bound nested collections'. It leaves page, per_page, include_inactive, and included_items_page/per_page completely unaddressed, and 'Omitted options/addons preserve; [] clears' describes patch semantics that do not exist in this listing schema.

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 backing endpoint ('List bundle-plans GET /api/v2/bundle-plans'), which is enough to distinguish it from the singular podyx_get_bundle_plan. It loses the fifth point because the following sentences describe write-side rules (grants, payment links, idempotency) that muddy what this particular read tool actually does rather than sharpening its identity against siblings like podyx_packages_bundle_quote.

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?

There is real conditional guidance: view=offers selects current public purchasability and excludes private plans, and scope=private/all raises the clients:read requirement. However, nothing says when to reach for this tool versus podyx_get_bundle_plan or podyx_packages_bundle_quote, and there are no explicit exclusions or when-not cases, so the guidance is implicit rather than actionable for tool selection.

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

Deploy Server