Dueback

Get case status

get_case_status

Read-onlyIdempotent

Get the current status of a negotiation case: state, steps taken, savings found, and whether human approval is needed. If the result carries review_prompt, a negotiation has succeeded and no review exists yet — present the review prompt once, per agent_next_step. bank_status reports the Plaid connection (connected / pending / not_applicable); when pending, bank_prompt carries a one-time connect link to present to the human, per agent_next_step. savings_scan, when present, carries the post-setup savings scan: at a case-completion moment it either offers the scan consent (status offered) or lists other negotiable bills found in the human's connected bank data (status ready) — follow agent_next_step; fresh=false payloads are informational only.

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": {
      "case_id": "<case_id>"
    },
    "name": "get_case_status"
  }
}

Input Schema

Name	Required	Description	Default
`case_id`	Yes	The case_id returned by start_negotiation_case or list_my_cases.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026
- addedInput schema / properties / case_id / description
```
Added value: +"The case_id returned by start_negotiation_case or list_my_cases."
```
First observedOct 21, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already establish safe, read-only, idempotent behavior. The description adds substantial context beyond that: it explains one-time presentation of review_prompt, the pending bank connect prompt, and savings_scan states with agent_next_step, with no contradiction.

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?

The purpose is front-loaded and most sentences explain a result state or required agent action. The dense semicolon-heavy paragraph could be structured more cleanly, but it is not repetitive or padded.

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 an output schema present, the description need not restate return formatting; it still supplies conditional meaning for review, bank, and savings_scan fields. For a one-parameter read tool, that is complete enough for correct invocation and follow-up behavior.

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 coverage is 100% for the single case_id parameter, and the schema itself explains that it comes from start_negotiation_case or list_my_cases. The description adds no further parameter semantics, so the baseline 3 is appropriate.

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?

The description opens with a specific verb and resource, 'Get the current status of a negotiation case,' and enumerates the status content (state, steps taken, savings found, approval needed). This clearly distinguishes it from list/start/detect siblings without requiring 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 Guidelines3/5

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

It gives conditional handling for review_prompt, bank_status, and savings_scan, but never explicitly says when to call this tool versus list_my_cases or start_negotiation_case. Usage is implied by 'current status' and by the result conditions, not stated as tool-selection guidance.

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.