Beyond Payday

SHTF plan

beyondpayday_get_shtf_plan

Read-only

Returns the household's saved SHTF (hard-times) plan: the actions it would take if income stopped — selling or withdrawing from assets, cutting or replacing bills, housing changes — grouped by severity level, with the plan's start date and settings. Each change in plan.actions has an id, a fromLevel and base settings; plan.levels[n].overrides[id] holds what level n changed (a change made at one level carries into every more severe level, unless that level holds its own value; a change added at one level is listed unchecked at milder levels). Unchecked changes (enabled: false) are included. changes_by_level is the same plan resolved per level, as the page shows it: every change available at that level with checked, editedHere (changed for this plan in more than checked or unchecked; use_lower_level_choice resets it) and all its fields flat under the plan's own names (amount, startMonth, sale.salePrice, withdrawal.taxAmount, …); netCash for a sale or withdrawal is computed by Beyond Payday with the page's rules — report it, never recompute it. A sale has no amount of its own. Bill and asset references are ids from beyondpayday_list_bills / beyondpayday_list_assets; an id that no longer resolves means that record was deleted after the plan was saved. saved is false when the household has not saved a plan yet: plan is then the starting plan the SHTF page shows (built from their bills), and the first edit saves it. Change it with beyondpayday_update_shtf_plan, using these ids. Coverage isn't computed here; the SHTF page's verdict and Covered here marker show it. The plan is the household's own hypothetical scenario, not a recommendation. Only the family owner or spouse/partner can read it, and only with SHTF plan, income, bills and assets access. 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_get_shtf_plan"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already mark it read-only and closed-world, yet the description adds substantial behavioral context the schema cannot: access control, the `saved: false` empty-state semantics, that unchecked changes are included, that netCash must never be recomputed, and that deleted ids indicate removed records. It also flags the plan as a hypothetical, not advice.

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 is front-loaded and the dense material is mostly necessary because there is no output schema to carry the response semantics. It is long, but few sentences look like pure filler; the inheritance/override explanation earns its space.

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?

With no output schema, the description takes on full responsibility for explaining the return value, and it does so thoroughly — structure, edge cases, computed fields, access, and disclaimers. An agent can interpret the response without further sources.

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?

The tool takes no parameters, so the baseline is 4. The description instead invests in documenting the return shape (`plan.actions`, `plan.levels[n].overrides`, `changes_by_level`), which is useful but concerns output rather than parameters.

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 and resource ('Returns the household's saved SHTF (hard-times) plan') and enumerates its content (actions, severity levels, start date, settings). It is clearly distinguishable from the mutating sibling beyondpayday_update_shtf_plan and from the list/reference tools it points to.

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?

Names the alternative for modification ('Change it with beyondpayday_update_shtf_plan') and states the access conditions (owner or spouse/partner, with SHTF plan/income/bills/assets access). It does not spell out explicit when-not conditions, but for a read-only getter the coverage is strong.

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

All Beyond Payday 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?