area_intelligenceCoverage intelligence for a US city: how many providers file service, fiber availability share, and the dominant technologies — honest numbers with their grain and vintage stated. Give city and two-letter state.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name, e.g. 'Goshen' | |
| state | Yes | Two-letter state, e.g. 'IN' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety and determinism. The description adds meaningful context beyond annotations by promising 'honest numbers with their grain and vintage stated,' which informs the user about data quality and temporal provenance—a useful behavioral trait not captured in structured 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 concise and front-loaded, presenting the core purpose and expected outputs in a single, information-dense sentence. The second sentence gives necessary input instructions. Every clause adds value, with no filler or redundant repetition.
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?
Given the absence of an output schema, the description adequately outlines the return content (providers count, fiber share, technologies) and mentions metadata ('grain and vintage'). It is sufficient for a simple two-parameter read-only intelligence tool, though it could benefit from a more explicit statement about the output format or units.
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% for both 'city' and 'state', so the baseline is 3. The description reinforces the parameter format ('Give city and two-letter state') but adds little beyond the schema, except for clarifying the US-only scope, which is already implied by the word 'US' in the description. No new semantic depth is provided for the 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 clearly specifies the tool's function: it provides city-level coverage intelligence including number of providers, fiber availability share, and dominant technologies. It distinguishes itself from sibling tools by focusing on aggregate city statistics rather than individual availability checks or provider profiles.
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 stating the required inputs ('Give city and two-letter state') and the scope ('for a US city'), but it does not explicitly contrast with sibling tools or state when to choose this over alternatives. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct geographic or entity level: city, address, national, hex, and provider. There is no overlap in primary purpose; even the two 'intelligence' tools are clearly separated by scale (city vs. res-8 hex).
Most tools follow a noun_noun pattern (area_intelligence, industry_overview, location_intelligence, provider_profile), with one exception: check_availability uses a verb-led style. The deviation is minor and the names remain intuitive and predictable.
Five tools is well-scoped for a telecom data server, covering the core lookups needed without bloat. Each tool earns its place and the count aligns with a focused read-only domain.
The tool set covers the full spectrum of US broadband availability queries: address, neighborhood, city, national, and provider identity. There are no obvious dead ends—users can drill down from national to address or use provider_profile for disambiguation.