Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

vrbo_properties_rate_calendar

Retrieve a Vrbo property's rate calendar showing nightly prices, availability, and stay constraints using the property ID.

Instructions

Get a Vrbo property rate calendar. Returns public calendar dates, nightly display prices when provided, availability, check-in/out validity, and stay constraints. Resolves the property's GraphQL product ID from the server-rendered page and uses a fresh proxy connection for every request attempt.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
property_idYesVrbo property ID (optionally ending in ha)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden. It does add real value beyond structured fields by disclosing that prices are only present "when provided," that the GraphQL product ID is resolved from the server-rendered page, and that a fresh proxy connection is used per attempt (implying fragility/retry behavior). It stops short of stating the operation is read-only, whether any auth is needed, or how failures surface.

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?

Three sentences, front-loaded with purpose and return contents, with no filler. The closing sentence on proxy/resolution mechanics is arguably implementation detail, but it is short and informative rather than padding.

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

Completeness4/5

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

For a single-parameter read tool with no output schema and no annotations, the description is close to sufficient: it explains purpose, the fields returned, and the conditional nature of pricing. It is only missing selection guidance relative to sibling Vrbo tools and an explicit read-only/side-effect statement.

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 100% and the single property_id parameter is already documented in the schema (including the optional "ha" suffix). The description adds no further format, sourcing, or validation detail for the parameter, so the baseline of 3 applies.

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 description opens with a specific verb+resource ("Get a Vrbo property rate calendar") and then enumerates the return contents: dates, nightly display prices, availability, check-in/out validity, and stay constraints. That is precise enough to distinguish it from retrieval tools generally. What it does not do is differentiate it from the nearest siblings (vrbo_property, vrbo_properties_reviews, airbnb_room_calendar), which is why it lands at 4 rather than 5.

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?

There is no statement of when to reach for this tool versus vrbo_property or airbnb_room_calendar, and no preconditions (e.g. that the property_id must come from vrbo_search or vrbo_locations_search). The description only says what the tool does, leaving selection entirely to inference.

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

Deploy Server

Other Tools