Skip to main content
Glama

wealthpulse

WealthPulse: Personal finance intelligence API. 12 endpoints grounded in live FRED rate data — financial health, retirement, debt, credit cards, mortgage, Social Security, tax optimization, Roth vs Traditional, em

Coverage: Global

Endpoints: • snapshot ($0.15): Financial health snapshot • retire ($0.15): Retirement readiness projection • debt ($0.10): Avalanche vs snowball debt payoff strategy • cards ($0.10): Best credit card for your spending profile • mortgage ($0.10): How much house can I afford • debt-negotiate ($0.15): Can I settle this debt for less • advisor ($0.10): Financial advisor finder, comparison, and background check • ssa ($0.15): Social Security claiming strategy • tax ($0.15): Year-end tax optimization • roth ($0.10): Roth vs Traditional IRA/401k decision • emergency ($0.10): Emergency fund sizing • inheritance ($0.10): Inherited IRA and estate rules • trump-account ($0.15): Trump Account (IRC §530A) eligibility, strategy, and rules • bank-health ($0.25): Is my bank safe? FDIC Call Report bank-health check • bank-check ($0.02): FDIC bank-health check — deterministic Call Report primitive • unclaimed ($0.50): Find unclaimed money owed to you • card-benefit ($0.05): Credit-Card Benefit Coverage Check • card-benefit-pack ($2.00): Card-Benefit Claim Pack • card-benefit-preview ($0.25): Card-Benefit Coverage PREVIEW

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ageNoage
bankNoBank name or FDIC certificate (CERT) number
cardNoCard slug (sapphire-reserve, platinum, venture-x, ...)
debtNoTotal non-mortgage debt in USD
downNoDown payment in USD
firmNoOptional firm name; used alongside name for action=vet
goalNoFor action=strategy: the savings goal for this child
langNolang
nameNoRequired for action=vet (advisor name)
typeNocredit_card | medical | personal | auto | student
debtsNoname:balance:rate format, comma-separated (e.g. credit-card:8500:24,car-loan:12000:6.5)
extraNoExtra monthly payment available in USD (optional)
stateNostate
topicNoFor action=rules (optional): focus the rules answer on this topic
actionNoRequired. One of: find, compare, vet.
healthNohealth
incomeNoAnnual income in USD
issuerNoCard issuer slug (chase, amex, capital-one, citi, hsbc, discover, amex-uk, rbc)
statesNoComma-separated US state codes you have lived/worked in (e.g. CA,TX,NY)
balanceNoBalance owed in USD
benefitNoBenefit to check
has_ssnNoFor action=eligibility: does the child have a Social Security Number
monthlyNoMonthly spend in USD (default: 3000)
savingsNoTotal savings/investments in USD
advisorsNoRequired for action=compare (e.g. "Advisor A 1% AUM, Advisor B flat fee")
creditorNoThe collector or original creditor name
expensesNoMonthly expenses in USD
job_typeNojob_type
locationNolocation
your_ageNoYour current age
child_ageNoFor action=strategy: the child's current age
countriesNoComma-separated non-US jurisdictions: CA (Canada), GB, CH, AU, AU-VIC, AU-NSW
retire_atNoretire_at
situationNoOptional free-text context about your situation
specialtyNoRequired for action=find (e.g. retirement planning, tax, estate, investment)
birth_dateNoAlternative to birth_year for action=eligibility (e.g. 2026-03-15)
birth_yearNoYear of birth (used to calculate Full Retirement Age)
dependentsNoNumber of dependents
item_priceNoItem price — recoverable estimate = min(price, cap) - deductible
situationsNoLife events unlocking federal/special sources: former_pension | failed_bank | failed_credit_union | fha_mortgage | savings_bonds | deceased_relative | old_employer | moved_states | former_business
us_citizenNoFor action=eligibility: is the child a US citizen. Required for the $1,000 pilot only — NOT required for the account itself.
delay_hoursNoTrip delay: hours delayed (triggers are 6h or 12h by card tier)
account_typeNoaccount_type
credit_scoreNoApproximate credit tier
current_fundNoExisting emergency fund in USD
relationshipNorelationship
budget_yearlyNoFor action=strategy: how much can be contributed per year, in USD
filing_statusNofiling_status
incident_dateNoDamage/theft/delay date YYYY-MM-DD — filing deadlines computed from this
purchase_dateNoItem/ticket purchase date YYYY-MM-DD (eligibility windows + warranty math)
spend_profileNoRequired. Free text, e.g. travel, dining, groceries, gas, cashback.
target_incomeNotarget_income
employer_matchNoWhether your employer offers a 401k match (yes/no)
marital_statusNomarital_status
prior_electionNoFor action=eligibility: has an account already been elected for this child
ssn_work_validNoFor action=eligibility: is that SSN valid for employment, issued before election
warranty_yearsNoExtended warranty: original manufacturer warranty length
cardholder_nameNoName for the cover note (placeholder if omitted)
employer_programNoFor action=strategy: does an employer offer a Trump Account matching program
item_descriptionNoWhat the item/trip is (cover note)
original_owner_ageNoOriginal owner's age at time of death
phone_paid_on_cardNoCell phone: was the prior month's wireless bill paid on this card

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed10 schema fields changed
    • changedInput schema / properties / benefit / description
      Previous value: -"extended_warranty | purchase_protection | trip_delay | cell_phone | return_protection"New value: +"Benefit to check"
    • addedInput schema / properties / cardholder_name
      Added value: +{
      +  "description": "Name for the cover note (placeholder if omitted)",
      +  "type": "string"
      +}
    • addedInput schema / properties / delay_hours
      Added value: +{
      +  "description": "Trip delay: hours delayed (triggers are 6h or 12h by card tier)",
      +  "type": "string"
      +}
    • changedInput schema / properties / incident_date / description
      Previous value: -"YYYY-MM-DD — deadlines computed from this"New value: +"Damage/theft/delay date YYYY-MM-DD — filing deadlines computed from this"
    • changedInput schema / properties / issuer / description
      Previous value: -"chase | amex | capital-one | citi | hsbc | discover | amex-uk | rbc"New value: +"Card issuer slug (chase, amex, capital-one, citi, hsbc, discover, amex-uk, rbc)"
    • changedInput schema / properties / item_description / description
      Previous value: -"Item/trip for the cover note"New value: +"What the item/trip is (cover note)"
    • changedInput schema / properties / item_price / description
      Previous value: -"Recoverable estimate computed from this"New value: +"Item price — recoverable estimate = min(price, cap) - deductible"
    • addedInput schema / properties / phone_paid_on_card
      Added value: +{
      +  "description": "Cell phone: was the prior month's wireless bill paid on this card",
      +  "type": "string"
      +}
    • changedInput schema / properties / purchase_date / description
      Previous value: -"YYYY-MM-DD"New value: +"Item/ticket purchase date YYYY-MM-DD (eligibility windows + warranty math)"
    • addedInput schema / properties / warranty_years
      Added value: +{
      +  "description": "Extended warranty: original manufacturer warranty length",
      +  "type": "string"
      +}
  2. Changed7 schema fields changed
    • addedInput schema / properties / benefit
      Added value: +{
      +  "description": "extended_warranty | purchase_protection | trip_delay | cell_phone | return_protection",
      +  "type": "string"
      +}
    • addedInput schema / properties / card
      Added value: +{
      +  "description": "Card slug (sapphire-reserve, platinum, venture-x, ...)",
      +  "type": "string"
      +}
    • addedInput schema / properties / incident_date
      Added value: +{
      +  "description": "YYYY-MM-DD — deadlines computed from this",
      +  "type": "string"
      +}
    • addedInput schema / properties / issuer
      Added value: +{
      +  "description": "chase | amex | capital-one | citi | hsbc | discover | amex-uk | rbc",
      +  "type": "string"
      +}
    • addedInput schema / properties / item_description
      Added value: +{
      +  "description": "Item/trip for the cover note",
      +  "type": "string"
      +}
    • addedInput schema / properties / item_price
      Added value: +{
      +  "description": "Recoverable estimate computed from this",
      +  "type": "string"
      +}
    • addedInput schema / properties / purchase_date
      Added value: +{
      +  "description": "YYYY-MM-DD",
      +  "type": "string"
      +}
  3. Changed3 schema fields changed
    • addedInput schema / properties / countries
      Added value: +{
      +  "description": "Comma-separated non-US jurisdictions: CA (Canada), GB, CH, AU, AU-VIC, AU-NSW",
      +  "type": "string"
      +}
    • addedInput schema / properties / situations
      Added value: +{
      +  "description": "Life events unlocking federal/special sources: former_pension | failed_bank | failed_credit_union | fha_mortgage | savings_bonds | deceased_relative | old_employer | moved_states | former_business",
      +  "type": "string"
      +}
    • addedInput schema / properties / states
      Added value: +{
      +  "description": "Comma-separated US state codes you have lived/worked in (e.g. CA,TX,NY)",
      +  "type": "string"
      +}
  4. First observed

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does add useful context: prices per endpoint, 'live FRED rate data', and 'Coverage: Global'. However, it fails to disclose authentication needs, side effects, error behaviors, rate limits, or whether all endpoints are read-only queries. It also contradicts itself by claiming '12 endpoints' while listing 19.

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 description is long but well-structured with bulleted endpoints, prices, and short purpose phrases. It is front-loaded with a domain summary. The main issues are repetition ('Card-Benefit' appears four times) and the internal inconsistency about the number of endpoints, which undermines precision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex 62-parameter, multi-endpoint tool with no output schema, yet the description does not explain how to invoke a specific endpoint, which parameters are required for each, or what the response format looks like. The parameter list is not mapped to the endpoint list, leaving an agent to guess whether, for example, 'action' or 'spend_profile' is needed for the cards endpoint.

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?

