Foobos: Boston and Denver concerts and comedy

One venue

get_venue

Read-onlyIdempotent

One venue in Boston or Denver (id, id_variant, or slug) and a page of its upcoming shows. With no city it looks in both. Use for “shows at Paradise” when you already have the venue id/slug; otherwise search_shows with venue=. Paginated: default 20, max 50, always includes total. id is required. For the directory of rooms, use list_venues.

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": {
      "id": "<id>"
    },
    "name": "get_venue"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Venue id, id_variant, or slug (e.g. paradise, paradise_rock_club).
`via`	No	Inbound UTM source written onto every Foobos deep link. Default muse.
`city`	No	boston (default: Boston, Cambridge, Somerville, Greater Boston) or denver (Denver, Boulder, the Colorado Front Range). Set denver for anything in Colorado.	boston
`limit`	No	Page size. Default 20, max 50. Do not request the full list — tonight is ~174 shows / ~36k tokens.
`offset`	No	Rows to skip. Use with the returned total to page.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds pagination behavior (default 20, max 50, total always returned) plus the warning not to request the full list. However, "With no city it looks in both" conflicts with the schema's declared default of boston, leaving the actual default resolution ambiguous.

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?

Information is front-loaded and dense: scope, usage rule, pagination, required param, and the sibling redirect all in four sentences. Slight waste in repeating the pagination defaults and "id is required" that the schema already carries.

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?

With no output schema, the description still conveys the return shape (a page of upcoming shows plus a total) and paging strategy, which is what an agent needs to call it correctly. The unresolved city-default conflict is the one gap that could cause a wrong-region call.

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%, so all five parameters are already documented, including the limit ceiling and offset paging via total. The description mainly restates the limit range and the required id, and its statement about omitting city contradicts the schema default rather than clarifying it.

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?

Opens with a specific verb+resource: returns one venue (by id, id_variant, or slug) plus a page of its upcoming shows, scoped to Boston or Denver. It explicitly separates itself from search_shows and list_venues by name, so an agent can route 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete selection rule: use this for "shows at Paradise" when the venue id/slug is already known, otherwise use search_shows with venue=. It also redirects directory-style lookups to list_venues. Both the when and the when-not are stated.

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

All Foobos: Boston and Denver concerts and comedy 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?