SwitchWize MCP

Business Card Cost

business_card_cost

Read-onlyIdempotent

Estimate yearly rewards minus annual, foreign and late fees for four small-business credit cards, given monthly spend, spend in the bonus category, share of spend abroad and late payments per year. Fees come from issuer pages a reviewer read and quoted; a fee with no current quote is marked not verified and left out of the ranking, never treated as zero. Excludes welcome bonuses, credits, interest and approval odds. Pay-in-full scenario, not personalized advice.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "business_card_cost"
  }
}

Input Schema

Name	Required	Description
`monthlySpend`	No	Business card spend per month in dollars. Default 5000.
`foreignSharePct`	No	Percent of spend made abroad. Default 0.
`latePaymentsPerYear`	No	Late payments per year. Default 0.
`monthlyBonusCategorySpend`	No	Part of monthlySpend in a bonus category (for example shipping or advertising). Default 0.

Output Schema

Name	Required	Description
`asOf`	No	ISO timestamp of the underlying data this response reflects.
`tool`	Yes
`cards`	No
`error`	No
`source`	No	Where the data comes from (URL).
`winner`	No
`toolMeta`	No	Version and stability of the tool that produced this reply. See /developers#tool-versions.
`warnings`	No
`assumptions`	No
`attribution`	No
`generatedAt`	Yes	ISO timestamp this response was computed at.
`verified_at`	No
`schemaVersion`	Yes
`methodologyUrl`	No
`recommendation`	No
`freshnessStatus`	No
`verifiedThrough`	No
`comparison_status`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds genuinely useful behavioral context beyond them: fee provenance ('issuer pages a reviewer read and quoted') and, crucially, that an unquoted fee is flagged not verified and excluded from the ranking rather than treated as zero. It stops short of describing the ranking/output shape, which the output schema covers.

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?

Four sentences, front-loaded with the purpose in sentence one, then scope limits and data caveats. Dense but each sentence earns its place; only the long opening clause is slightly overloaded.

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 four-optional-parameter estimation tool with an output schema, the description covers the calculation basis, what is deliberately excluded, how missing fee data is handled, and the advice disclaimer. Nothing an agent needs to call or interpret it correctly 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 coverage is 100% and each parameter carries its own description with defaults, so the baseline is 3. The prose restates all four inputs (monthly spend, bonus-category spend, foreign share, late payments) but adds no interpretation, units, or interaction semantics beyond the schema.

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?

Specific verb plus resource: 'Estimate yearly rewards minus annual, foreign and late fees for four small-business credit cards,' with the full input basis spelled out. It clearly distinguishes itself from siblings like get_card_offers or compare_accounts, which deal with offers or bank accounts rather than net-of-fee card economics.

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 description frames the scenario ('Pay-in-full scenario, not personalized advice') and lists exclusions (welcome bonuses, credits, interest, approval odds), which tells the agent what the output does not answer. But it never says when to prefer this over a sibling such as get_card_changes or get_card_downgrade_path; the routing is left implied.

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

All SwitchWize MCP 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.