The input schema has 100% parameter description coverage, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides. It does not map parameters to endpoints or clarify which of the 62 parameters are needed for each endpoint, but the schema descriptions are individually informative.

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 clearly identifies this as a personal finance intelligence API and enumerates 19 named endpoints with terse purpose statements (e.g., 'Retirement readiness projection', 'Avalanche vs snowball debt payoff strategy'). This differentiates it from sibling pulse tools by domain (finance). However, the opening says '12 endpoints' while the list contains 19, creating confusion about scope and whether this is a single tool or an aggregation of many tools.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives like debtpulse, taxpulse, homepulse, or travelpulse. The description provides endpoint names and prices but does not explain how an agent should choose among the 19 endpoints, what the required entry conditions are, or how to structure a request (especially given 0 required parameters in the schema).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation4/5

Each tool has a unique domain prefix (e.g., airdroppulse, alphapulse, arbipulse) making them mostly distinguishable at a glance. A few adjacent verticals like careerpulse vs talentpulse or marketpulse vs dealpulse have overlapping themes, but their descriptions clarify the distinct focus. The utility tools (catalog_search, discover, get_openapi_spec, x402_troubleshoot) are also clearly distinct in role. However, the sheer number of similar 'pulse' names could still cause misselection without reading descriptions.

Naming Consistency4/5

The dominant naming convention is `<domain>pulse` (e.g., climatepulse, cryptopulse, edupulse), which is highly consistent and predictable. Exceptions like catalog_search, discover, get_openapi_spec, x402_troubleshoot, and stateedge break the pattern, but these are few and serve obvious utility purposes. Overall, the convention is clear and easily learnable.

Tool Count2/5

With 80 tools, the server presents an extremely large and potentially overwhelming surface. While each tool represents a distinct intelligence vertical and navigation aids exist (catalog_search, discover, get_openapi_spec), the count far exceeds the typical 3-15 range for coherent agent use and even the 'heavy' 16-25 range. The burden of selecting the correct vertical from 80 options is significant, despite clear naming.

Completeness5/5

The server offers an exceptionally broad and deep coverage of domains, from finance and health to agriculture and gaming. Each vertical includes multiple endpoints that address core operations for its domain, such as search, analysis, comparisons, deterministic checks, and even action-oriented tools like letter generators and physical mail. The presence of free discovery and troubleshooting tools fills potential gaps, leaving no obvious dead ends in the overall tool surface.