Foobos: Boston and Denver concerts and comedy

Shows this weekend

shows_this_weekend

Read-onlyIdempotent

Concerts and comedy this Friday through Sunday (the remaining or upcoming weekend) in Boston (default) or Denver (city=denver). Use this for “what's on this weekend?”. Default sort=evening. free=true, event_type=comedy, and genre= match tonight/search. For “what should I see this weekend?” or date night prefer list_picks. Always cite url (/e/?id=). Do not rewrite to /event/. Paginated: default 20, max 50, always includes total.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "shows_this_weekend"
  }
}

Input Schema

Name	Required	Description	Default
`via`	No	Inbound UTM source written onto every Foobos deep link. Default muse.
`area`	No	Finder WHERE pill or neighborhood (Boston: cambridge, allston_brighton, somerville…; Denver: den_downtown, den_colfax, boulder…). Aliases: neighborhood, where.
`city`	No	boston (default: Boston, Cambridge, Somerville, Greater Boston) or denver (Denver, Boulder, the Colorado Front Range). Set denver for anything in Colorado.	boston
`free`	No	If true, only free shows (listing flag or price 0). Use for “what’s free tonight?”. Alias: is_free.
`mbta`	No	Boston only. If true, only MBTA-accessible rooms.
`sort`	No	evening (default): evening + upcoming first, not brunch-first chrono. time: raw chronological. popular: editorial picks first, then evening.	evening
`genre`	No	Finder mega-category (rock, punk, pop, jazz, soul, blues, folk, electronic, hiphop, reggae, classical, latin). Alias: genres. Comedy is event_type, not a genre. Joined from finder.json `g` — do not invent tags.
`large`	No	Hint alias of min_capacity=5000.
`limit`	No	Page size. Default 20, max 50. Do not request the full list — tonight is ~174 shows / ~36k tokens.
`genres`	No	Comma-separated megas. Alias of genre.
`is_new`	No	If true, only just-added (finder new).
`offset`	No	Rows to skip. Use with the returned total to page.
`is_free`	No	If true, only free shows (listing flag or price 0). Use for “what’s free tonight?”. Alias: is_free.
`all_ages`	No	If true, only all-ages (a/a).
`intimate`	No	Hint alias of max_capacity=500. Unknown capacity excluded.
`max_price`	No	Numeric price ceiling. Free passes; unknown price excluded.
`event_type`	No	comedy or music. Comedy is public event_type / finder ty=c, NOT a genre tag. Use for “comedy this week?”.
`max_capacity`	No	Known venues.json capacity ≤ N. intimate=true aliases max_capacity=500 (hint, not a stored flag).
`min_capacity`	No	Known venues.json capacity ≥ N. large=true aliases min_capacity=5000.
`neighborhood`	No	Alias of area.

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 cover the read-only, idempotent, closed-world, non-destructive profile, and the description adds genuinely new behavior: default sort=evening, pagination defaults/max, that a total is always returned, and that results must be cited via url. The token-cost warning (~174 shows / ~36k tokens) reappears in the limit parameter description, so that element is partly redundant, keeping it from a 5.

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?

Dense and front-loaded: scope first, then routing, then defaults, then citation rules, with no filler sentences. A few fragments ("free=true, event_type=comedy, and genre= match tonight/search") are terse to the point of being cryptic, which costs a point against a 20-parameter tool that rewards precision.

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?

For a tool with 20 optional parameters, no output schema, and full schema coverage, the description covers the essentials an agent needs: default city and sort, page size and max, availability of a total for paging, and the required citation field. It stops short of describing the shape of each returned listing (venue, time, price fields), which matters somewhat given there is no output schema.

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 description coverage is 100% and every parameter already carries a detailed description, so the baseline is 3. The prose adds only a little beyond the schema — that free=true, event_type=comedy, and genre= correspond to the tonight/search filters — and does not explain area aliases, capacity hints, or price-ceiling behavior, which the schema already does better.

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 names the resource (concerts and comedy), the exact time window (Friday through Sunday, remaining or upcoming), and the two supported cities with the default. It also distinguishes itself from list_picks and points at a specific sibling for the 'what should I see' phrasing, so an agent can route without opening a 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?

It gives an explicit trigger phrase ("what's on this weekend?"), an explicit exclusion with the alternative ("For 'what should I see this weekend?' or date night prefer list_picks"), and a usage rule for the returned links (do not rewrite /e/?id= to /event/). Both when-to-use and when-to-use-something-else 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?