SnagRes

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world). The description adds genuinely useful provenance context — the ranking is 'measured rather than opinion' and based on reachability — but says nothing about pagination, default limit, or result ordering ties.

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 with no filler; the ranking criterion and the routing hint are both front-loaded. Every clause earns its 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?

There is no output schema, so the description should clarify what comes back; it only implies a ranked list without describing fields or length behavior. With two optional parameters whose defaults are undocumented, an agent knows the intent but not the mechanics of a call.

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 description coverage is 0%, so the description must carry the load, and it largely does not. 'In a city' weakly gestures at the city parameter but never explains the enum values or that city is unrestricted, and the limit parameter (its default, range, or interaction with ranking) is entirely unaddressed.

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 resource and the ranking criterion ('hardest restaurants to book in a city, ranked by how rarely a table is actually reachable'), which is more than a restatement of the name. It implicitly distinguishes itself from siblings like open_now and when_does_it_release by framing itself as a measured difficulty ranking, but never names a sibling to sharpen 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?

Gives a concrete trigger ('what are the hardest reservations') plus a secondary purpose ('to set expectations'). It does not say when NOT to use it or point to an alternative tool such as when_does_it_release for release timing, so it stops short of full routing 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 declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely useful scope context ('anywhere', i.e. no filtering, and that a timestamp accompanies the result), but says nothing about behavior when nothing has been spotted, staleness of the 'most recent' value, or response shape.

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 tight sentences with zero filler: what it returns first, intended use second. Nothing could be cut without losing 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?

With no parameters, no output schema, and full annotation coverage, the description supplies the one thing structured fields cannot: that the result is global (anywhere) and carries a timestamp. Minor omission is what happens on an empty/never-observed state.

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 no 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?

States a specific resource and scope: the single most recent table seen open anywhere, plus the timestamp it was spotted. It is distinguishable from siblings like hardest_tables or when_does_it_release, though it never names or contrasts with the overlapping-sounding open_now.

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 two intended uses ('show the service is live', 'a sense of what is moving right now'), which implies a liveness/pulse-check role. However it offers no when-not guidance and does not address how it differs from the sibling open_now, which an agent could easily confuse it with.

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 establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description earns real credit on top of that by disclosing the aggregation sources (Resy, OpenTable, Tock, SevenRooms), the exactness of returning times, and the minute-level volatility of the data — meaningful operational context an agent planning a call would not get 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?

Three short sentences, front-loaded with the resource and scope, then the when-to-use trigger, then the volatility caveat. No filler, no repetition of the title, and each sentence carries distinct 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?

With no output schema, the description does the work of indicating what comes back ('exact times') and how fresh it is, which is the key expectation to set for a live-availability tool. It stops short of describing result volume, whether results are ranked, or what an empty response means, but nothing required for a correct invocation is absent.

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 (city enum with default, limit cap of 50) are already fully documented in the schema. The description names the cities and the notion of 'right now' but adds no syntax, range, or defaulting details beyond what the schema provides, so the baseline 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?

States a concrete verb-and-resource ('tables bookable right now') plus scope: four named cities and four booking platforms with exact times. It is clear which resource is returned, but it never contrasts itself with siblings like hardest_tables or last_table_spotted, and the phrase 'hardest restaurants' actively overlaps with hardest_tables, so an agent must infer the split.

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?

'Use this when someone asks what they can get tonight or this week' gives a clear triggering context, and 'changes by the minute' reinforces that this is for immediate/imminent availability rather than research. What is missing is the negative case: nothing says to prefer hardest_tables for background research or when_does_it_release for future drops.

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, and closed-world behavior, so the safety profile is covered. The description adds valuable provenance by stating the figures are measured from SnagRes's own availability checks and lists the exact measured fields, though it does not discuss data freshness or any limitations.

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, each earning its place: what the record contains, when to use it, and where the data comes from. The most important content is front-loaded with no filler.

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 must carry the burden of return content, and it enumerates the key metrics well. It does not specify the exact return structure or units, but for a one-parameter lookup tool it is nearly 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?

Schema description coverage is 100% and the single parameter already has an example. The description adds no syntax or format detail beyond restating that the data is for one restaurant, so 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?

The description states a specific resource and enumerates the data it returns (two-top/four-top availability, dates checked, booking window, release hour), so the agent knows exactly what this tool provides. It is clear on its own but does not explicitly differentiate itself from siblings like when_does_it_release or open_now.

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 use case: answering whether a restaurant is realistically gettable or why someone keeps failing to book it. However, it does not name when to prefer an alternative sibling tool or state any 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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuine context beyond that: the answer is per-restaurant rather than per-platform and each restaurant sets its own hour and window, which shapes how the agent should interpret results.

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?

Four short sentences, front-loaded with what the tool returns before the usage examples and the per-restaurant caveat. Each sentence contributes something, though the opening fragment is slightly clipped.

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 burden of explaining returns, and it does so for both modes (booking window and exact release day/time) plus the per-restaurant scoping. Nothing essential for calling it correctly appears to be 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 both parameters are already documented, setting a baseline of 3. The description adds conditional semantics beyond the schema: supplying a dining date yields the exact day and local time a date becomes bookable, while framing the no-date behavior as the booking window.

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 capability: determining when a restaurant releases new bookable dates and how far ahead it books, with a concrete example query. It is clearly distinct from availability-style siblings like open_now, though it never names an alternative tool to route away from.

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 trigger phrasing ('Use this for "when can I book X for Saturday" or "when do X reservations open"'), so the agent knows the intent that maps here. It lacks explicit when-not conditions or named sibling alternatives, capping it below 5.

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