DouxProcess Directory

Book an estimate visit

book_estimate

Books an estimate visit with ONE contractor the person chose whose listing shows luma.books_online. The contractor calls the person to confirm the time. Call it once without consent to get consent_text, show it, and call again with consent=true only if they agree.

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": {
      "name": "<name>",
      "phone": "<phone>",
      "address": "<address>",
      "job": "<job>",
      "consent": "<consent>"
    },
    "name": "book_estimate"
  }
}

Input Schema

Name	Required	Description
`job`	Yes	What the job is, in the person's words.
`name`	Yes	The person's name.
`site`	No	Or the Luma site from the listing's luma.site.
`slug`	No	The listing slug from find_businesses (a listing with luma.books_online).
`phone`	Yes	A 10-digit phone number the contractor calls to confirm.
`address`	Yes	The address of the job, as the person gave it for this booking.
`consent`	Yes	True only if the person read and agreed to consent_text.
`preferred_times`	No	Optional: days and times that suit them.

Output Schema

Name	Required	Description	Default
`why`	No
`next`	No
`booked`	Yes
`business`	No
`site_url`	No
`reference`	No
`consent_text`	No
`contact_directly`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare this is non-read-only, non-idempotent, open-world, and non-destructive. The description adds important behavioral context beyond annotations: the contractor calls the person to confirm the time, and consent must be obtained via a preliminary call. It does not spell out all failure modes or side effects, but it adds meaningful operational detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, then the contractor confirmation behavior, then the consent workflow. No wasted text; each sentence carries operational meaning.

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?

Given the annotations, full schema descriptions, output schema, and non-idempotent booking nature, the description covers the essential pieces: single-contractor scope, listing eligibility, contractor follow-up, and the required consent sequence. Return-value details are left to the output schema, which exists.

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 description coverage is 100%, so the schema already documents all eight parameters and the consent parameter's meaning. The description still adds useful semantics by explaining the consent flow: a call without consent returns consent_text, and consent=true should only be used after the person agrees.

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?

The description states a specific verb and resource: books an estimate visit with exactly one chosen contractor whose listing shows luma.books_online. This scope constraint distinguishes it from broader siblings like request_quotes and request_service without needing the schema.

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

Usage Guidelines5/5

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

It gives an explicit two-step consent workflow: call once without consent to get consent_text, show it, then call again with consent=true only if the person agrees. It also makes clear that the booking is with a single contractor the person already chose.

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

All DouxProcess Directory 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?