Arcana: San Francisco wine bar, restaurant, art space and music venue. Reservations, private events.
Scored across 6 tools
Most tools target clearly distinct needs (business facts, reservations, public events, private events, inquiry prep, inquiry submit). The main friction is that get_business_info advertises 'every part of what it offers' and links to each offering, so it partially overlaps with get_private_event_offer, get_reservation_options, and list_upcoming_events. The 'start here' framing and the prepare vs. submit split keep misselection limited.
All tools use a consistent snake_case verb_noun pattern (get_*, list_*, prepare_*, submit_*). The verbs vary but do so meaningfully (retrieve vs. prepare vs. send), so the pattern stays predictable.
Six tools is well-scoped for a venue-info and private-event inquiry server. Each tool maps to a distinct visitor intent and earns its place, with no filler.
The surface covers discovery (business info, events, reservation guidance, private-event offerings) and the full inquiry lifecycle through to submission. Minor gaps remain: no way to check inquiry status or follow up after submit_inquiry, and no date/availability check beyond the daily-refreshed event listing.
Start here. What Arcana is, its hours, location, and contact links, every part of what it offers, and links to each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the agent knows this is a safe, repeatable, closed-domain read. The description adds that the response is a bundle of links and overview content, which is mildly useful context, but says nothing about return shape, freshness of data, or failure modes. Adequate given the annotation coverage, not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the imperative 'Start here' so the routing signal lands first. The second sentence's phrasing ('every part of what it offers, and links to each') is slightly loose but still earns its place by enumerating the payload.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only overview tool with no output schema, the description covers both what triggers a call and what comes back at a summary level. A bit more on the return structure (e.g., that links are URLs to booking/contact pages) would close the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the description misleads about inputs, and the absence of inputs is consistent with the empty object schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States concretely what the tool returns: Arcana's identity, hours, location, contact links, and an enumeration of its offerings plus links. That is a specific resource with a specific payload, and the 'Start here' framing helps position it against the sibling tools. It does not explicitly contrast itself with any named sibling, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Start here' is an unambiguous usage instruction that tells the agent to invoke this before the more specific siblings (reservations, events, inquiries). It gives positive guidance clearly but never names an alternative or states a when-not condition, leaving the routing inference to the reader.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns Arcana qualitative private-event offerings and the inquiry form link.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that the payload includes an inquiry form link, a mild behavioral clue; it does not say whether the offerings are static marketing copy or dynamic/pricing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is appropriately sized for a no-argument lookup, though it could have spent the same length on routing guidance instead of only content description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param, read-only tool with no output schema, the description should hint at the return shape; 'qualitative offerings' is vague about what fields or format come back. Combined with missing hand-off guidance to prepare_inquiry, an agent has enough to call it but not enough to use the result confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema carries no semantics to explain and the baseline of 4 applies. The description correctly does not waste words on nonexistent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns Arcana private-event offerings plus the inquiry form link. That is concrete enough to distinguish it from list_upcoming_events and get_reservation_options, though it only implicitly separates from prepare_inquiry/submit_inquiry without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no mention of the related siblings prepare_inquiry or submit_inquiry, which are the obvious downstream steps after this call. The agent must infer that this is the lookup to run when a user asks about private events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns walk-in guidance and the public Resy reservation link.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotent, non-destructive and closed-world, so the safety profile is covered. The description usefully implies this is a static-info lookup (guidance text plus a link) with no booking performed, but it does not state that no reservation is actually made — an important clarification for an agent talking to a user about booking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero filler, front-loaded with the return value. Nothing is wasted and nothing relevant is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description's job is to say what the agent gets back, which it does at a high level. It could go one step further on what 'walk-in guidance' contains (hours, party size limits) since no output schema documents the return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. Schema coverage is 100% regardless.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns') and names exactly what comes back: walk-in guidance and the public Resy reservation link. This clearly separates it from the inquiry-flow siblings (prepare_inquiry, submit_inquiry), though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not guidance. Nothing tells the agent to prefer get_private_event_offer for group/private bookings or that this tool covers only walk-in/public reservations, leaving routing between siblings to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns upcoming public events at Arcana as published on Resident Advisor and Luma, with a link to each listing. The list refreshes once a day, so the listing is the authority for tickets and changes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and non-open-world behavior. The description adds useful context beyond annotations: the list refreshes once a day and is the authority for tickets and changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded and purposeful. The first identifies the returned resource and sources; the second adds freshness and authority context without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is mostly complete: it says what is returned, where it comes from, that each listing has a link, and how fresh it is. It could be slightly richer about returned event fields beyond the link, but no major calling information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. The baseline for a no-parameter tool is 4, and the description does not create confusion about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns upcoming public events at Arcana from Resident Advisor and Luma, with listing links. The word 'public' also distinguishes it from sibling tools like get_private_event_offer and get_reservation_options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly establishes when the tool is relevant: for upcoming public events and ticket/change authority. It does not explicitly name alternatives or exclusions, such as routing private-event requests to get_private_event_offer, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepares a prefilled link for a private-event inquiry from whatever details are known. The person reviews the form and submits it.
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| budget | No | ||
| company | No | ||
| endTime | No | ||
| howHeard | No | ||
| lastName | No | ||
| occasion | No | ||
| eventDate | No | ||
| firstName | No | ||
| startTime | No | ||
| guestCount | No | ||
| additionalInfo | No | ||
| alternativeDate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false. The description adds useful context that this only prepares a link and does not submit the inquiry itself, but it omits details such as link expiry, whether any data is sent to the server, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core action and human-review step front-loaded. There is no redundant or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 undocumented parameters, no output schema, and no field-level schema descriptions, the description is too thin. It does not explain how unknown fields are handled, what the returned link looks like, whether the link can be reused, or how this relates to submit_inquiry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 13 parameters, so the description carries the full burden of explaining parameter semantics. It only conveys that partial information is acceptable ('whatever details are known') and gives no meaning, format, or constraints for fields like budget, eventDate, guestCount, or occasion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: preparing a prefilled link for a private-event inquiry. It also clarifies that the person reviews and submits the form, which implicitly distinguishes it from the sibling submit_inquiry tool, though it does not name that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage by saying the link is built from whatever details are known and then reviewed by the person. However, it does not explicitly say when to use this instead of submit_inquiry or other siblings, nor does it list exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a private-event inquiry to the Arcana booking team. Use only after the person has seen these details and asked you to send them. Requires first and last name, email, occasion, guest count, event date, start and end time, and one total budget amount in US dollars. Ask the person for anything missing. A reply goes to the email given.
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| budget | No | ||
| company | No | ||
| endTime | No | ||
| howHeard | No | ||
| lastName | No | ||
| occasion | No | ||
| eventDate | No | ||
| firstName | No | ||
| startTime | No | ||
| guestCount | No | ||
| additionalInfo | No | ||
| alternativeDate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a non-read-only, open-world, non-idempotent operation. The description adds useful context that it sends externally to the booking team, asks for missing details, and that a reply goes to the supplied email, though it does not discuss duplicate submissions or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action, then the precondition, required fields, missing-information instruction, and reply behavior. Every sentence adds useful information with no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main submission workflow and confirmation requirement well, but for a 13-parameter tool with no schema descriptions and no output schema, several optional fields and validation details remain unexplained. It is adequate to invoke correctly in common cases but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 13 parameters, so the description has to compensate. It usefully enumerates most core fields and clarifies one total budget amount in USD, but omits company, howHeard, additionalInfo, and alternativeDate, and gives no format guidance for dates or times.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 inquiry to the Arcana booking team. The recipient and precondition make it distinguishable from related siblings such as prepare_inquiry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition: use only after the person has seen the details and asked for it to be sent. It does not explicitly name prepare_inquiry as the preceding alternative, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_business_infoget_private_event_offerget_reservation_optionslist_upcoming_eventsprepare_inquirysubmit_inquiryRSVP to San Francisco AI events, book a room, borrow a VR headset, submit a 3D print, find members.
Live tables, release times and booking odds at hard-to-book restaurants in NYC, SF, LA and Chicago.
MONO Social — directory of places, events, and listings.
Editorial guide to restaurants and bars — hand-picked venues with opinions, not a places database
Add one secure layer between your agents and this server.
