property-search

Book a property viewing (no account needed)

book_viewing

Request a viewing of an OpenMoov property on behalf of the user — no account required. Requires the property id plus the user's real name, email and UK phone number (the agent uses these to confirm the appointment). Optionally pass preferred_days (e.g. ["Saturday","Sunday"]), preferred_time_of_day (e.g. "morning", "afternoon", "evening") and a short message. Creates a real lead an agent will act on — only call with genuine user details and explicit intent. IMPORTANT: some listings are by PRIVATE OWNERS (listedBy "private_owner" on search/details results). For those, first ask the user whether their name and phone number may be shared with the private owner to arrange the viewing, and pass consent_to_share_details: true only if they agree — without it the request is handled by OpenMoov customer service instead of reaching the owner directly. Returns a viewing_request_id and a status_token: KEEP BOTH, check_viewing_status needs them.

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": {
      "property_id": "<property_id>",
      "name": "<name>",
      "email": "<email>",
      "phone": "<phone>"
    },
    "name": "book_viewing"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The user's full name
`email`	Yes	The user's email — the agent confirms by email
`phone`	Yes	The user's phone number
`message`	No	Short note to the agent
`property_id`	Yes	Property id from search_properties results
`preferred_days`	No	Days that suit the user, e.g. ["Saturday","Sunday"]
`preferred_time_of_day`	No	e.g. "morning", "afternoon" or "evening"
`consent_to_share_details`	No	Set true ONLY after the user explicitly agrees their name and phone may be shared with the property's private owner to arrange the viewing. Needed for listedBy "private_owner" listings to reach the owner directly; ignored for agent listings.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say it is a non-read-only, non-idempotent, open-world write. The description adds real consequences: a real lead an agent will act on, a consent gate for private owners, an explicit fallback (handled by OpenMoov customer service if consent is absent), and the returned viewing_request_id/status_token that must be kept. That is substantial behaviour beyond the structured fields.

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 what the tool does and what it requires, then the risk warning, then the private-owner consent exception, then return values — a sensible priority order. A few fragments duplicate the schema examples (preferred_days, time_of_day), but no sentence is filler.

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?

For an 8-parameter, non-idempotent outward-facing write with no output schema, it covers required inputs, the conditional consent path, the real-world side effect, and the shape of the response. An agent has everything needed to call it correctly and safely.

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 semantics the schema does not: the phone must be a UK number, the details must be the user's real details, preferred_days/time_of_day are optional and free-form, and consent_to_share_details is only ever true after explicit user agreement. It also explains that consent is ignored for agent listings, which the schema states in weaker form.

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 and resource ('Request a viewing of an OpenMoov property on behalf of the user') and immediately scopes it with 'no account required'. An agent can tell this apart from check_viewing_status, get_available_viewing_slots or search_properties without opening any schema.

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?

Gives clear preconditions: only call with genuine user details and explicit user intent, and it explicitly branches on private_owner listings with a consent step before calling. It also points to check_viewing_status as the follow-up consumer of the returned tokens. It stops short of naming when a sibling such as get_available_viewing_slots should be used first to select a slot, so it is strong but not exhaustive.

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

All property-search 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?