Podyx MCP

podyx_get_bundle_plan

Read-onlyIdempotent

Retrieve a bundle plan by ID to preview current pricing, options, addons, images, and public availability before quoting. Paginate nested options and addons to inspect complete details.

Instructions

Get bundle-plans GET /api/v2/bundle-plans/{id}. 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

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_bundle_plan"
  }
}

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

C2.3/5.0

Behavior2/5

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

The annotations already state readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description does add that pagination bounds nested collections and that images and terms are available for display, but it spends most of its text on behaviors this tool cannot perform, such as authoring, granting, archiving, and payment-link saves. Those statements do not contradict the annotations directly, but they distract from the actual behavior of a read-only GET and omit useful return-shape context.

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

Conciseness1/5

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

This is a dense wall of text that reads like concatenated documentation for multiple endpoints rather than a focused tool description. It is not front-loaded around what an agent needs to call GET /bundle-plans/{id}; instead it buries the relevant pagination and read-only notes among unrelated authoring, grants, archive, and subscription-sales rules.

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?

For a simple GET-by-ID tool with optional pagination and no output schema, the definition should focus on what is returned and how nested collections are paginated. It mentions nested pagination and displayable images/terms, but the bulk of the description is irrelevant to this operation and even references a view=offers parameter that is absent from the schema. The result is incomplete for the actual read semantics and misleading for an agent trying to predict output.

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 must carry parameter meaning. It does identify options_page, options_per_page, addons_page, and addons_per_page as independent bounds on nested collections, which is useful and better than the bare schema. The id path parameter is not explained beyond the endpoint path, but its UUID requirement is visible in the schema.

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 first sentence does state a specific verb and resource: 'Get bundle-plans GET /api/v2/bundle-plans/{id}'. However, the rest of the description immediately mixes in authoring, grants, subscription sales, archiving, payment links, and idempotency behavior, which obscures whether this tool is purely a read operation. It also does not distinguish this single-plan GET from the sibling podyx_list_bundle_plan.

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 description says 'Read/preview only' and 'GET reads current state', which gives a minimal hint about usage. It does not say when to use this tool versus podyx_list_bundle_plan, podyx_bundle_quote, or podyx_packages_bundle_quote. Most of the remaining text describes unrelated write, grant, archive, and subscription workflows rather than guidance for invoking this GET.

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

Deploy Server