booking

book_event

Submit a request to book Rick Hebert for an event. This sends the details to Rick, who personally reviews every request and replies (usually within a day) to confirm availability, pricing, and details — it does NOT instantly confirm or hold a date. Collect the contact's name and at least an email or phone number before calling. Rick is based near Houston, TX and travels for the right event.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Full name of the person booking.
`email`	No	Contact email address. Provide this and/or a phone number.
`phone`	No	Contact phone number. Provide this and/or an email.
`format`	No	Preferred format, if known: 'Strolling Close-Up', 'The Stand-Up Show', or 'The Full Evening'. See list_packages. Omit if unsure — Rick will recommend.
`message`	No	Anything else about the event or what they're looking for.
`event_city`	No	City and/or venue. Rick is based near Houston, TX (Greater Houston: The Woodlands, Sugar Land, Galveston, Clear Lake) and travels for the right event.
`event_date`	No	Event date in YYYY-MM-DD format. Omit or leave blank if not set yet.
`event_time`	No	Approximate start time, e.g. '7:00 PM'.
`event_type`	No	The occasion — e.g. wedding, corporate event, birthday party, holiday party, gala, fundraiser.
`guest_count`	No	Approximate number of guests, e.g. '50' or '75-100'.
`contact_pref`	No	How they'd prefer Rick to reach back — e.g. 'email', 'phone', or 'text'.

TDQS

A4.4/5.0

Behavior5/5

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

Excellent disclosure: explains that the tool sends a request for human review, does not instantly confirm, typical response time, and Rick's location and travel. No annotations provided, so the description fully handles behavioral transparency.

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?

Four sentences that front-load the purpose and are free of filler. Could be more structured, but efficient overall.

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 tool's complexity (11 parameters, no output schema, no annotations), the description is remarkably complete: it explains the asynchronous process, prerequisites, response time, and references sibling tools. No gaps identified.

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 100% with detailed descriptions for each of the 11 parameters. The description adds overall context but does not significantly enhance individual parameter understanding beyond the schema. Baseline 3 is appropriate.

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 clearly states the verb and resource: 'Submit a request to book Rick Hebert for an event.' It distinguishes itself from siblings like get_contact and list_packages by focusing on the booking action.

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?

Provides explicit prerequisites ('Collect the contact's name and at least an email or phone number before calling') and references sibling tool list_packages in the format parameter description. However, it does not explicitly state when to use this tool over alternatives.

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

All booking tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool addresses a distinct need: booking, contact info, and package listing. No overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (book_event, get_contact, list_packages).

Tool Count5/5

3 tools are appropriate for a focused booking server, covering core user actions without bloat.

Completeness4/5

Covers essential operations (info, contact, booking). A minor gap might be a cancellation tool, but the surface is adequate for the stated purpose.

Resources

Need Help?