Dueback

Start negotiation case

start_negotiation_case

Open a Dueback negotiation case. Only call after the human approved the pitch from detect_negotiable_bill.

Two outcomes:

{"outcome": "case_created", "case_id", ...}: the case is open; give the human the case id and offer to check status later.
{"outcome": "setup_required", "setup_url", ...}: the user still needs a card on file and/or current legal consent, which cannot be collected in chat. Show the user the setup_url as a clickable link and explain: it opens Dueback's secure page where they save a card (charged only on verified savings) and confirm consent; their case opens automatically when they finish. Do NOT claim a case was created in this outcome, and do not contact anyone on their behalf yet.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "expense_description": "<expense_description>"
    },
    "name": "start_negotiation_case"
  }
}

Input Schema

Name	Required	Description	Default
`amount_cents`	No	The amount charged, in cents (e.g. 8500 means $85.00), if known.
`counterparty`	No	The company that charges the bill (e.g. 'Comcast'), if known.
`billing_period`	No	How often the charge recurs: 'monthly', 'annual', or 'one_off' for a single purchase. Use 'unknown' if unsure — it affects how savings are calculated.	unknown
`automatic_change`	No	True only if the lower price already took effect automatically (e.g. the provider dropped the rate on its own) rather than through negotiation. Otherwise false.
`observed_signals`	No	Facts suggesting the price may be negotiable or incorrect — e.g. a recent increase, a lower advertised price, a billing error, a competitor offer, or long customer tenure. Omit if none.
`expense_description`	Yes	Plain-language description of the bill or expense — what the charge is for, e.g. 'monthly home internet bill'. Use the same facts as the approved detect_negotiable_bill call.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 29, 2026

addedInput schema / properties / amount_cents / description

Added value: +"The amount charged, in cents (e.g. 8500 means $85.00), if known."

addedInput schema / properties / automatic_change / description

Added value: +"True only if the lower price already took effect automatically (e.g. the provider dropped the rate on its own) rather than through negotiation. Otherwise false."

addedInput schema / properties / billing_period / description

Added value: +"How often the charge recurs: 'monthly', 'annual', or 'one_off' for a single purchase. Use 'unknown' if unsure — it affects how savings are calculated."

addedInput schema / properties / counterparty / description

Added value: +"The company that charges the bill (e.g. 'Comcast'), if known."

addedInput schema / properties / expense_description / description

Added value: +"Plain-language description of the bill or expense — what the charge is for, e.g. 'monthly home internet bill'. Use the same facts as the approved detect_negotiable_bill call."

addedInput schema / properties / observed_signals / description

Added value: +"Facts suggesting the price may be negotiable or incorrect — e.g. a recent increase, a lower advertised price, a billing error, a competitor offer, or long customer tenure. Omit if none."

First observedOct 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare this is a non-read-only, non-idempotent, open-world write, and the description goes well beyond them: it names the two possible outcomes with their key fields, states that card/consent cannot be collected in chat, and forbids claiming a case was created in the setup_required branch. These are behavioral constraints the agent could not derive from annotations or schema.

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 precondition, then cleanly split into two bullet outcomes. The setup_required explanation runs a bit long, but every clause carries agent-facing instruction (link handling, what not to claim, don't contact anyone), so there is little waste.

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 six params, an output schema, and rich annotations, the remaining burden is interpretation and post-call behavior — exactly what the description supplies for both outcomes. An agent has everything needed to call it and to handle each response correctly.

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 description coverage is 100%, so the baseline is 3 and the schema already explains amount_cents, billing_period, automatic_change, and observed_signals. The description adds cross-call meaning for expense_description ('use the same facts as the approved detect_negotiable_bill call'), which is genuine value beyond the field's own text.

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?

Opens with a specific verb+resource ('Open a Dueback negotiation case') and immediately distinguishes itself from siblings by tying it to a prior detect_negotiable_bill approval. An agent can tell this apart from get_case_status/list_my_cases without opening any schema.

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

Usage Guidelines5/5

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

Gives an explicit hard precondition ('Only call after the human approved the pitch from detect_negotiable_bill') and implies the alternative path when the user later wants status ('offer to check status later'). It also enumerates the two branches and how to behave in each, leaving nothing to inference.

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

All Dueback 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.