Skip to main content
Glama

finance

Agent: Update monitoring plan

update_monitoring_plan
    Update (and optionally activate) the user's monitoring plan.

    Only the fields passed are changed. Part of onboarding: activate=True
    turns hands-off monitoring on and is intended to follow the user's
    explicit confirmation in the conversation.

    The plan drives notifications and Tier-2 proposals only — it moves
    no money.

    Args:
        check_in_frequency: daily / weekly / monthly / off.
        watch_*: toggle individual watchers.
        low_balance_threshold: alert when an account drops below this ($).
        surplus_buffer: keep at least this much in checking ($).
        surplus_minimum_sweep: minimum sweep size proposed ($); smaller
            sweeps aren't proposed.
        watch_cashflow_shortfall / watch_anomalies: forecast + anomaly watchers.
        watch_new_recurring / watch_duplicates / watch_quiet_account:
            elder-watch trio — new recurring charge inference, possible
            double-posted charges, and spending on a normally-quiet
            account (all informational; nothing moves money).
        activate: set True (with the user's explicit OK) to approve the plan
            and start the sentinel.

    Returns:
        {"success": True, "plan": {...}} or {"error": ...}.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
activateNo
watch_surplusNo
surplus_bufferNo
watch_anomaliesNo
watch_duplicatesNo
watch_low_balanceNo
check_in_frequencyNo
watch_bill_coverageNo
watch_new_recurringNo
watch_quiet_accountNo
low_balance_thresholdNo
surplus_minimum_sweepNo
watch_cashflow_shortfallNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds meaningful context beyond these: only passed fields change (patch semantics), the plan 'moves no money', and watchers are informational. This reassures the agent about side effects, though auth/permission requirements are not discussed.

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?

Front-loads the core purpose before the Args/Returns detail, and every section adds value. It is longer than average but justified by 13 undocumented parameters; the docstring structure is efficient.

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 13-parameter mutation tool with no output schema, the description covers purpose, partial-update behavior, activation flow, per-field meaning, and even the return shape ({success, plan} / {error}). An agent has everything needed to invoke it correctly.

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?

With 13 parameters and 0% schema coverage, the description fully carries the burden: it explains check_in_frequency's allowed values (daily/weekly/monthly/off), the threshold semantics for low_balance_threshold, surplus_buffer and surplus_minimum_sweep, and annotates each watcher group. This adds substantial meaning absent from 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?

States a specific verb+resource ('Update (and optionally activate) the user's monitoring plan') and clarifies the domain scope by naming what it affects ('drives notifications and Tier-2 proposals only'). An agent can distinguish this from get_monitoring_plan without opening either schema.

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

Usage Guidelines4/5

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

Provides clear context: 'Part of onboarding' and activate=True 'is intended to follow the user's explicit confirmation.' This tells the agent when the activate flag is appropriate. No explicit alternative tool is named, but the usage context is concrete.

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.

Resources