Remote Vegas

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

Goes well beyond the annotations by disclosing auth requirements (agent token), storage semantics (official platform embed, never downloaded or rehosted), and a post-submission moderation step before display. Leaves error/duplicate handling unstated, which is why it isn't 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with eligibility, then content constraints, then storage/moderation behavior. No redundancy or 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?

For a four-parameter mutation with no output schema, the description covers eligibility, accepted content, storage model, and moderation. Missing only guidance on rejection/failure behavior and how the returned record (if any) looks, which keeps it from a 5.

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 four parameters are already documented, and the description adds no field-level detail such as whether credit is required or how slug is resolved. The content constraints (public, credited) hint at credit's purpose but the baseline 3 applies when the schema does the work.

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 (attach a media link to a spot) and enumerates the accepted platforms and post types. The agent can distinguish this from update_spot_facts or suggest_spot 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.

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

Explicitly gates usage to partner agents with an agent token and constrains content to public posts showing the spot's work area, credited to its creator. It lacks an explicit when-not or a named alternative, but the eligibility conditions are 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, so the safety profile is covered. The description adds value beyond them by disclosing the return shape (schema.org place types with reasons and citable URLs) and the effect of the summarize mode, which annotations do not convey. Remaining gaps are minor: no mention of result limits or empty-result behavior.

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 dense sentences that front-load purpose, then usage, then return shape, with no filler. Some jargon ("NLWeb-style") and parenthetical type lists cost a little readability without adding much for an agent.

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 describing results and does so (place types, reasons, URLs, summarize mode). It is adequate for a three-parameter read tool, missing only edge details like truncation or no-match responses.

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 67%; query and top_k are documented in the schema, and the description explains what the otherwise-undescribed mode enum value "summarize" actually does. That is genuine added meaning, but top_k's default/limit behavior and the "list" mode are left to the schema alone, so the compensation is partial.

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 operation and resource (natural-language query over Remote Vegas) and scopes it to open questions that don't map cleanly to filters, which implicitly separates it from the filter-based siblings (search_spots, recommend_spot). It stops short of naming an alternative explicitly, so an agent must infer the routing rather than read it.

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?

Clear when-to-use guidance with a concrete example ("somewhere with a view to work on a Sunday morning") that shows the intended free-form case. There is no explicit when-not or named-alternative clause, so the negative side of the routing decision is left implicit.

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?

Adds substantive behavior beyond the annotations: the auth requirement (Remote Vegas agent token in the HTTP Authorization header, error without one) and the fact that submissions are queued for human moderation before counting. These are exactly the operational facts an agent cannot derive from readOnlyHint=false / idempotentHint=false.

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 compact sentences, front-loaded with the auth gate, then the use condition, then the moderation caveat. The partial '(workability 1-5, Wi-Fi, outlets, noise…)' enumeration trails off rather than resolving, but nothing is padding.

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 an 11-parameter write tool with no output schema, the description covers the critical unknowns: authorization, moderation latency, and the epistemic bar for values. It stops short of saying what a successful response contains or whether repeat check-ins at the same spot are allowed (idempotentHint=false).

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 only 27% across 11 parameters, so the description must compensate and it only partly does: it names workability 1-5, Wi-Fi, outlets and noise, leaving calls, crowd, light, seating, speed_mbps, note and slug meaning to the enums and terse schema text. The 'today' and 'never infer' framing usefully constrains values but doesn't explain the remaining fields.

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 pairs the verb 'report'/'check in' with a precise resource and scope: today's in-person observed conditions at a spot. It implicitly separates itself from update_spot_facts by insisting on first-hand observation rather than curated facts, but it never names that sibling explicitly.

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?

