Skip to main content
Glama

Beyond Payday

List assets

beyondpayday_list_assets
Read-only

Lists assets tracked in the Beyond Payday account — accounts, property, investments and similar — with their current value, category, institution and owners. Each asset reports the business_id it belongs to (null for personal assets), and the list can be filtered to one business with the business_id argument. A row Beyond Payday maintains itself (a business-equity asset) carries derived_from and value_last_computed_at: its value is computed from the business valuation, not entered by the account holder, and it is only as current as that timestamp. A business-equity row may instead carry value_hidden: true with current_value: null: its value would reveal business debts this member cannot read, so it is withheld and left out of the total_assets of beyondpayday_get_overview — say it is hidden, never estimate it. excluded_from_overview marks the rows beyondpayday_get_overview leaves out of its totals. Each row also carries balance_history (its last 12 recorded balances, newest first, dated in the household's local time) and balance_pace (the least-squares change per month over the last year, or null until at least 3 balances span 90 days). History is read-only here. Insurance assets carry policy (coverage details; see below) and investment accounts that can hold holdings carry holdings_summary { count, total } — informational only, never added to the asset's value; use beyondpayday_list_holdings for the rows. For an insurance category (Auto/Home/Condo/Renters/Umbrella/Flood/Disability/Long-Term Care Insurance, Term Life and the like) policy holds the coverage details. Policies with no cash value (Term Life, Disability Insurance, Homeowners Insurance, Renters Insurance, Auto Insurance, Umbrella Insurance, Flood Insurance, Long-Term Care Insurance, Condo Insurance) keep current_value at 0; for permanent life current_value is the net cash surrender value, never the death benefit. The death benefit is policy.coverage_amount and never counts in net worth. A life, disability or long-term care policy covers its owner (family_member_id). Each newer fact applies only to the kinds its description names; a fact the kind cannot carry is not saved (the echo shows null). The premium is never a policy field: a policy bought on your own is paid by a bill; a work policy (employer_provided: true) is paid by a paycheck deduction on the owner's income linked to the asset, so never suggest or create a premium bill for it (the user adds the deduction in the app). Permanent life (Whole, Universal, Variable Universal, Indexed Universal), long-term care and work policies have no end date or term; only Term Life and disability bought on your own end. Home, condo, renters, auto, umbrella and flood policies renew instead (renews_on in reads). Omitted policy fields keep their saved value; on update, policy: null removes the details. The beneficiary note is not available through this connector. Account numbers are not included. A child account sees only assets assigned to it. These rows include DISABLED records and BUSINESS records. beyondpayday_get_overview excludes both from its totals, and additionally leaves out 529 accounts that are unowned or owned by a child and counts policies by cash value only (Term Life and other no-cash-value policies are $0; whole, universal, variable universal and indexed universal life count their cash value; coverage never counts) — so do NOT add these rows up to reproduce an overview figure; call the overview for that. reviewed_at is when the figure was last changed or confirmed accurate by the household; updated_at also moves on cosmetic edits, so use reviewed_at to judge how current a figure is. Paginated: pass limit (1-100, default 25) and offset; the response carries total and nextOffset — keep calling until nextOffset is null before totaling. Figures are estimates from user-entered data — not tax, financial, investment, insurance, or legal advice.

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

Input Schema

NameRequiredDescriptionDefault
idNoFetch one record by id (e.g. to verify a write).
limitNoMaximum records to return (1-100).
offsetNoNumber of records to skip. If nextOffset is not null the page is incomplete — call again with offset: nextOffset before totaling.
searchNoMatch against name, nickname, institution or notes.
categoryNoAsset category to filter by. Matched case-insensitively.
business_idNoOnly return assets belonging to this business.
family_member_idNoOnly return records belonging to this family member.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint, but the description adds substantial behavioral context: derived_from/value_last_computed_at on self-maintained rows, value_hidden rows with null current_value that are withheld for permission reasons, included DISABLED/BUSINESS records, child-account scoping, account numbers excluded, and how rows map (or don't) to overview totals.

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

Conciseness2/5

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

A single enormous block whose core purpose is front-loaded but then buries the reader in policy-mutation semantics ('Each newer fact applies only to the kinds its description names', 'on update, policy: null removes the details', premium-bill rules) that belong to create_asset/update_asset, not a read-only list. Little of that text earns its place here.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and largely delivers: row shape, derived/hidden/excluded flags, balance_history and balance_pace, policy vs holdings_summary. It is effectively complete for the fields it names, though it is silent on the search/category/family_member_id filters and on row ordering.

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 coverage is 100%, so the baseline is 3. The description explains business_id scoping (null = personal) and pagination intent, but never mentions the id, search, category or family_member_id parameters at all, and the offset/nextOffset loop it describes is already spelled out in the schema. Net added value is marginal.

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?

First sentence gives a specific verb+resource+scope: assets tracked in the account, with their value, category, institution and owners. It also explicitly distinguishes itself from siblings (beyondpayday_list_holdings for holding rows, beyondpayday_get_overview for totals), so an agent can route without opening a 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?

Explicit when-not guidance: 'do NOT add these rows up to reproduce an overview figure; call the overview for that', 'use beyondpayday_list_holdings for the rows', 'say it is hidden, never estimate it'. It also warns to keep paginating until nextOffset is null before totaling. Alternatives and exclusions are named outright.

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