Crawlora MCP

tripadvisor_place

Read-only

Returns a rich normalized TripAdvisor place profile. Destination and bookable tour/experience pages resolve through a faster dedicated lookup; everything else comes from public place HTML, using configured browser fallbacks when direct HTML is blocked. Use tripadvisor_hotels to search TripAdvisor hotels.

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": "tripadvisor_place"
  }
}

Input Schema

Name	Required	Description	Default
`id`	No	TripAdvisor location id; provide either id or url.
`url`	No	TripAdvisor place URL; preferred over id when both are available.

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 5, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover readOnlyHint and openWorldHint. The description adds real behavioral context beyond them: destination/tour pages take a faster dedicated lookup, other pages come from public HTML, and browser fallbacks are used when direct HTML is blocked. It doesn't mention auth or rate limits, but the lookup-path disclosure is genuinely useful.

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 with the purpose front-loaded. The middle sentence about resolution paths is somewhat technical but earns its place as behavioral context. No filler.

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?

An output schema exists so return values needn't be described, and the definition covers purpose, one alternative, and resolution behavior. Given 0 required params, it could note that id or url must be supplied, but the schema handles that. Adequate overall.

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 schema already explains that either id or url is required and that url is preferred. The description adds nothing about parameter syntax or selection, so the baseline 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?

States a specific verb ('Returns') and resource ('rich normalized TripAdvisor place profile'), and it names the hotel-search sibling as an alternative. However, it doesn't clearly distinguish itself from other place-detail siblings like tripadvisor_reviews or tripadvisor_search, so the agent must infer the boundary.

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 gives one explicit routing hint ('Use tripadvisor_hotels to search TripAdvisor hotels'), which tells the agent this is not a search tool. But it never states the positive condition for using this tool (e.g., when you already have a location id or URL) or how it relates to tripadvisor_reviews or tripadvisor_search, leaving usage implied.

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

All Crawlora MCP 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?