Movable Capital: verified cash rates

Compare cash options after tax

compare_after_tax

Read-only

For a cash balance and the person's tax rates, estimate what each kind of cash option keeps per year after federal and state income tax (Treasury interest is state-tax-free; money funds pass through their government share), and how much more than where the cash sits now. Returns the best option of each kind.

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": {
      "balance": "<balance>",
      "federal_pct": "<federal_pct>",
      "state_pct": "<state_pct>"
    },
    "name": "compare_after_tax"
  }
}

Input Schema

Name	Required	Description
`niit`	No	True if the 3.8% net investment income tax applies.
`balance`	Yes	Cash balance in U.S. dollars.
`current`	No	Where the cash sits now: a broker name (its default sweep), "checking", or an id from get_cash_rates. Default checking at 0.01%.
`priority`	No	return (default), liquidity (2 days or less), or protection (FDIC or U.S. government).
`state_pct`	Yes	State + local income tax rate, e.g. 5. 0 if none.
`federal_pct`	Yes	Top federal income tax bracket, e.g. 24.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the tax treatment rules (Treasury interest state-tax-free, money funds passing through their government share) and the fact that results are per-year and include a delta versus the current holding, plus 'best option of each kind' for the output shape.

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?

A single front-loaded sentence states the computation, then layers tax rules and the baseline comparison in parentheses that each carry information. It is dense but no clause is pure filler; a light split into two sentences would improve scanability.

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, the description carries the return-value burden and does so: it says the tool returns per-year after-tax amounts per option kind, the delta versus the current holding, and the best option of each kind. Combined with 100% schema coverage and readOnly annotations, an agent has enough to call this correctly.

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 all six parameters including niit, priority, and current are already documented in the schema. The description adds only modest interpretive value, chiefly clarifying that 'where the cash sits now' serves as the comparison baseline for the reported gain, and does not expand on niit or priority semantics.

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

Purpose4/5

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

The description names a specific verb (estimate what each option keeps per year) and a specific resource (after-tax cash options, incorporating federal/state treatment). It clearly differs in kind from the siblings (get_cash_rates, get_sweep_rate, get_treasury_yields) because it computes an after-tax comparison rather than fetching raw data, though it never names those siblings to make the contrast explicit.

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?

The opening clause implies the usage context (given a balance and the person's tax rates) and the 'how much more than where the cash sits now' framing hints at comparison use, but there is no explicit when-to-use/when-not guidance and no named alternative tool. The reference to get_cash_rates ids in the schema is the only routing signal.

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

All Movable Capital: verified cash rates 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?