Commerce for Agents

Compare US Mobile Phone Plans

compare-mobile-plans

Read-onlyIdempotent

Compares and ranks US mobile phone plans, cheapest first, from a curated catalog of carrier and prepaid (MVNO) plans, each price checked on the provider's own page, by 12-month average cost per line, with any promo price shown alongside. The catalog is a selection, not the whole market; each result states how many plans and providers it covers and the oldest price-check date. Inputs: number of lines, and optionally data need, budget per line, prepaid or postpaid, must-have features and preferred network. No address or location is used, so network coverage is not checked; each result carries a coverage note. Keywords: cheapest phone plan, compare cell phone plans, cell phone plan, mobile plan comparison, switch carriers, unlimited data plan, family plan, prepaid vs postpaid.

Input Schema

Name	Required	Description
`lines`	No	Number of phone lines to price.
`data_need`	No	Minimum data: light ≥2GB, moderate ≥5GB, heavy ≥20GB, unlimited = unlimited plans only.
`must_haves`	No	Required features: hotspot, 5g, premium_data (deprioritization-free), unlimited_data.
`budget_per_line`	No	Max USD/month per line.
`preferred_network`	No	Preferred underlying network, e.g. AT&T, Verizon, T-Mobile.
`prepaid_or_postpaid`	No	Restrict to prepaid or postpaid plans; omit for both.

Output Schema

Name	Required	Description
`lines`	Yes
`plans`	Yes
`source`	Yes
`message`	No
`priceNote`	Yes
`coverageNote`	Yes
`selectionNote`	Yes	Curated selection of N plans from M providers, not the whole market.
`catalogPlanCount`	Yes
`oldestVerifiedDate`	No	Oldest verified_date among the plans shown.
`catalogProviderCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026
- addedOutput schema / properties / plans / items / properties / offerTargetUrl
```
Added value: +{
+  "description": "Where offerUrl redirects to.",
+  "type": "string"
+}
```

Changed2 schema fields changedSep 26, 2026

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"
-]
```

AddedSep 26, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly/idempotent/openWorld=false) by disclosing data provenance (prices checked on the provider's own page), the comparison metric (12-month average per line with promo prices shown alongside), and the transparency guarantees each result carries (plan/provider coverage counts, oldest price-check date, coverage note). This is exactly the extra context annotations cannot supply.

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-loads the core action and ranking method, then layers scope limits and inputs efficiently. The trailing 'Keywords:' list is retrieval-oriented padding that an agent gains little from, which keeps it from a 5.

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?

For a read-only comparison tool with an output schema, the description covers everything an agent needs: what is compared, how it is ranked, catalog limitations, what each result reports, and the absence of location-based coverage checking. Nothing material is missing.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all six parameters including enums and thresholds. The description only restates the parameter list ('number of lines, and optionally data need, budget per line, prepaid or postpaid, must-have features and preferred network') without adding syntax or semantics beyond it, so the baseline 3 applies.

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 (compares and ranks), a precisely scoped resource (US carrier and MVNO phone plans), and the ranking rule (cheapest first by 12-month average cost per line). This clearly separates it from siblings like compare-broadband, compare-esims, and compare-tariffs without needing their schemas.

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?

Gives clear context on when the tool applies, including that the catalog is a curated selection rather than the whole market, and that no location is used so coverage is not checked. It does not explicitly route to or away from a sibling (e.g. tariff-details for a single plan), so it stops short of a 5.

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 tools Inspect

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

Need Help?