Beyond Payday

List businesses

beyondpayday_list_businesses

Read-only

Lists the businesses tracked in the Beyond Payday account with their entity type, industry, estimated tax rate and valuation settings. A business's own income, assets and debts are available from beyondpayday_list_income, beyondpayday_list_assets and beyondpayday_list_debts filtered by business_id, and its expenses from beyondpayday_list_business_expenses. Requires a Beyond Payday plan that includes businesses. Employer identification numbers are never returned, and a child account sees only the businesses it is a listed owner of. 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_businesses"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum records to return (1-100).
`offset`	No	Number of records to skip. If nextOffset is not null the page is incomplete — call again with offset: nextOffset before totaling.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing that employer identification numbers are never returned, that child accounts see only businesses they own, that the feature requires a qualifying plan, and how pagination must be driven to completion. These are non-obvious behavioral constraints an agent could not infer from structured fields.

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

Conciseness5/5

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

Front-loaded with the core purpose, then progressive detail on sibling routing, constraints, pagination, and disclaimer. Every sentence carries operational value with no 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?

With no output schema, the description compensates by naming the fields returned and the pagination envelope (total, nextOffset). An agent has everything needed to call, page through, and correctly interpret (and hedge) the results.

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 both parameters (limit, offset) are already documented with ranges and defaults. The description restates limit 1-100/default 25 and the nextOffset looping rule, which largely duplicates the schema text rather than adding new meaning — baseline 3 is appropriate.

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 (lists) and resource (businesses) and enumerates the returned fields: entity type, industry, estimated tax rate, valuation settings. It is clearly distinguishable from sibling list tools (income, assets, debts, expenses), which it explicitly delegates to for per-business detail.

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?

Explicitly routes the agent: a business's income, assets and debts come from beyondpayday_list_income/assets/debts filtered by business_id, and its expenses from beyondpayday_list_business_expenses. It also states the plan precondition and the child-account visibility rule, so the agent knows both when this tool is right and when to call a sibling instead.

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?