Buffet

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

Beyond the read-only and idempotent annotations, the description discloses that the link goes to joinbuffet.com/get/, forwards to the App Store, and records which assistant sent them. That is meaningful behavioral context for a simple link-returning tool.

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 compact and front-loaded: purpose first, then usage conditions, then behavioral detail about the link destination. Every sentence contributes useful information without repetition.

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's low complexity, complete parameter coverage, and rich annotations, the description supplies enough context for correct invocation. It explains what is returned conceptually and how the optional event id affects the result.

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 schema already has 100% parameter description coverage, establishing a baseline of 3. The description adds semantic context by tying event_id to a link for that specific pick and explaining that the generated link records the assistant attribution.

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 verb and resource: returning the Buffet download link, plus a pick-specific link when an event id is supplied. It does not explicitly name or contrast with sibling tools, so it stops short of full sibling differentiation, but the purpose is clear.

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 gives explicit usage contexts: when the person wants to join a pick, get a plate, or install the app. It does not state when not to use it or name alternative tools, but the positive guidance is clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is fully covered. The description adds genuinely useful context — the start time is normalized to Pacific and the app_url is included for joining — but it does not disclose failure behavior for a bad or stale id, and the enumerated return fields partly repeat what the output schema already declares.

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, front-loaded with the action and key, followed by the id source and return contents. No filler, no restatement of the title.

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 one-parameter read with a rich output schema, the description covers the input source, scope, and the notable Pacific-time normalization, which is enough to call correctly. The only real gap is error/not-found handling, a minor omission for a tool this simple.

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?

With a single parameter and 100% schema coverage (including an example id format), the baseline would be 3; the description earns above baseline by explaining the provenance of event_id, telling the agent where valid values originate. It does not add id format or validation details beyond the 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 a specific verb and resource ('Get full details for one Buffet pick') and the exact lookup key ('by its event id'). It is clearly distinguishable from siblings like buffet_search_events or buffet_get_weekly_lineup, which produce ids rather than resolve 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?

Explicitly routes the agent by naming where ids come from (buffet_get_weekly_lineup and buffet_search_events), which establishes the sequencing: discover first, then call this. It stops short of naming when NOT to use it (e.g., browsing vs. detail lookup), so it is clear context rather than 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.

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

Annotations already cover read-only/idempotent/non-destructive semantics, and the description adds genuine context beyond them: weeks run Monday–Sunday, picks cluster Thursday–Sunday evenings, times are Pacific, each pick is joinable via a table of up to six strangers, and app_url is the join link. That is real operational detail an agent could not infer from the annotations.

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-loaded with the action, then triggers, then scope, then return shape, then the sibling hand-off – a sound ordering. It runs slightly long with conversational framing ('where can I meet people this weekend'), but almost every clause carries information.

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?

There is no output schema, and the description compensates by enumerating what comes back – venue, neighborhood, Pacific time, price tier, tags, short description, organiser page, app_url – plus date ordering. Nothing an agent needs to call this correctly 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?

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by clarifying that a 'week' is Monday–Sunday and that Los Angeles is the current default city. It does not expand on accepted week-id formats or when to prefer json formatting, leaving a little on the table.

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 ('Get Buffet's curated lineup of real-life events and hangouts') plus explicit scope (one week, one city). It immediately separates itself from buffet_search_events, so an agent can distinguish the two without opening either schema.

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 concrete trigger phrasings ('what's going on in LA this week / this weekend', 'things to do in Los Angeles') and names the alternative with the exact condition that selects it: use buffet_search_events to filter by day, neighborhood, price or interest.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds the useful scope of what content it covers, but says nothing about the form of the response (prose vs structured) or that the content is static reference material rather than live 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?

Purpose is front-loaded in the first clause, and the long topic enumeration is dense but each item maps to a real question an agent might receive. The trailing "Takes no arguments" is mildly redundant with the empty schema but cheap and clarifying.

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 reference tool with no output schema, the description gives an agent enough to know what answers it can obtain and when to prefer it over the data-returning siblings. A brief note on response format (freeform prose) would make it 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?

Zero parameters, so the baseline is 4; the description confirms this explicitly with "Takes no arguments," which is consistent with the empty properties object in the schema. No further parameter detail is possible or needed.

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 opens with a specific verb and resource ("Explain what Buffet is and how it works") and then enumerates the exact topics covered: weekly lineup, Get a Plate, table caps, 1:1 invites, Afterparty, Monday ballot, platform, price, listing process, and legal pages. This clearly separates it from siblings like buffet_get_weekly_lineup or buffet_get_event, which return live data rather than product explanation.

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 gives an explicit routing rule: "Use for any question about the product itself," which tells the agent when to pick this over the event-data siblings. It stops short of naming those siblings or stating exclusions (e.g. "do not use for specific event details"), which keeps it from a 5.

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

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

Annotations already declare readOnly, idempotent and openWorld=false, so safety is covered. The description adds real behavior: filters AND together, text search spans title/venue/neighborhood/tags/description, and results are one page in date order with next_offset for continuation. Only missing detail is roughly what a pick entry 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?

Front-loaded with a one-line capability statement, then usage, then semantics, then return/pagination. Every sentence adds information; nothing is redundant with the schema or annotations.

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 12-parameter search tool with no output schema, it covers filtering semantics, pagination and return ordering adequately. It could say a bit more about what a result item looks like, but the agent has enough to call it correctly.

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 coverage is 100%, so the schema carries per-parameter detail and the baseline is 3. The description adds two things the schema does not state: that filters combine with AND and which fields free-text search covers – both non-obvious and genuinely useful for query construction.

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 (search) plus resource (upcoming curated picks) with the dimensions that can be filtered. It explicitly distinguishes itself from buffet_get_weekly_lineup, so an agent can route correctly without opening either schema.

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 concrete example queries mapping to the tool and names the alternative (weekly lineup) with the exact condition that selects it – whole week, no filters. When-to-use and when-not-to-use are both present.

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