Skip to main content
Glama
Sign In

Commerce for Agents

by com.commerceforagents
OverviewDiscussionsAdmin

Find US Internet Providers at an Address

compare-broadband
Read-onlyIdempotent

For questions like “what internet providers are at my address?”, “is fiber available?”, “fast home internet near me?”, “Starlink vs cable?”, “cheapest internet at my address?”, “how much is internet here?”, or “moving to an address, what internet can I get?”, look up US fixed broadband provider availability and speed by address or coordinates. Returns FCC availability and maximum advertised speeds by census block (not building-level), ranked by low latency, then speed. Address is sent to the US Census Bureau Geocoder to identify the census block; starting prices ("from $X/mo", with conditions, source and check date) for major national and regional providers (e.g. AT&T, Verizon, T-Mobile, Spectrum, Xfinity, Optimum, Starlink). Filter by minimum download speed or technology.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "compare-broadband"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNoLatitude, if no address is given.
lonNoLongitude, if no address is given.
addressNoUS street address incl. city and state or ZIP.
technologyNoOnly these technologies.
minDownloadMbpsNoOnly providers advertising at least this download speed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / context
      Removed value: -{
-  "description": "Why are you calling this tool? Briefly describe the user's goal.",
-  "type": "string"
-}
    • removedInput schema / required
      Removed value: -[
-  "context"
-]
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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 contributes real added context: results are census-block level rather than building-level (an accuracy caveat), the address is forwarded to the US Census Bureau Geocoder (a privacy/data-flow disclosure), results are ranked by low latency then speed, and prices carry conditions and a check date.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Front-loaded with the retrieval-friendly trigger questions, then the behavioral facts. The long enumerations of example queries and of major providers (AT&T, Verizon, T-Mobile, ...) are somewhat padded, but each clause still carries selection value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description carries the return-value burden and does so: it describes the shape of results (per-provider availability and max speeds, ranked, with starting prices and source/check date) plus coverage limits and the geocoding dependency. Given 0 required parameters, the 'address or coordinates' framing is the one remaining implicit point, but it is adequately signposted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 adds meaning beyond the field text: it frames address vs coordinates as interchangeable locating inputs and explains that the address is geocoded to a census block, which justifies why a street address (not just lat/lon) is accepted. The speed and technology filters are restated rather than enriched, hence not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — look up US fixed broadband provider availability and speed by address or coordinates — and the domain terms (broadband, internet providers) cleanly separate it from siblings like compare-mobile-plans, compare-vpn, and compare-esims. The returned artifact (FCC availability + max advertised speeds by census block) is named explicitly, so an agent can select it without reading the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

The opening list of sample questions (“what internet providers are at my address?”, “is fiber available?”, “Starlink vs cable?”) gives concrete triggers for invocation. It stops short of naming an alternative tool or stating when NOT to use it (e.g., non-US addresses are implicitly excluded only via 'US fixed broadband').

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

All Commerce for Agents toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources