Prox

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, covering the safety profile. The description adds only example queries and does not explain proximity behavior, category handling, default radius, result limits, or anything else beyond 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?

The description is short and front-loads the core purpose. The example queries are useful and not excessive, though they take space that could have documented parameters.

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 five parameters, 0% schema description coverage, and no output schema, the description is too thin for correct invocation. It establishes what the tool does but leaves latitude/longitude handling, radius units, category enum meaning, and result limits completely undocumented.

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% across five parameters, and the description does not explain lat/lng, limit, category, or radius_miles. The examples hint at category use, but they do not map to the actual enum values or define any parameter 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?

The description gives a clear verb and resource: "Find shops near a location." It is understandable without opening the schema, though it does not explicitly distinguish itself from siblings such as find_open_houses or whats_live_nearby.

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 example queries ("coffee shops near me", "where can I get lunch nearby?", "is there a bookstore around here?") make the intended use context clear. However, there are no explicit exclusions or direct comparisons to the sibling tools.

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 covered. The description adds no behavioral context at all - no return shape, no result limits, no note that the 'this weekend'/'today' phrasing in its own examples has no corresponding temporal parameter in the schema, which is a meaningful omission.

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 short purpose sentence followed by illustrative queries - front-loaded and easy to scan. The examples are slightly repetitive but serve as usage signaling 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?

For a 4-parameter tool with 0% schema coverage, no output schema, and annotations that only cover safety, the description leaves the caller without unit, limit, or result-shape guidance. Its temporal examples also raise expectations the parameter list cannot satisfy.

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% across 4 parameters, so the description must compensate and largely does not. 'near a location' loosely maps to lat/lng and 'nearby' hints at radius_miles, but limit and radius_miles units/defaults/bounds are undocumented anywhere.

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 ('Find open houses') plus the spatial scope ('near a location'), which cleanly separates it from find_nearby_shops and whats_happening. It does not explicitly name or contrast a sibling, but the resource is unambiguous.

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?

Three example utterances imply the intended context (weekend/today/nearby lookups), which is more than nothing, but there is no explicit statement of when to prefer this over siblings like whats_happening or find_nearby_shops, and no exclusions or prerequisites.

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 openWorldHint=false, so the safety profile is covered. The description adds that results blend two source types, which is genuine context, but says nothing about result ordering, freshness, or how radius/limit affect 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 compact sentences with the core purpose front-loaded and examples placed after, which is the right order. The examples are somewhat repetitive (all three express essentially the same 'what's nearby' intent), which trims some value.

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 geo-query with no output schema, the description should explain the radius/limit controls and what the returned items look like. It does communicate the content types returned, but leaves the spatial scoping parameters entirely unexplained.

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% across four parameters, and the description only vaguely implies a location via 'near a location'. limit and radius_miles are never mentioned, nor are expected formats or units for lat/lng, leaving the agent to guess from bare type declarations.

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 verb-resource combination (see what's going on near a location) and clarifies it aggregates two content types, shop posts and open houses, together. That implicitly differentiates it from find_nearby_shops and find_open_houses, but the relationship to whats_live_nearby is never addressed.

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?

Three example user utterances ('anything to do near me?', 'what's going on around here?', 'what should I do nearby today?') give useful intent-matching cues for when to call it. However, there is no explicit guidance on when to prefer find_nearby_shops, find_open_houses, or whats_live_nearby instead, nor any prerequisites 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 the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description need not cover that. It adds the meaningful behavioral trait that results are time-sensitive 'right now' postings, but says nothing about volume, pagination behavior, or how limit/radius affect 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?

Two sentences with the purpose front-loaded, followed by illustrative example queries. It is tight with no padding, though the example phrasings are somewhat redundant with one another.

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 no annotation describing return values, yet the description never explains what a result contains (shops, posts, deals, timestamps?). Combined with zero-coverage parameters and no return-format guidance, an agent cannot predict the response shape or the effect of limit/radius_miles.

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% and none of the four parameters (lat, lng, limit, radius_miles) have descriptions, so the description carries the full burden. It only loosely implies a location ('near a location'), giving no meaning to lat/lng format, the units of radius_miles, or the default/range of limit.

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: 'See what shops are posting right now near a location,' which conveys a real-time feed of nearby shop posts. It is clearer than the generic siblings (find_nearby_shops, whats_happening) because of the 'live/right now' framing, but it never explicitly contrasts itself with find_nearby_shops, which overlaps heavily.

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 example queries ('what's live near me?', 'any deals nearby right now?') imply the conversational intent this tool serves, which is useful context. However, there is no explicit when-to-use versus when-not guidance, and no mention of the closely related find_nearby_shops sibling, leaving the routing decision to inference.

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