SwitchWize MCP

Official

by switchwize

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Card Reality Score

get_reality_score

Read-onlyIdempotent

Estimate a premium credit card’s modeled annual net value by card and consumer segment, returning a Reality Score with rewards, credits, perks, fees, interest, friction and caveats.

Instructions

Estimate the modeled annual value of a supported premium credit card for a consumer segment. Supply a card slug or name and optionally a segment ID; the default is occasional-traveler. Return segment assumptions, score, rewards, credits, perks, fee, interest, friction, net value, caveats, sources, verification date, freshness and methodology. Gross recovered value is rewards + credits + perks. breakageMultiplier is gross recovered value / advertised value, NOT divided by annual fee. feeRecoveryMultiplier is max(0, gross recovered value - interest drag - rewards friction discount) / annual fee, before subtracting the fee. Friction applies to raw rewards only. Reality Score is 100 * net realized value / advertised value. Ratios are rounded. These are scenario estimates, not personalized advice or guaranteed benefits. Preserve stale or unavailable labels; do not infer that all terms share the observation date. Unknown cards or segments return a structured error with suggestions.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`card`	Yes	Card slug or name, e.g. platinum-card or Chase Sapphire Reserve.
`segment`	No	Optional segment id, e.g. occasional-traveler, small-business-owner, balance-carrier.

Output Schema

TableJSON Schema

Name	Required	Description
`asOf`	No	ISO timestamp of the underlying data this response reflects.
`tool`	Yes
`error`	No
`result`	No
`segment`	No
`index_id`	No
`datasetUrl`	No
`attribution`	No
`generatedAt`	Yes	ISO timestamp this response was computed at.
`verified_at`	No
`schemaVersion`	Yes
`methodologyUrl`	No
`freshnessStatus`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.0Oct 13, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "asOf": {
+      "description": "ISO timestamp of the underlying data this response reflects.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "attribution": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "datasetUrl": {
+      "type": "string"
+    },
+    "error": {
+      "additionalProperties": false,
+      "properties": {
+        "code": {
+          "type": "string"
+        },
+        "message": {
+          "type": "string"
+        },
+        "retryable": {
+          "type": "boolean"
+        },
+        "suggestions": {
+          "items": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "additionalProperties": true,
+                "type": "object"
+              }
+            ]
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "code",
+        "message"
+      ],
+      "type": "object"
+    },
+    "freshnessStatus": {
+      "enum": [
+        "fresh",
+        "aging",
+        "stale",
+        "unavailable"
+      ],
+      "type": "string"
+    },
+    "generatedAt": {
+      "description": "ISO timestamp this response was computed at.",
+      "type": "string"
+    },
+    "index_id": {
+      "type": "string"
+    },
+    "methodologyUrl": {
+      "type": "string"
+    },
+    "result": {
+      "additionalProperties": true,
+      "properties": {
+        "advertisedValue": {
+          "type": "number"
+        },
+        "annualFee": {
+          "type": "number"
+        },
+        "breakageMultiplier": {
+          "description": "Gross recovered value (rewards + credits + perks) / advertised value, rounded to two decimals. Annual fee is not this denominator.",
+          "type": "number"
+        },
+        "feeRecoveryMultiplier": {
+          "description": "max(0, gross recovered value - interest drag - rewards friction discount) / annual fee, rounded to two decimals; before subtracting the annual fee.",
+          "type": "number"
+        },
+        "interestDrag": {
+          "type": "number"
+        },
+        "realityScore": {
+          "description": "100 * net realized value / advertised value, rounded to an integer.",
+          "type": "number"
+        },
+        "realizedPerks": {
+          "type": "number"
+        },
+        "realizedRewards": {
+          "type": "number"
+        },
+        "realizedStatementCredits": {
+          "type": "number"
+        },
+        "realizedValue": {
+          "description": "Rewards + credits + perks minus annual fee, interest drag and rewards friction discount.",
+          "type": "number"
+        },
+        "redemptionFrictionDiscount": {
+          "description": "Discount applied to raw rewards, not to credits or perks.",
+          "type": "number"
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "schemaVersion": {
+      "type": "string"
+    },
+    "segment": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "tool": {
+      "type": "string"
+    },
+    "verified_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "schemaVersion",
+    "tool",
+    "generatedAt"
+  ],
+  "type": "object"
+}

First observedv0.1.0Sep 5, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but the description adds real behavioral context: it defines every derived ratio (breakageMultiplier, feeRecoveryMultiplier, friction, Reality Score), warns that these are scenario estimates, and instructs how to handle stale/unavailable labels. It also discloses that unknown cards/segments return a structured error with suggestions. This goes well beyond the annotations, though some overlap with the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and required inputs are front-loaded correctly, but the middle of the description is a dense run of formula definitions (breakageMultiplier, feeRecoveryMultiplier, friction, Reality Score) that partly restates what the output schema can carry. Several sentences do real work, but the block is longer than needed for a 2-parameter read tool.

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 read-only estimation tool with a full output schema and complete annotations, the description covers the remaining gaps: default segment, error behavior, the meaning of every computed ratio, caveats about scenario estimates, and stale-label handling. An agent has everything it needs 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 the schema already documents both parameters (card and segment) with examples. The description adds only the default value for segment (occasional-traveler), which is not in the schema, and restates card-or-name input. Baseline 3 is appropriate.

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 opening sentence gives a specific verb+resource+scope: "Estimate the modeled annual value of a supported premium credit card for a consumer segment." It clearly defines the Reality Score concept. However, it never distinguishes itself from the closest siblings (get_reward_valuations, get_card_offers, get_card_downgrade_path), so an agent must infer which card-value tool to pick.

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 states invocation basics ("Supply a card slug or name and optionally a segment ID; the default is occasional-traveler") and notes error behavior for unknown inputs, but gives no when-to-use vs when-not guidance and names no alternative among the many sibling card tools. Usage is implied rather than directed.

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

Deploy Server