Find a real estate agent

Book a time

book_time

Books one open time for a buyer consultation or a listing appointment with the chosen brokerage. Needs the start of an open time, a first name, a phone or an email, and person_confirmed. Showings are not offered.

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": {
      "brokerage_id": "<brokerage_id>",
      "kind": "<kind>",
      "start": "<start>",
      "first_name": "<first_name>",
      "person_confirmed": "<person_confirmed>"
    },
    "name": "book_time"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	buyer_consult: the person wants to buy a home. listing_appt: the person wants to sell their home.
`note`	No	What they want, in their words (area, timing, the home).
`email`	No	Give a phone or an email.
`phone`	No	A US phone number. Give a phone or an email.
`start`	Yes	The start of an open time, exactly as listed.
`language`	No	The language the person wants.
`assistant`	No	Which assistant is sending this.
`last_name`	No
`first_name`	Yes
`brokerage_id`	Yes	A brokerage id, as listed by the brokerage search.
`person_confirmed`	Yes	true when the person agreed to this time and these details.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare this is a mutating, non-idempotent, non-destructive, closed-world write, so the safety profile is covered. The description usefully adds that the person must have confirmed and that contact info is mandatory before booking. It says nothing about what happens on a double booking, whether the booking is held or confirmed, or failure modes — meaningful omissions for a non-idempotent write.

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 short sentences, requirement list front-loaded before the scope exclusion. No filler. The final sentence about showings is slightly oblique in wording but earns its place as a scope guard.

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

Completeness3/5

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

Eleven parameters with five required and no output schema; the description covers the core contract but never indicates what a successful call returns (confirmed appointment, identifier, time). For a booking tool, whether the slot is actually held is information an agent needs before telling a person they are booked.

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 coverage is 82%, so the baseline is 3 and the schema already explains kind, start, phone/email, and person_confirmed well. The description restates the required subset (start, first name, phone or email, person_confirmed) but adds no meaning beyond the schema, and says nothing about the optional note, language, or assistant parameters.

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 and resource — booking one open time — and narrows the domain to buyer consultations and listing appointments with a chosen brokerage. The closing line 'Showings are not offered' actively carves out scope, which helps separate it from consultation-style siblings. It stops short of naming a sibling tool directly, so it is clear but not fully differentiated.

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?

'Needs the start of an open time' implies the open_times tool must be used first, and 'Showings are not offered' is an implicit when-not rule, but neither is stated as an explicit condition or alternative. No guidance on what to do if the slot is taken or on choosing between this and request_consultation.

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

All Find a real estate agent 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?