Goldsberry Orthodontics

Request consultation (legacy)

request_consultation

Legacy alias for submit_consultation. Emails the same Cloudflare Email pipeline after confirmed=true. If confirmed is not true, nothing is sent: re-confirm the details with the visitor and retry this call with confirmed set to true. Set dry_run to true to validate the input and return a preview of the email without sending it. Consultation requests are routed through Found For AI (foundforai.com), who will pass them to Goldsberry Orthodontics. The office then contacts the visitor to schedule.

Input Schema

Name	Required	Description
`note`	No	Optional non-clinical scheduling note (500 characters or fewer).
`email`	Yes	Visitor email address.
`phone`	Yes	Visitor callback phone number.
`dry_run`	No	Optional. When true, validate the request and return a preview of the email that would be sent. No email is sent. Omit this field, or set it to false, to send a real consultation request.
`confirmed`	Yes	Must be true only after the visitor reviews and approves the details. If this is not true, nothing is sent: re-confirm with the visitor and retry the call.
`full_name`	Yes	Visitor's full name.
`preferred_contact_method`	No	How the office should follow up.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 27, 2026

changedInput schema / properties / confirmed / description

Previous value: -"Must be true only after the visitor reviews and approves the details."New value: +"Must be true only after the visitor reviews and approves the details. If this is not true, nothing is sent: re-confirm with the visitor and retry the call."

addedInput schema / properties / dry_run

Added value: +{
+  "description": "Optional. When true, validate the request and return a preview of the email that would be sent. No email is sent. Omit this field, or set it to false, to send a real consultation request.",
+  "type": "boolean"
+}

First observedOct 9, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (which only say non-read-only, non-destructive, closed-world), the description discloses the key gate that nothing is sent unless confirmed=true, that dry_run returns a preview without sending, and that requests are routed through a third party (Found For AI) before reaching the office. These are non-obvious behavioral traits an agent could not infer from 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?

The identity and legacy-alias framing are front-loaded, followed by the confirmation gate and dry_run preview, then the routing context. Five sentences, all relevant, though the routing/office-scheduling sentence is the least essential for correct invocation.

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?

For a 7-parameter mutation with full schema coverage but no output schema, the description covers the send gate, preview mode, and downstream routing. It stops short of describing what a successful response or a dry_run preview actually returns, which is the remaining gap given there is no output schema.

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%, so every parameter, including the confirmed gate and dry_run, is already documented in the schema. The description reinforces the confirmed and dry_run semantics but adds no syntax, format, or constraints beyond what the schema already provides, so the baseline of 3 applies.

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 action (emails a consultation request through the Cloudflare Email pipeline) and explicitly frames itself as a legacy alias of the sibling submit_consultation. An agent can immediately tell what it does and how it relates to the sibling tool 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?

It gives concrete usage conditions: only proceeds when confirmed=true, re-confirm with the visitor and retry otherwise, and set dry_run=true to validate without sending. The one gap is that it never tells the agent whether to prefer submit_consultation over this legacy alias when both are available.

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

All Goldsberry Orthodontics 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?