Address profile: representatives, services, zoning

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

Annotations already cover the behavior profile (readOnly, idempotent, open-world, non-destructive), and the description's 'in one call' phrasing adds useful context that many sub-queries are executed internally. It doesn't disclose the geographic constraint (Mecklenburg County) on behavior or describe output richness beyond enumerating fields.

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: a front-loaded summary followed by a compact enumerated list. Every clause earns its place, and the summary line is placed first for fast scanning.

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-value explanation is not required. For a single-input, read-only aggregate lookup, the description plus annotations plus output schema give the agent everything needed to invoke it correctly and understand its scope.

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 schema clearly describes accepting either a street address or 'latitude,longitude' coordinates with examples. The description adds no additional parameter detail, but with a fully documented single parameter the baseline is 3–4; 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?

The description opens with a specific, distinctive framing — 'Everything that serves or governs a location, in one call' — and then enumerates the concrete data returned (council district, CMPD division, trash days, zoning, FEMA flood zone, tax parcel ID). This is a clearly defined aggregate-lookup tool that is readily distinguished from siblings like lookup_address or get_trash_and_recycling_schedule.

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 implies usage by framing itself as an 'in one call' aggregate, hinting that it should be preferred over several narrow sibling tools. However, it never states when NOT to use it, e.g. that lookup_address is lighter-weight for a bare address, or that the more specific sibling tools give fresher/dedicated data. Implied context only.

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