Portmans Motor Lodge

Check availability

check_availability

Read-only. Returns room types that fit the stay, with nightly and total NZD rates from public rate plans only. The restrictions rate is for the rate plan's primary occupancy, not the room type's default occupancy. Each adult or child aged 1+ above that base adds the rate plan's extra-person amount per night. Infants under 1 are not counted and are not charged. By default a public title starts with "BAR - "; a non-empty explicit rate-plan id list in config overrides that. A room with no public plan for the stay is no_public_rate. Respects stop_sell, closed_to_arrival, min_stay_arrival, and occupancy. Dates are ISO dates in Pacific/Auckland, check-out must be after check-in, the stay cannot exceed 30 nights, and check-in cannot be in the past. Does not create a booking and does not accept payment card data.

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": {
      "check_in": "<check_in>",
      "check_out": "<check_out>",
      "adults": "<adults>",
      "children": "<children>"
    },
    "name": "check_availability"
  }
}

Input Schema

Name	Required	Description
`adults`	Yes	Number of adults, from 1 to 20.
`infants`	No	Infants under 1 year. They do not count toward occupancy. One cot is available to hire.
`check_in`	Yes	Check-in date YYYY-MM-DD, interpreted in Pacific/Auckland.
`children`	Yes	Number of children aged 1 or over, from 0 to 20. Do not count infants under 1 here.
`check_out`	Yes	Check-out date YYYY-MM-DD. Must be after check-in. Maximum 30 nights.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 17, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: read-only, no booking created, no payment card data accepted, respects stop_sell/closed_to_arrival/min_stay/occupancy, defines the default public title prefix 'BAR - ' with config override, and names the no_public_rate outcome. It also explains the occupancy/extra-person charging model and that infants under 1 are not counted or charged.

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

Conciseness4/5

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

Front-loaded with the read-only safety statement and the core return value, then proceeds to validity rules and pricing mechanics. Every sentence is substantive, though the density is high and a couple of clauses (rate-plan id override, occupancy restatement) could be tightened.

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

Completeness5/5

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

With no output schema, the description compensates by describing the return payload (room types, nightly and total NZD rates, no_public_rate), and it fully specifies date format, timezone, ordering, and the 30-night/past-date constraints. Nothing an agent needs to call this correctly is missing.

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 100%, so the baseline is 3, but the description adds real semantic value beyond it: the extra-person charge applies per adult or child aged 1+ above the rate plan's primary occupancy, which is not the room type's default occupancy, and infants under 1 are exempt. It still does not clarify a few edge interactions (e.g. cot hire cost vs. rate impact), so it is not a full 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action and resource: it returns room types that fit a stay, with nightly and total NZD rates from public rate plans. This is clearly distinct from get_booking_link and get_property_info, which an agent can differentiate without opening the schema.

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?

Usage is implied by the query-shaped inputs (stay dates and occupancy) and the read-only framing, but there is no explicit 'use this when' or excluded-alternative guidance relative to the sibling tools. An agent can infer intent, but nothing routes it clearly among the three tools.

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

All Portmans Motor Lodge tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?