Skip to main content
Glama
Sign In

Well

by io.github.WellApp-ai
OverviewDiscussionsAdmin

List upcoming payments and the next payday

well_list_upcoming_payments
Read-only

List the payments still to come in a personal space, from its bank and credit card history: each recurring debit with its next day and amount, a running total, and the next recurring inflows (payday among them) with what is left before each. It draws no card.

Call it when the person asks what is coming out of their account, which bills are due before payday, or what is left until payday ("what's left before payday?", "qu'est-ce qui part avant ma paie ?"). It reads a personal space only: in a company workspace it refuses, and the supplier bills a company owes are read with the bills-due skill.

The server applies every rule, and the result states each one in rules. Quote the figures and days as returned: never recompute a day, an amount, a running total or a balance, and never add a payment the person expects.

Every amount in the result is in the major units of its currency, never in cents: 1860 is 1,860.00 EUR, not 18.60 EUR.

Inputs:

  • until: the last day to list, YYYY-MM-DD, from today to 366 days ahead. Omit it for the next 35 days, which always holds a monthly payday.

  • balance_by_currency: the balance to start from, in major units, keyed by currency, as a balance read returned it. Omit it to get the days and totals with no balance left.

What the result is:

  • today: the calendar day in the workspace's time zone; until the last day listed.

  • debits: the recurring debits expected from today to until, earliest first, at most 50; debit_count is the full count. Each has its next_day, expected_amount (the latest debit's amount; amount_pattern: varying means it is an estimate), cadence, state, running_total per currency and balance_left (balance minus the running total, null with no balance for its currency). state: late means the expected day passed at most 5 days ago with no debit seen yet: it is still expected and counted. missed_periods above 0 means earlier periods passed with no debit.

  • inflows: the recurring money in expected in the same days, earliest first, with its category (SALARY_INCOME is a salary), next_day, expected_amount, debits_due_before (the debits of its currency expected before its day) and balance_left_before. Payday is one of these, or of inflows_after_until when until comes before it: the result never picks it.

  • inflows_after_until: the recurring inflows whose next day is after until, earliest first, with the same fields as debits but no running total. A salary here is a payday after the last day listed.

  • totals: per currency, the debits expected to until and the balance left after them.

  • possibly_ended_count: series that may have stopped, never listed. beyond_horizon_count: debits and inflows whose next day is after until. undated_count: series with no readable day.

  • excluded: what fell out of the debits, counted apart. payments_to_own_accounts are debits to another account of this space, such as a loan repayment to a loan account Well holds; category_excluded the debits whose category is a transfer, placement or cash withdrawal. A null count was not measured, which is not zero.

partial: true means nothing was measured: the read was cut short, or the space holds no bank account and no card. Say so rather than reporting no payment. rows_truncated: true means the smallest counterparties were not read, so every total is a floor.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

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": "well_list_upcoming_payments"
  }
}

Input Schema

NameRequiredDescriptionDefault
untilNoThe last day to list, YYYY-MM-DD, from today to 366 days ahead. Omit it for the next 35 days.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.
balance_by_currencyNoThe balance to start from in major units, keyed by currency, as a balance read returned it. Omit it to list the days with no balance left.

Output Schema

NameRequiredDescriptionDefault
errorNo
rulesYes
todayYes
untilYes
debitsYes
totalsYes
inflowsYes
partialYes
successYes
excludedYes
time_zoneYes
debit_countYes
inflow_countYes
undated_countYes
rows_truncatedYes
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
debits_truncatedYes
inflows_truncatedYes
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
inflows_after_untilYes
beyond_horizon_countYes
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
possibly_ended_countYes
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnly/closed-world/non-destructive; the description goes far beyond by disclosing that no card is drawn, that all rules are applied server-side and echoed in `rules`, that amounts are in major units so `1860` is 1,860.00 EUR, and what `partial: true` and `rows_truncated: true` mean for trusting totals. It also explains `state: late`, `missed_periods`, `amount_pattern: varying`, and that a `null` excluded count means unmeasured rather than zero — precisely the failure modes an agent would otherwise misreport.

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?

Purpose, disambiguation, and the critical quoting/currency rules are front-loaded before any field detail, and the labelled sections (Inputs, What the result is) make it scannable. It is long, however, and a substantial block documents return fields the output schema already carries, which taxes a per-call token budget.

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 five-parameter, nested-schema, output-schema-carrying financial read against a named sibling, the description covers scope, refusal behavior, workspace selection, default horizon, currency units, and how to interpret partial/truncated results. An agent has everything needed to call it correctly and to report its output faithfully.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: `until` omitted defaults to 35 days 'which always holds a monthly payday', and `balance_by_currency` omitted yields days and totals without a balance left. It also adds workspace-selection reasoning (pass `workspace_id` rather than guessing when several are authorized). Nothing is added for `conversation_id` or `workspace_scope` beyond their schema text.

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?

The first sentence names a specific resource (recurring debits and inflows in a personal space), a specific output shape (next day, amount, running total, next payday), and an explicit non-behavior ('It draws no card'). It also carves out the boundary against a named alternative ('the supplier bills a company owes are read with the bills-due skill'), so an agent can distinguish it from well_sum_receivables or well_render_cash_forecast without opening another schema.

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

Usage Guidelines5/5

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

Gives explicit trigger utterances in two languages ('what's left before payday?', 'qu'est-ce qui part avant ma paie ?') plus the three situations the tool serves. It names the condition under which it must not be used (company workspace, where it refuses) and routes that case to the bills-due skill. The workspace preamble further states when no workspace call is needed first.

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

All Well toolsInspect
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