Podyx MCP

podyx_list_setup

Read-onlyIdempotent

List catalog setups with pagination, filtering by room, service, setup, and active status; choose authoring or offers view and independently paginate configured prices.

Instructions

List catalog setups GET /api/v2/setups. 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

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

Input Schema

Name	Required	Description	Default
`query`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.0Nov 7, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false). The description adds useful domain behavior: configured-price pagination and that amounts are current catalog rates rather than dated quotes. However, it spends substantial text on mutation/archive/idempotency-key semantics that do not apply to this read-only tool, diluting rather than clarifying behavior.

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

Conciseness3/5

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

The opening sentence is front-loaded and precise, but the remainder is a run-on block mixing tool-specific guidance with general catalog/mutation policy (idempotency keys, archive, restore) that is irrelevant to a list call. Several sentences do not earn their place for this tool.

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?

With no output schema and a nested 10-property query object, the description reasonably covers pagination and price-pagination behavior. It leaves filter parameters and default handling unexplained, and the irrelevant mutation context consumes space that could have completed those gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning, and it does explain the view enum options, the separate prices_page/prices_per_page pagination, and lifecycle implications of include_inactive (archive/restore). It omits the room_id, setup_id, and service_id filter semantics, so it is strong but not complete.

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?

First sentence states a specific verb+resource and endpoint: "List catalog setups GET /api/v2/setups." An agent can distinguish it from podyx_get_setup (single fetch) and podyx_v1_list_setups (versioned sibling), though neither sibling is named explicitly.

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?

It does give conditional guidance for the view parameter ("Authoring includes drafts; view=offers reuses customer buyability") and warns to "Follow all pagination." But there is no explicit routing versus podyx_v1_list_setups, podyx_get_setup, or when to include inactive setups, leaving alternative selection implicit.

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

Deploy Server