Podyx MCP

podyx_get_addon

Read-onlyIdempotent

Retrieve a catalog add-on by UUID with paginated configured prices to inspect offer details and customer buyability before booking or updates.

Instructions

Get catalog addons GET /api/v2/addons/{id}. Catalog owns JSON normalization, versioning, links, configured prices and lifecycle. Authoring includes drafts; view=offers reuses customer buyability. Configured prices are independently paginated with prices_page/prices_per_page and refer to current service versions. Amounts are configured catalog rates, not a dated customer quote. Omitted links/override sections preserve; [] clears the submitted collection. Archive deactivates; restore reactivates and enforces existing room allowances. Mutations require a UUID Idempotency-Key and current primary/linked-resource authority, including receipt replay. 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_addon"
  }
}

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

Behavior1/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, but the description discusses mutations, archive/restore behavior, and Idempotency-Key requirements. Even though it later says 'Read/preview only', the mutation language contradicts the read-only annotation and creates ambiguity about what the tool can actually do.

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 response is front-loaded with the endpoint, but it then includes many unrelated catalog, mutation, and lifecycle sentences that do not apply to a read-only get tool. Those sentences distract from the core retrieval behavior and make the definition harder to parse.

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 pagination and no output schema, the description should focus on the identifier, pagination behavior, and return shape. Instead it spends most of its length on mutation semantics, archive/restore behavior, and non-schema parameters, leaving the actual read behavior under-explained.

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 compensate. It names prices_page and prices_per_page and explains independent price pagination, but it does not explain the required path.id parameter beyond the URL template, and it references a view parameter that is not in the 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 first sentence states a specific verb and resource: 'Get catalog addons GET /api/v2/addons/{id}'. That is enough for an agent to identify it as a single-addon retrieval tool, though it does not explicitly distinguish it from sibling list tools such as podyx_list_addon or podyx_v1_list_addons.

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 does not say when to use this tool versus alternatives like podyx_list_addon. It mentions 'view=offers' and authoring drafts, but the schema has no view parameter, so the guidance is confusing rather than actionable.

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

Deploy Server