Strong, explicit gating: 'Partner agents only' with a token requirement, 'Use only to report conditions the user observed IN PERSON ... today', and 'Never invent or infer values' tells the agent exactly when not to call. What's missing is a named alternative for non-first-hand or historical data (e.g. update_spot_facts).

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 needs no restatement. The description earns credit for disclosing the shape of the read: it returns evidence behind each attribute, approved community check-ins, and credited creator posts, which tells the agent what depth of data to expect. It does not mention behavior on an unknown slug or any rate limits.

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 front-loaded sentence with the usage trigger first and the payload enumeration second; nothing is redundant. The payload list is dense with parentheticals but each item is informative rather than 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 and only one parameter, the description carries the return-value burden well by enumerating what comes back. It is essentially complete for a read-by-id tool; only error behavior for an invalid or unknown slug is unaddressed.

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 `slug` parameter is fully documented in the schema with an example, and the description only restates that lookup is by slug. With 100% schema coverage and one required param, the description adds no syntax, format, or validation meaning beyond the schema, 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 specific verb and resource ("get everything about ONE spot by slug") and enumerates the payload categories: address, opening hours, Wi-Fi/outlets/noise/calls with evidence, best time, access tips, check-ins, creator posts, links. The capitalized "ONE" distinguishes it from the list-oriented siblings search_spots and recommend_spot.

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 says to use it "after search_spots/recommend_spot (or when the user names a specific place)," which tells the agent both the sequencing and the direct-lookup trigger. It stops short of an explicit when-not or an alternative for bulk detail retrieval, but the context 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 and non-destructive behavior, so the safety profile is covered. The description's added value is limited to the return shape (zone plus spots with slugs and urls), which is modest given there is no output schema; it says nothing about pagination, result caps, or what happens for an unknown slug.

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 short sentences, both earning their place: the first front-loads the usage condition, the second states the return payload. No filler or redundancy.

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 full annotation and schema coverage, the description supplies the missing pieces an agent needs: when to call it and roughly what comes back. Edge-case behavior for invalid or ambiguous slugs is the only notable gap.

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% and the slug property already documents accepted forms (quadrant, area, landmark) with examples and a pointer to list_zones. The description adds nothing about the parameter, 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 a specific outcome: it returns the zone plus 'a compact list of its spots with slugs and urls', which tells an agent this is a zone-scoped listing operation. It doesn't explicitly contrast itself with search_spots or get_spot, so sibling differentiation is left to inference.

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 a clear trigger condition ('when the user wants ALL the work spots in one area') plus a concrete example utterance, which is enough to route an enumeration request here. It stops short of naming alternatives like search_spots for filtered queries, so there are no explicit 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 readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so safety is covered. The description adds real return-shape context (aliases and spot counts are included) that no output schema provides, though it omits whether the list is exhaustive or can be paginated.

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 the value proposition and examples front-loaded and the usage instruction second. Every clause carries information; nothing is repeated from 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 zero-required-parameter enumeration tool without an output schema, the description covers purpose, trigger, and returned fields well. Minor gap: it doesn't state whether the response is the complete zone list or varies with the kind filter.

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, but the description earns above baseline by mapping the three enum values onto concrete meanings: quadrants, named areas (Strip, Downtown, Summerlin, etc.) and landmark waypoints (UNLV, airport). It still doesn't say what happens when kind is omitted.

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 (learn which zone names/slugs exist) and enumerates the concrete zone families returned (quadrants, named areas, waypoints) plus aliases and spot counts. That makes it clearly distinguishable from get_zone, which fetches a single zone.

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?

"Call it when the user's area is ambiguous or before passing a zone to other tools" gives explicit trigger conditions and a sequencing rule. It stops short of naming get_zone as the alternative for resolving a single known zone, but the discovery-vs-lookup split 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 this a read-only, idempotent, non-destructive, closed-world operation, so the description only needs to add behavior beyond that — and it does: deterministic scoring over hand-checked data, a short reason attached to each pick, and the semantic categories the matcher understands. It does not mention result-count defaults or fallback behavior when nothing matches, which would have made it 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the trigger condition ('Use this FIRST when...'), followed by return behavior and scope limits. The parenthetical example and the capability list earn their space, though the 'understands quiet/focus, calls, outlets...' enumeration is slightly dense.

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 explaining that results are ranked spots with a short reason each. Combined with the 100%-covered input schema and full annotation set, an agent has enough to call this correctly; only edge cases like empty results remain unaddressed.

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 five parameters are already documented, and the description adds only marginal meaning — chiefly that zone names and constraints can be written into the free-text need rather than passed separately. Baseline 3 is appropriate since the schema does the heavy lifting.

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 — recommends top work/study spots ranked by a deterministic score — and bounds the domain to the Las Vegas valley. An agent can distinguish it from get_spot or list_zones, though it never names the closest sibling, search_spots, so the boundary there is inferred rather than stated.

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 explicit when-to-use framing ('Use this FIRST when the user asks where to work, study or take calls in Las Vegas/Henderson/Summerlin') plus a concrete example query, and an explicit when-not ('Not for places outside the Las Vegas valley'). It stops short of naming the alternative tool to fall back on for out-of-valley or non-recommendation 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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond that by disclosing the return shape ("compact rows" with name, category, area, hours, amenities, slug, url), which tells the agent this is a lightweight summary list rather than full records. It stops short of mentioning pagination behavior or the default row cap, which the schema carries instead.

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: purpose and scope, return shape, then sibling routing. Front-loading the verb and resource means an agent can decide on the first clause alone.

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 full schema coverage and no output schema, the description closes the remaining gaps by stating what the rows contain and where to go for deeper or ranked results. Nothing an agent needs in order 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 every one of the 12 parameters is already documented with examples and defaults. The description's parenthetical list of criteria (zone, category, Wi-Fi, outlets, quiet, calls, open now/at a time, near a point) largely restates those schema fields, though the "explicit criteria vs. name/keyword" framing does clarify the split between q and the boolean filters. Baseline 3 is appropriate since the schema does the heavy lifting.

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 ("list or filter Las Vegas work spots") and immediately enumerates the filterable dimensions plus the free-text alternative. It also names what it is not (recommend_spot, get_spot), so an agent can distinguish it from all relevant siblings without opening any 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?

