Call scripts to lower bills in the US and UK, low-cost plans you may qualify for, and when to call.
Scored across 3 tools
Each tool serves a clearly distinct purpose: finding help programmes, generating a negotiation script, and creating a calendar reminder. The descriptions use specific user queries and output types, leaving no overlap or ambiguity for an agent to misselect.
All tools follow a consistent verb_noun pattern using snake_case: get_bill_help, get_bill_script, get_call_reminder. The 'get_' prefix and noun-based names are predictable throughout.
With only 3 tools, the set is well-scoped and each tool earns its place by covering a distinct step in the bill-lowering workflow. The count is neither thin nor excessive for the focused domain.
The tools cover the full lifecycle: discovering assistance programmes, obtaining a negotiation script, and setting a reminder to act before a deal ends. No obvious gaps exist, and the flexible inputs (bill type, provider, or both) handle various scenarios.
Official help programmes for a bill. Use for "is there help paying my internet bill?", "is there a broadband social tariff?", "help with my energy bill in the UK", "help with my electric bill", "cheap internet for low income", "does Xfinity have a low-income plan?". Returns programmes with who qualifies and how to apply
| Name | Required | Description | Default |
|---|---|---|---|
| bill | Yes | internet, mobile, electricity (or heating, gas), water, tv, streaming, car insurance, home insurance, credit card, council tax (UK), or a provider name. Up to 60 characters. | |
| state | No | US state name or two-letter code. For electricity, adds the state's energy discount programme (California, New York, Ohio, New Jersey, Pennsylvania, Georgia). England, Scotland, Wales, Northern Ireland or UK gives the UK answer. | |
| country | No | Two-letter country code. GB (or UK) gives UK schemes (Ofcom social tariffs, Warm Home Discount, WaterSure, Council Tax Reduction). Defaults to the caller's country, else US. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description supplements this by disclosing the return shape ('programmes with who qualifies and how to apply') and the geographic scoping of results via state/country. It does not discuss rate limits or failure cases, but the bar is lower with full annotation coverage.
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-loads the one-line purpose, then spends the rest on intent examples followed by a short return-value clause. The query list is long but each phrase maps to a real routing case (US vs UK, energy vs internet, provider-specific), so it earns its space rather than padding.
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?
For a three-parameter, read-only lookup with no output schema, the definition covers purpose, triggering intents, the geography mechanics and a summary of what comes back. Nothing an agent needs to invoke it correctly is missing; only the absence of explicit sibling/alternative guidance keeps it from being fully complete.
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% and the schema already explains bill types, the state-to-country interaction, and the GB/UK scheme variants in detail. The description adds no parameter syntax or format information beyond that, so baseline 3 is appropriate here.
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 (official help programmes for a bill) and what it returns (programmes with eligibility and how to apply). The included user-phrased queries ('is there a broadband social tariff?', 'help with my energy bill in the UK') make it unmistakably distinct from get_bill_script and get_call_reminder, which handle talking points and reminders respectively.
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?
Gives rich when-to-use context via seven example questions spanning internet, energy, low-income broadband and provider-specific plan lookups. However, it never names a sibling tool or states when NOT to use this tool, so the alternatives remain implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A call script to lower a bill. Use for "help me lower my Comcast bill", "get my BT broadband cheaper", "lower my Council Tax", "script to get a better phone plan", "how do I negotiate my car insurance?", "lower my credit card interest", "I pay for too many streaming services". Give the bill type, the provider, or both. If the provider doesn't sell that bill, provider_note says so and the general script is returned
| Name | Required | Description | Default |
|---|---|---|---|
| bill | No | internet (or broadband), mobile, tv, streaming, car insurance, home insurance, electricity (or energy, gas), water, credit card, gym or council tax (UK). Up to 60 characters. | |
| state | No | US state name or two-letter code. For electricity, adds the state's energy discount programme where there is one. England, Scotland, Wales, Northern Ireland or UK gives the UK answer. | |
| country | No | Two-letter country code. GB (or UK) gives UK scripts, schemes and complaint routes; otherwise it picks the Amazon store in own_modem (US by default; IE uses amazon.co.uk). Defaults to the caller's country. | |
| provider | No | Company name, for example Comcast, Xfinity, Spectrum, AT&T, Verizon, Frontier, T-Mobile, Cox, Optimum, Mediacom, Astound, DIRECTV, DISH, GEICO, Progressive, State Farm, Allstate, USAA; UK: BT, Sky, Virgin Media, TalkTalk, Vodafone, EE, O2, Three, Plusnet, NOW Broadband, Hyperoptic, British Gas, Octopus, EDF, E.ON Next, OVO, ScottishPower. Up to 60 characters. | |
| deal_ends | No | The date the current promotional price, contract or insurance policy ends, YYYY-MM-DD. Adds call_by (about 30 days earlier, on a weekday, or today if that has passed) and add_to_calendar, a link to a calendar reminder with the script. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent and closed-world behavior, so the bar is lower, yet the description adds real value: the provider fallback ('provider_note says so and the general script is returned') and the conditional outputs (call_by, add_to_calendar) when deal_ends is supplied. It does not describe the shape of the script itself, so not 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?
Purpose is front-loaded in sentence one, followed by usage examples, param guidance and the fallback rule in a logical order. The seven-example list is long but each example earns its place by covering a distinct bill category, so the size is defensible.
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?
With 5 optional parameters, no output schema and annotations already carrying the safety profile, the description covers the key gaps an agent would otherwise hit: which inputs to combine, the provider-mismatch fallback, and the extra fields triggered by deal_ends. It stops short of describing what the returned script contains or its length/format.
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%, so per-parameter meaning, examples and formats are already fully documented in the schema, establishing a baseline of 3. The description only adds the combination rule ('give the bill type, the provider, or both'), which is mildly useful but largely restates the optionality implied by zero required params.
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 first sentence names a specific artifact and goal ('call script to lower a bill'), so an agent knows exactly what it produces. It is clear against the sibling get_call_reminder, but it never explicitly distinguishes itself from get_bill_help, leaving that differentiation to inference.
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 'Use for ...' block gives seven concrete user phrasings that map intent to this tool, which is strong routing guidance for an agent matching a user request. It lacks any explicit when-not-to-use or sibling comparison, 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.
Calendar reminder to call before a deal ends. Returns a calendar file (.ics) with an all-day event about 30 days before the deal ends, holding the full script, offers to ask for and a confirm-in-writing message, with alerts at 9am the day before and on the day. Nothing is stored. /v1/script gives this link as add_to_calendar when deal_ends is given
| Name | Required | Description | Default |
|---|---|---|---|
| bill | No | Bill type, as for getBillScript. Give bill, provider or both. | |
| country | No | Two-letter country code. GB (or UK) gives the UK script when no provider is named. Defaults to the caller's country, else US. | |
| provider | No | Company name, as for getBillScript. | |
| deal_ends | Yes | The date the current price or policy ends, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by describing the returned artifact in detail: an all-day event ~30 days before the deal ends, containing the full script, offers to ask for, a confirm-in-writing message, and alerts at 9am the day before and on the day. It also confirms 'Nothing is stored', reinforcing the readOnly/idempotent hints with concrete behavior.
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?
Three sentences, front-loaded with the core purpose and output artifact, then the construction detail. The middle sentence is dense but each clause carries information the agent needs; little waste.
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?
With no output schema, the description correctly describes the return value (.ics contents and alert timing) and states no persistence. The one gap is that it never clarifies its relationship to get_bill_script/get_bill_help beyond a passing reference, but overall it is complete enough to invoke correctly.
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%, so the schema already documents bill, country, provider, and deal_ends fully, including cross-references to getBillScript. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.
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 concrete verb+resource ('Calendar reminder to call before a deal ends') and specifies the output artifact (a .ics calendar file). It references the /v1/script relationship, though it does not directly name get_bill_script as the sibling it complements, so differentiation is implied rather than explicit.
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 line about /v1/script emitting this link as add_to_calendar when deal_ends is given implies when the tool is relevant, but there is no explicit when-to-use vs when-not guidance or named alternative among siblings. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_bill_helpget_bill_scriptget_call_reminderCompare US mobile plans (cheapest first), home internet providers by address, German energy tariffs.
Is your US medical bill fair? Compares charges with Medicare rates and drafts a dispute letter.
Search U.S. cell plans, compare supported costs, find wireless news, and get switching guidance.
Find unclaimed money in the US and UK: the official free searches and how to claim.
Add one secure layer between your agents and this server.