finance

Profile: Update user preferences

update_user_preferences

    Update user preferences. Only provided fields are changed.

    Args:
        theme: Color theme (light, dark, emerald_banking, frost_glass, carbon)
        currency: Currency code. USD only — multi-currency is disabled
            pre-launch, so any other value is rejected (matches the web
            form + REST serializer, which omit/lock the field).
        notify_budget_alerts: Enable budget alert notifications
        notify_bill_reminders: Enable bill reminder notifications
        notify_large_transactions: Enable large transaction notifications
        notify_weekly_summary: Enable weekly summary emails
        notify_balance_alerts: Enable Plaid balance-mismatch alert
            notifications (off by default — the dashboard badge is the
            default signal)
        notify_debt_payments: Enable the monthly debt-strategy payment
            reminder (requires a saved debt_strategy to fire)
        notify_daily_brief_email: Email the agent's morning brief to the
            user's inbox (the brief appears in the app thread either
            way; this toggles the email copy only)
        notify_family_alerts: Receive in-app alerts + the family brief
            about accounts a family member shared with the user
            (elder-care; on by default, receiver-side opt-out)
        notify_family_brief_email: Email the family brief (off by
            default; alerts keep appearing in the app either way)
        show_profile_picture: Show profile picture in forum
        show_real_name: Show real name in forum
        show_level: Show level badge in forum
        show_badges: Show earned badges in forum
        debt_strategy: Save the user's debt-paydown "my plan" strategy — one
            of minimum_payments, snowball, variable_snowball, highest_rate,
            highest_balance, highest_payment, cashflow_index, npv,
            max_interest_savings. Pass "" to clear it. This drives the
            dashboard debt-payoff card + the strategy reminder. Free plans are
            limited to the lower-tier strategies (Premium-only ones rejected).
        debt_extra_monthly_payment: Extra $/month applied on top of minimums
            in the paydown plan (0 or positive).

    Returns:
        Updated preferences (including debt_strategy + debt_extra_monthly_payment)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`theme`	No
`currency`	No
`show_level`	No
`show_badges`	No
`debt_strategy`	No
`show_real_name`	No
`notify_budget_alerts`	No
`notify_debt_payments`	No
`notify_family_alerts`	No
`show_profile_picture`	No
`notify_balance_alerts`	No
`notify_bill_reminders`	No
`notify_weekly_summary`	No
`notify_daily_brief_email`	No
`notify_family_brief_email`	No
`notify_large_transactions`	No
`debt_extra_monthly_payment`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the description's job is to add context — and it does: partial updates, currency is locked to USD pre-launch, debt_strategy accepts "" to clear, free plans reject Premium strategies, and several notify_* flags carry defaults (e.g. notify_balance_alerts off by default). Auth requirements and rate limits remain unstated.

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 lead sentence is front-loaded and the Args block is scannable; almost every line adds distinct information. Some parenthetical asides (e.g. the dashboard-badge note on balance alerts) run longer than needed, but nothing is filler.

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 17-parameter mutation tool with no output schema, the description covers every field's meaning, the constraints that cause rejection, defaults, and what the call returns. An agent can invoke this correctly without consulting anything else.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full parameter burden for 17 fields, and it delivers: enumerations (theme colors, debt_strategy values), accepted value ranges, clearing semantics, and plan-gating per field. This is exactly the compensation the 0% coverage demands.

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?

States a specific verb and resource (update user preferences) and adds the key partial-update contract: 'Only provided fields are changed.' That distinguishes it from sibling getters like get_user_preferences and from the profile-scoped update_user_profile, though it never names those siblings explicitly.

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?

Usage is implied by the partial-update semantics and the per-field notes, but there is no explicit when-to-use this vs update_user_profile, and no stated prerequisites or auth context for a mutation tool.

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

All finance 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?