Foobos: Boston and Denver concerts and comedy

One guide

get_guide

Read-onlyIdempotent

One guide's upcoming shows in the curator's order, each with the curator's note as why when there is one. With no city it uses the city where the guide has the most shows. Always cite each show's url. Paginated: default 20, max 50, always includes total.

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_guide"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Guide id from list_guides, e.g. rare-shows.
`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.
`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.2/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, closed-world, non-destructive, so the description's job is to add the rest — and it does: curator ordering, the optional `why` note, the city-fallback resolution rule, and pagination defaults (20/50) with a guaranteed total. It stops short of describing what happens on an unknown guide id or whether past shows are excluded from 'upcoming'.

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?

Four short sentences, front-loaded with the resource and ordering before the defaulting and pagination rules. Nothing is redundant with the schema's field descriptions except the paging numbers, which are restated as a usage contract.

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 carries the return-value burden and does name the key fields (`why`, `url`, total) plus ordering. It does not say what other fields each show carries, so an agent still has gaps about the response shape, but the call-critical information is present.

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 earns above that by explaining the omitted-city fallback ('uses the city where the guide has the most shows') and by restating the paging contract (default 20, max 50, always includes total) as a coherent rule rather than per-field prose.

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+resource+scope: 'One guide's upcoming shows in the curator's order'. That distinguishes it from list_guides (the catalog of guides) and from get_show (a single show) without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied by the resource shape — you call this when you already know a guide id and want its lineup — but there is no explicit when-to-use/when-not statement and no routing to list_guides or search_shows. The 'with no city' sentence describes a default, not a selection rule.

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?