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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely new behavior: the data is live, results carry UTC times and city-level granularity, and online rooms are included. It stops short of stating freshness guarantees or result caps, keeping it from 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 core scope statement, then supporting detail and examples; each sentence carries information. The trailing quoted query examples are slightly redundant with the examples given usage, but they ground the tool in real phrasing.

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?

An output schema exists, so return values need not be documented, yet the description helpfully notes the when (UTC) and where (city level) fields. For a zero-required-param, open-world discovery tool this is nearly complete; only the limit parameter and lat/lng pairing are 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 75% and the four parameters are largely self-describing (lat/lng paired, city as fallback when no coordinates). The description only implies location input via 'near a city' and never addresses lat/lng pairing or the limit bound, so it adds little beyond the schema — baseline 3.

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 (real gatherings) with a concrete scope (next seven days, near a city), and enumerates what is included (services, prayer nights, studies, meals, online rooms). It explicitly distinguishes itself from the sibling find_gatherings_near as the same live data bounded to one week, so the agent can route between them without opening schemas.

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?

Names the alternative (find_gatherings_near) and gives the selecting condition (bounded to one week / pick a day), plus three natural-language query exemplars that clarify the intended use. It does not explicitly exclude or route to gatherings_tonight, so the when-not guidance is left partly implicit.

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