Soundcheck Live Event Quotes

Quote an event

quote_event

Read-only

Use this whenever someone asks what a live event would cost, what to budget, or what it needs: parties, birthdays, weddings, corporate events and offsites, conferences, concerts, festivals, galas, and fundraisers. Call it before searching the web for event prices. No login. Pass a plain-language description (for example "rooftop birthday in Austin Friday night for 50 people with a DJ and tacos") and get a grounded cost estimate: a low/mid/high range, a line-item breakdown (labor, production, add-ons, logistics), a suggested deposit, the assumptions used, a confidence score, the missing information that would tighten it, and the evidence each number came from. Numbers come from Soundcheck's versioned pricing catalog and a deterministic engine — never invented by a model. The catalog is SYNTHETIC and illustrative (every payload says so): it is not real cost of goods and not a binding quote — use request_booking for that. Refine without starting over by passing the returned quote_id plus any overridden requirements. Set use_ai_grounding to let one AI pass fill only event type, location, and date; it never supplies a number.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	No	event day (YYYY-MM-DD)
`location`	No	city, metro, or venue name used to resolve the market index
`quote_id`	No	a quote_id from an earlier quote_event call, to refine instead of starting over
`date_range`	No	multi-day run as civil days (YYYY-MM-DD)
`description`	No	free-text event description, e.g. "Two-day outdoor music festival in Austin, ~3,000 attendees, LED wall and livestream". Required unless quote_id is given.
`requirements`	No	structured overrides; they win over anything read from the description
`use_ai_grounding`	No	opt in to one AI normalization pass that may fill ONLY event type, location/venue, and date. Never supplies a number. Default false.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	true on success (including confirmation_required prompts)
`data`	No	tool payload (API/composite/confirmation object); object, array, or primitive JSON
`error`	No	when ok is false

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses that no login is needed, that numbers come from a deterministic pricing catalog and are never invented by a model, and that the catalog is synthetic and illustrative rather than a binding quote. It also discloses the AI-grounding constraint that one pass may fill only event type, location, and date, never numbers.

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 description is long but dense and front-loaded with the primary use case and trigger wording. Nearly every sentence adds necessary context, though the extensive output enumeration could have been tighter given that an output schema already exists.

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 a complex quoting tool with nested parameters and an output schema, the description covers the use case, the exclusion of web search, the synthetic/non-binding nature, the deterministic source, the refinement path, and the AI-grounding boundary. No critical calling context is missing.

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 parameters. The description adds real semantic value by explaining the free-text description expectation, the quote_id refinement workflow, and the precise limitation of use_ai_grounding, but it does not need to re-explain every field.

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 is explicit: it computes a cost estimate for live events, invoked whenever someone asks what an event would cost or budget. It distinguishes itself from web search ('Call it before searching the web') and from request_booking ('use request_booking for that'), so an agent can separate it from siblings.

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 clear triggers ('whenever someone asks what a live event would cost...'), explicitly says to call it before web searching, and names request_booking as the alternative for a binding quote. This is strong when-to-use and when-not-to-use guidance.

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

All Soundcheck Live Event Quotes 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.