saved.rsvp

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds meaningful output context: the guide is returned in the curator's order with their ranks and quotes, which is beyond what annotations or schema disclose.

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 efficient sentence that front-loads the resource and its distinguishing content with no wasted words.

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 output schema, the description usefully conveys what the returned guide contains (order, ranks, quotes). It does not mention pagination or the creator/guide lookup relationship, but those are covered by the schema and annotations.

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 all parameters (creator, guide, limit) are already documented in the schema. The description adds no parameter-specific detail, so the baseline of 3 applies.

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 the specific resource (a whole guide) and its content (curator's order, ranks, quotes), which distinguishes it from get_place and search_places. It lacks an explicit verb and does not name sibling alternatives, but the resource scope 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?

The phrase 'A whole guide' implies you use this when you want the complete ordered guide rather than a search or single place, but there is no explicit when-to-use guidance or named alternative (e.g. 'use search_places for queries').

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value by disclosing the payload contents (address, what to order, rank, guide, co-recommenders), but says nothing about behavior when no review exists for that place/curator pair or about lookup-by-name vs id fallback semantics.

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 tight sentence with zero filler, and the resource scope ('one curator's full review of a place') is front-loaded before the field enumeration. It opens with a noun phrase rather than an action verb, which slightly weakens immediacy for a tool called get_place.

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 output schema, the description carries the return-value burden and does so by listing what's included. Annotations cover safety, and both required params are documented; the only real gap is behavior when the curator has no review for that place.

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 both parameters are fully documented in the schema, which sets the baseline at 3. The description reinforces that the pair (one curator + one place) constitutes a single review, but adds no format, id syntax, or disambiguation detail 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?

The description names a specific resource — one curator's full review of a place — and enumerates what it contains (address, what to order, rank, guide, other recommending curators). It implicitly reads rather than writes, and the 'one curator's' scoping helps separate it from search_places, but it never names a sibling or states the retrieval verb outright.

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 reference to any of the sibling tools (get_guide, who_recommends, search_places), even though 'which other curators recommend it too' overlaps conceptually with who_recommends. The agent must infer that this is the per-curator detail lookup requiring both a place and a curator.

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 and closed-world, so the safety profile is covered. The description's only added behavior signal is that results include coverage areas and guides, which is useful content context but no more than one clause.

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 tight sentence with no waste. It leads with the resource, though starting with an action verb ("List the food curators…") would front-load the operation more clearly.

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 output schema, the description is the only source for what comes back, and it gives a partial answer (coverage, guides). It omits anything about result size, ordering, or returned curator fields, which leaves real gaps for an agent planning a call chain.

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; baseline 4 applies.

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?

Names the resource (food curators on Goodtimes) and hints at returned content (what they cover, their guides), but is phrased as a noun phrase with no verb, so it only implicitly reads as a list operation. It also doesn't distinguish itself from siblings like who_recommends or get_guide, which also touch curator/guide data.

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 guidance on when to call this versus who_recommends (also curator-related) or get_guide. The agent has to infer from the name alone that this is the entry-point listing tool.

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 read-only, idempotent, non-destructive, closed-world behavior, so the description is not burdened with safety disclosure. It usefully adds that results carry curator attribution, rank, guide, a quote, and a link, which compensates for the missing output schema. It says nothing about result counts, pagination, or rate limits beyond the schema's limit field.

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?

Three sentences, front-loaded with what the tool does, followed by how to query and what comes back. No filler; the result-fields sentence earns its place because there is no output schema.

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 six-parameter, all-optional search tool with annotations covering safety and no output schema, the description covers purpose, input modes, and return shape. Remaining minor gaps (pagination/count behavior, interaction with limit) are not critical for correct invocation.

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 83%, so the schema already documents most parameters. The description reinforces the query parameter by giving examples ('greasy spoon shoreditch', 'pie and mash', 'dim sum') and explains combining query with coordinates, but adds no meaning for creator, limit, or radius_km beyond what the schema states. Baseline 3 is appropriate.

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 ('Search restaurants, cafés and bars recommended by food curators on Goodtimes') and makes the scope unambiguous. It does not, however, differentiate itself from siblings such as get_place or who_recommends, so an agent must infer the boundary.

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?

The description gives positive usage guidance ('Give words ... and/or coordinates to search nearby'), which implies the two search modes. It never states when to prefer this over get_place, who_recommends, or get_guide, and names no alternatives or exclusions.

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 a safe, idempotent, closed-world read, so the safety profile needs no restating. The description usefully adds that the payload is curator identities plus their commentary, but it omits name-matching semantics (exact vs fuzzy) and what is returned when no curator recommends the venue.

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 compact sentence that front-loads the subject and immediately states both halves of the return value. No filler, though 'a specific restaurant' is slightly redundant with 'a venue' in 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 single-parameter read tool with rich annotations and no output schema, the description covers what the tool returns and what it is scoped to. The only real gap is lookup semantics when the venue name is ambiguous or unmatched, which is minor at this complexity level.

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 single parameter has 100% schema description coverage ('The venue’s name'), so the schema does the documenting. The description adds only a marginal nuance by calling the target 'a specific restaurant', and does not clarify format (full address, city qualifier) or matching behavior.

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 ('Check') and a specific output ('which curators on Goodtimes recommend it, and what they say'), which is clearly distinct from get_place (venue details) and search_places (discovery). It does not explicitly name the siblings, so differentiation relies on inference from the query shape.

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?

Usage is implied by 'Check a specific restaurant', suggesting the venue must already be known, which points away from search_places. However, there is no explicit when-to-use guidance, no statement of prerequisites (must the venue already exist in Goodtimes?), and no named alternative such as get_place for full details.

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