Excellent Reference (free)

Send a private-event inquiry to a venue

send_event_inquiry

Sends a private-event or group-dining inquiry, on behalf of the person you are helping, to a venue that accepts inquiries from AI assistants (its handle comes from find_event_venues). Use it only when the person asked you to contact the venue, with the details they gave you. It lands in the venue's inbox as a new lead for the venue's team to review and answer directly; it books, holds and pays for nothing, and Excellent sends the guest no email. Give an email or a phone so the venue can reply. Answers only whether it was filed. At most 5 an hour and 20 a day per address.

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": {
      "venue": "<venue>",
      "guest_name": "<guest_name>"
    },
    "name": "send_event_inquiry"
  }
}

Input Schema

Name	Required	Description
`venue`	Yes	The venue's handle from find_event_venues (org/form), or its inquiry_url.
`message`	No	Optional: anything else they want the venue to know, in their words.
`event_date`	No	Optional: the date they want, YYYY-MM-DD.
`event_type`	No	Optional: the occasion, e.g. "birthday dinner", "rehearsal dinner", "team offsite".
`guest_name`	Yes	The guest's name, as they gave it.
`party_size`	No	Optional: how many guests.
`guest_email`	No	The guest's email, for the venue's reply. Give this or guest_phone.
`guest_phone`	No	The guest's phone, for the venue's reply. Give this or guest_email.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations: it explains the destination (the venue's inbox, as a new lead), the side effects that do NOT occur (no booking, hold, or payment; no email sent to the guest), the reply channel requirement, the return contract ("Answers only whether it was filed"), and explicit rate limits of 5/hour and 20/day per address. These are exactly the operational facts an agent needs before performing a non-idempotent outbound send.

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?

Front-loads the action and the source of the venue handle, then layers preconditions, side effects, contact requirement, return contract, and rate limits in a compact sequence. Telegraphic clauses like "it books, holds and pays for nothing" carry information densely rather than padding.

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 outbound-send tool with no output schema, the description covers prerequisites, exclusions, reply requirements, return semantics, and throttling — everything needed to call it correctly and to set expectations for the user. Nothing material is left to inference.

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; the description adds real value by surfacing the contact requirement ("Give an email or a phone so the venue can reply"), which the schema states only as a soft note on two optional properties and does not enforce via required. It adds little else beyond the schema, so it stops short of 5.

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 ("Sends a private-event or group-dining inquiry ... to a venue") and names the sibling that supplies the venue handle (find_event_venues), so the agent can place it precisely among the available tools.

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?

Gives an explicit precondition ("Use it only when the person asked you to contact the venue, with the details they gave you") plus the upstream step of getting the handle from find_event_venues. It also implies the negative case — do not send unless the person requested contact — and clarifies that it neither books nor holds anything, which routes the agent away from treating it as a reservation tool.

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

All Excellent Reference (free) 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?