It gives explicit routing: use this for explicit criteria or name/keyword lookups, use recommend_spot for "what's best for me" questions, and use get_spot with a slug for one place's full details. Both alternatives are named with the exact condition that selects them, leaving nothing to inference.

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 declare this as a non-read-only, non-destructive, non-idempotent write, and the description adds genuinely useful context beyond them: an agent token is required, and every submission enters a human review queue rather than taking effect immediately. It does not say what happens on duplicate submissions or what a successful call returns, which is a minor gap for a non-idempotent write.

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 with no filler, front-loaded with the access restriction and then the triggering condition. Every sentence carries distinct information: eligibility, trigger, and outcome.

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 five-parameter write tool with no output schema, the description covers access control, the trigger condition, and the review workflow, which are the highest-risk unknowns. The remaining gap is parameter-level guidance for the optional location fields and expected return behavior.

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 only 40%, and the description adds no meaning for lat, lng, or address — the three undocumented parameters. It does not state that name and why are the required fields, nor whether coordinates are optional helpers or necessary for a match. Only the Las Vegas framing gives any implicit guidance about location parameters.

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 action (submit a suggestion for a place that is missing from the dataset) and scopes it to Las Vegas venues suitable for laptop work. It implicitly separates itself from search_spots, but does not clarify how it differs from the sibling recommend_spot, which an agent could plausibly confuse with it.

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 a precise trigger: the user names a Las Vegas place good for laptop work and search_spots returns nothing. It also names the prerequisite (partner agent token) up front. There is no explicit statement about when not to use it, e.g. whether an existing spot should be updated with update_spot_facts instead.

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 it a non-read-only, idempotent, non-destructive write, but the description adds real behavior the annotations cannot express: trusted tokens apply immediately while others are queued for moderation, and every edit is audited with before/after values. The one gap is edit semantics — it never says whether omitted fields are left untouched or cleared, which matters for a partial-update mutation.

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?

Dense and front-loaded: the agent-token gate comes first, then the fact list, then moderation behavior, then the provenance rule. Some space is spent repeating enum values that the schema already enforces, which is the only real waste in an otherwise tight description.

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 an 11-parameter mutation with no output schema and thin schema documentation, the description covers access gating, moderation timing, auditing, and provenance well. It is still incomplete on two things an agent must get right: whether the update is partial or full-replacement, and what `reason` is for, despite that field being central to the audited edit workflow.

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 schema description coverage at 27% across 11 parameters, the description carries real burden and does partially compensate by restating the enum vocabularies (wifi yes|spotty|no, noise quiet|mixed|loud) and giving an hours format example. However, it omits `reason` entirely and says nothing about `slug` or `source_url` semantics beyond what the schema already documents, leaving the most audit-relevant field unexplained.

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: "Correct first-hand facts for one spot," followed by the exact fact categories it governs (hours, wifi, outlets, noise, calls, best_time, notes, access_tips). An agent can distinguish this from sibling tools like add_media_link or suggest_spot without opening the schema. It stops short of naming which sibling to use when a spot does not yet exist.

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?

"Partner agents only (agent token required)" gives a clear access precondition, and "Never copy facts from Yelp or Google" plus "first-hand facts" define what input is acceptable. Missing is explicit routing versus suggest_spot (new venue) or get_spot (read), so the agent must infer that this is for correcting an already-listed spot.

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