DogPolicies

Find hotels for a dog (alias)

dogrulebook_find_hotels

Read-onlyIdempotent

Alias of dogpolicies_find_hotels, kept for older clients. Find hotels and motels in California and Nevada that will take a specific dog, with the estimated pet fee for the stay.

Each hotel is sorted into "match" (the policy says yes on everything asked), "possible" (nothing rules it out, but something needs a call: a hotel that decides case by case, an unstated weight limit, a limit the hotel lifts with its approval, an "up to" fee) or excluded (left out). Matches come first, cheapest pet fee first. The fee arithmetic is spelled out for every result.

Examples:

"Will a Monterey hotel take my 70 lb Lab for under $50?" -> county="Monterey", dog_weight_lb=70, max_total_fee=50
"Two dogs, three nights near Palm Springs" -> near={lat:33.83, lon:-116.55}, dogs=2, nights=3
"Is the Motel 6 in Fresno dog friendly?" -> query="Motel 6 Fresno"
"A Las Vegas hotel for my 60 lb dog" -> county="Clark", state="NV", dog_weight_lb=60

Input Schema

Name	Required	Description	Default
`area`	No	Area id, the name a traveler gives the trip: san-francisco, east-bay, peninsula, south-bay, north-bay, lake-tahoe, big-sur, mendocino-coast, yosemite, death-valley
`dogs`	No	Number of dogs
`near`	No	Limit to places near a point; results are sorted by distance
`brand`	No	Only this hotel brand
`limit`	No	Maximum results to return
`query`	No	Words in the hotel name, city or brand
`state`	No	"CA" or "NV". Also tells apart counties with the same name, such as Humboldt.
`county`	No	County name without "County", in California or Nevada, e.g. "Monterey" or "Washoe"
`nights`	No	Nights of the stay
`offset`	No	Results to skip, for pagination
`region`	No	Region id, e.g. central-coast, san-diego or reno-tahoe-nevada
`dog_weight_lb`	No	The dog's weight in pounds
`max_total_fee`	No	Most the guest will pay in pet fees for the whole stay, USD
`response_format`	No	'markdown' for readable text, 'json' for structured data	markdown
`include_possible`	No	Include hotels that need a call to confirm

Output Schema

Name	Required	Description
`as_of`	Yes	Date the data was built (YYYY-MM-DD)
`count`	Yes
`total`	Yes
`counts`	Yes
`hotels`	Yes
`offset`	Yes
`license`	Yes
`has_more`	Yes
`attribution_url`	Yes
`attribution_text`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, idempotent). The description adds valuable behavioral detail: results are grouped into match/possible/excluded, matches are sorted by cheapest pet fee, and fee arithmetic is shown per result. It does not discuss pagination or output format details, but the output schema likely covers those.

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?

The alias note is front-loaded, followed by a clear purpose statement, then reasoning about result categories and sorting, then examples. Every sentence is useful, though the example block is somewhat verbose; overall it is well-structured for a complex tool.

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?

Given 15 parameters, nested objects, four enums, an output schema, and full annotation coverage, the description provides enough context to call the tool correctly. It explains the search domain, what each result category means, sorting, and gives worked examples. It could be slightly more explicit about when to prefer the canonical sibling, but it is otherwise complete.

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 schema already documents every parameter. The description goes beyond the schema by providing natural-language examples that map real questions to specific parameter combinations (county, near, dogs, nights, query, state, dog_weight_lb, max_total_fee), which helps an agent translate intent into arguments.

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 verb (find) and resource (hotels/motels) for a specific dog, with scope (California and Nevada) and fee estimation. It also explicitly names the canonical sibling it aliases (dogpolicies_find_hotels), so an agent can tell it is a duplicate for older clients.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The alias note ('kept for older clients') gives clear context that new callers should prefer dogpolicies_find_hotels, and four concrete query-to-parameter examples demonstrate invocation patterns. It stops short of an explicit 'use X instead' directive or exclusion rules, but the intent is clear.

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

All DogPolicies 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.