Connect

8 clients · secrets stay placeholders

JSON (mcpServers)Claude CodeCodexOpenCodeCursorVS CodeGemini CLIGoose

{
  "mcpServers": {
    "models": {
      "type": "http",
      "url": "https://worthune.com/api/mcp/mcp"
    }
  }
}

claude mcp add --transport http models https://worthune.com/api/mcp/mcp

[mcp_servers.models]
url = "https://worthune.com/api/mcp/mcp"

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "models": {
      "type": "remote",
      "url": "https://worthune.com/api/mcp/mcp",
      "enabled": true
    }
  }
}

{
  "mcpServers": {
    "models": {
      "type": "http",
      "url": "https://worthune.com/api/mcp/mcp"
    }
  },
  "deeplink": "cursor://anysphere.cursor-deeplink/mcp/install?name=models&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vd29ydGh1bmUuY29tL2FwaS9tY3AvbWNwIn0%3D"
}

{
  "servers": {
    "models": {
      "type": "http",
      "url": "https://worthune.com/api/mcp/mcp"
    }
  }
}

{
  "mcpServers": {
    "models": {
      "httpUrl": "https://worthune.com/api/mcp/mcp"
    }
  }
}

extensions:
  "models":
    enabled: true
    name: "models"
    type: streamable_http
    uri: "https://worthune.com/api/mcp/mcp"
    timeout: 300

Quality 84 / 100good

protocol88 · weight 25

pass
protocol.modernsupports 2026-07-28 (server/discover)
pass
protocol.statelessanswers without a session
pass
protocol.transportstreamable HTTP
warn
protocol.list_ttltools/list declares ttlMs 0, so clients re-fetch it on every use

authorizationn/a · weight 15

n/a
auth.prm, auth.as_metadata, auth.cimdno remote uses OAuth
n/a
auth.secret_in_urlno templated URL

tool hygiene86 · weight 30

pass
tools.descriptionsevery tool has a description
warn
tools.description_length2 tools have descriptions over 1,024 characters, which crowds the context
pass
tools.schemasevery tool has an object input schema
pass
tools.annotations30 of 30 tools declare readOnlyHint or destructiveHint
pass
tools.directory_hintsevery tool declares readOnlyHint, destructiveHint, idempotentHint and openWorldHint
warn
tools.token_costabout 9,011 tokens to load every tool
pass
tools.api_dumptools are not a one-to-one API dump

stability75 · weight 15

warn
stability.changes13 tool changes in 30 days
pass
stability.rug_pullno tool changed its meaning under the same name

dependenciesn/a · weight 15

n/a
deps.known_vulns, deps.mcp_sdk_version, deps.resolvableno npm or PyPI package

30 tools, about 9,011 tokens to load them all · tool set e36abedc2aaa · tools last changed 2026-10-11 · checked 2026-10-19 10:20 UTC

Tool changes

2026-10-11manage_preferencesadded
An advisor's standing preferences, which the gate enforces in every cycle: avoid-strategy (optionally until a date), min-value for a strategy, max-annual-conversion, avoid-alternative. action list (any role); add (an approver or owner key confirms it at once, a developer key only suggests it); confirm a suggestion (approver or owner); remove (a suggestion: developer and up; a confirmed preference: approver or owner). Same as /api/v1/mandates/{id}/preferences and /api/v1/preferences/{id}.
2026-10-11answer_questionadded
Answer one open question. value proposes the corrected field as a data-change proposal that an approver or owner must approve before anything is written; confirm: true records that the data is right, and the same check will not ask about the field again. Send exactly one of them. Developer, approver or owner key. Refused when the household changed since the question was asked. Same as POST /api/v1/questions/{id}/answer.
2026-10-11list_questionsadded
Lodestar's questions about one field of a household's data (a taxable account with no cost basis, a Social Security stream with no amount, living expenses of zero), asked by deterministic checks in every household cycle; at most one open per mandate. Filter by status (open, answered, confirmed, stale), mandate_id or household_id. Any key role. Same as GET /api/v1/questions.
2026-10-11create_mandatechangeddescription
before
Assign a standing mandate: strategy-watch (one household, the strategies you choose), tax-optimization (one household, minimize-lifetime-tax, the tax strategies) or rules-change (the whole book, Growth and above: when tax rules or your assumption profile change, finds and ranks every affected household; send no household_id). Each has an objective, pinned constraints and an approval policy. Lodestar then works it when a deadline approaches, the household changes, rules or the organization's assumption profile change, a scheduled review comes due, or on run_mandate, and files proposals for an approver. constraints needs horizonYears and exactly one of profile { id, version } or assumptions { … } (never an implicit default); optional: strategies, materialityFloorUsd (default 1000), cooldownDays (30), maxOpenProposals (3), reviewCadence (quarterly), taxRates, ladderCandidates, illustrativeCharacteristics, bracketFill { fillToRatesPct?, years? }, charitableGiving { annualGivingUsd, … } (tax-optimization runs charitable-giving only when charitableGiving names the gifts). One mandate per type per household. Each cycle's sweep counts the household as active for the month. Developer or owner key. Same as POST /api/v1/mandates.
after · 93% of words in common
Assign a standing mandate: strategy-watch (one household, the strategies you choose), tax-optimization (one household, minimize-lifetime-tax, the tax strategies) or rules-change (the whole book, Growth and above: when tax rules or your assumption profile change, finds and ranks every affected household; send no household_id). Each has an objective, pinned constraints and an approval policy. Lodestar then works it when a deadline approaches, the household changes, rules or the organization's assumption profile change, a scheduled review comes due, or on run_mandate, and files proposals for an approver. constraints needs horizonYears and exactly one of profile { id, version } or assumptions { … } (never an implicit default); optional: strategies, materialityFloorUsd (default 1000), cooldownDays (30), maxOpenProposals (3), reviewCadence (quarterly), planner ("on"/"off", default off: the organization's certified planner model chooses among gate-passed proposals), taxRates, ladderCandidates, illustrativeCharacteristics, bracketFill { fillToRatesPct?, years? }, charitableGiving { annualGivingUsd, … } (tax-optimization runs charitable-giving only when charitableGiving names the gifts). One mandate per type per household. Each cycle's sweep counts the household as active for the month. Developer or owner key. Same as POST /api/v1/mandates.
2026-10-11get_ledgeradded
Ledger entries written by approvals, newest first, optionally for one mandate or household, with the total. Each is an evidence record (hash over its inputs and outputs, Ed25519-signed with the key at /api/v1/records/keys) naming the stored decision it came from. Values are PROJECTED and NOMINAL against each decision's own baseline; the total is a sum of projections, not realized value. Any key role. Same as GET /api/v1/ledger.
2026-10-11review_proposaladded
Decide one pending proposal. APPROVER OR OWNER KEY ONLY: developer and viewer keys are refused, so the key that configures mandates cannot sign off their output. approve executes nothing; it writes one signed projected-value ledger entry (a re-pin proposal moves the mandate to the newer profile version instead). reject needs a reason: not-material, client-preference, timing, data-is-wrong, already-done, or other (with a note). Refused when the proposal is not pending, has expired, or the household changed since it was computed. An agent should only call this when the person it acts for has made the decision. Same as POST /api/v1/proposals/{id}/approve and /reject.
2026-10-11list_proposalsadded
Proposals Lodestar filed for a person to decide, newest first, optionally filtered by status (pending, approved, rejected, expired, superseded, stale, withdrawn), mandate or household. Each carries the recommendation and its intents verbatim from the decision, the projected value (NOMINAL horizon-end dollars against the current plan, not discounted, not realized) with its basis, the alternatives considered, caveats, and the evidence (stored decision id, record hash, signature). Any key role. Same as GET /api/v1/proposals.
2026-10-11run_mandateadded
Record a manual trigger and run the mandate's cycle now: sweep its strategies on the household's current version, store each decision, and file proposals that clear the gate. Returns the cycle; read proposals with list_proposals and the reasons with get_mandate. Developer or owner key. Same as POST /api/v1/mandates/{id}/run.
2026-10-11get_mandateadded
One mandate and its last 20 cycles, each with the strategies swept and the gate's reason for every candidate it did not propose (below the floor, cooldown, duplicate, max open), so 'why did nothing happen?' has an answer. Any key role. Same as GET /api/v1/mandates/{id}.
2026-10-11list_mandatesadded
The organization's mandates, newest first, optionally for one household or status, with an alert listing trigger events left open over an hour. Any key role. Same as GET /api/v1/mandates.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.

Trust 80 / 100

no-repository

provenance55

liveness100

freshness85

hygiene80

+dns-namespace +website +reachable +uptime-100% ~updated-42d-ago -no-repository

Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed. How it is computed.

Endpoints

remote	auth	reachable	uptime 30d	p50	protocol	last ok
`https://worthune.com/api/mcp/mcp` streamable-http	none	yes	100%	424 ms	2026-07-28	2026-10-19

Tools (30)

`answer_question`	Answer one open question. value proposes the corrected field as a data-change proposal that an approver or owner must approve before anything is written; confirm: true records that the data is right, and the same check will not ask about the field again. Send exactly one of them. Developer, approver or owner key. Refused when the household changed since the question was asked. Same as POST /api/v1/questions/{id}/answer.
`archive_household`destructive	Archive a stored household (never deleted: the row stays readable, leaves the active-household meter, and stops accepting writes or projections). The same operation as DELETE /api/v1/households/{id}.
`create_household`	Create a persistent household resource from a household-schema document (docs/household-schema-spec.md: members, accounts by tax wrapper, liabilities, income and expense streams). Validation rejects with JSON-path errors — fix the payload in one pass. Returns the household id to use with get/replace/project_household.
`create_mandate`	Assign a standing mandate: strategy-watch (one household, the strategies you choose), tax-optimization (one household, minimize-lifetime-tax, the tax strategies) or rules-change (the whole book, Growth and above: when tax rules or your assumption profile change, finds and ranks every affected household; send no household_id). Each has an objective, pinned constraints and an approval policy. Lodestar then works it when a deadline approaches, the household changes, rules or the organization's assumption profile change, a scheduled review comes due, or on run_mandate, and files proposals for an approver. constraints needs horizonYears and exactly one of profile { id, version } or assumptions { … } (never an implicit default); optional: strategies, materialityFloorUsd (default 1000), cooldownDays (30), maxOpenProposals (3), reviewCadence (quarterly), planner ("on"/"off", default off: the organization's certified planner model chooses among gate-passed proposals), taxRates, ladderCandidates, illustrativeCharacteristics, bracketFill { fillToRatesPct?, years? }, charitableGiving { annualGivingUsd, … } (tax-optimization runs charitable-giving only when charitableGiving names the gifts). One mandate per type per household. Each cycle's sweep counts the household as active for the month. Developer or owner key. Same as POST /api/v1/mandates.
`decide_household`	Run a Household Coordination Engine strategy on a stored household and get back a ranked decision object with evidence records. Strategies: withdrawal-sequencing (no params); roth-ladder (params.candidates: [{annualAmountUsd, years}]); ss-claiming (params.candidateAges?: {memberId: [ages 62-70]}); asset-location (params.taxRates: {marginalOrdinary, qualifiedAndLtcg} plus params.characteristics or params.illustrativeCharacteristics: true — the illustrative set is labeled not-a-recommendation and is never applied silently); tax-loss-harvesting (params.ordinaryMarginalRatePct, optional longTermRatePct and realizedGains); annual-gifting (params.doneeCount, params.years); pension-election (params.ownerId, startAge, discountRatePct, options — EPVs from the NCHS life table; adults need sex); bracket-fill (params.fillToRatesPct?: [10\|12\|22\|24\|32\|35], params.years? — Roth conversions sized each year to the top of the bracket); charitable-giving (params.annualGivingUsd, optional otherItemizedDeductionsUsd, bunchYears 2-5, iraDistributionsUsd — every year vs bunched vs QCD routes under the 2026 charitable rules). Alternatives are ranked best-first by a checkable score under a named objective; deltas name their baseline; every projection-backed candidate links its own verifiable record; exclusions are stated in the notes.
`draft_import_mapping`read-only	WS3.5c: AI drafts the mapping; determinism executes it. Send up to 10 sample records from an export (column → string cell) and get back a DRAFT mapping template for import_households' template + records path. Three deterministic gates run before anything returns: strict JSON, the transcription guard (a numeric const anywhere in the draft is rejected — numbers bind to columns, never to values a model wrote), and the real import dry-run over your sample. Nothing is written. Review the template and the unmappedColumns honesty list, then run import_households yourself with dryRun: true over the full export.
`get_decision`read-only	One stored decision in full: the decision object as it was produced, the household version it ran against, and its evidence record with the hashed inputs — enough to re-verify it with /api/v1/records/verify or the SDKs' verifyRecord. Decisions stored before their inputs were retained are returned hash-only and say so. Same as GET /api/v1/decisions/{id}.
`get_household`read-only	Fetch a stored household document and its metadata by id.
`get_household_picture`read-only	One household, one picture: the balance sheet by wrapper and owner, income and spending this year, how current the last computation is against the engine's spec (the same drift reasons the weekly scan delivers), the newest decisions, and a data-quality report naming what is missing and what supplying it would unlock. Sums only — no new number of consequence; nothing is stored. Same as GET /api/v1/households/{id}/picture. Pass as_of (YYYY-MM-DD) to pin the date; it is echoed back.
`get_ledger`read-only	Ledger entries written by approvals, newest first, optionally for one mandate or household, with the total. Each is an evidence record (hash over its inputs and outputs, Ed25519-signed with the key at /api/v1/records/keys) naming the stored decision it came from. Values are PROJECTED and NOMINAL against each decision's own baseline; the total is a sum of projections, not realized value. Any key role. Same as GET /api/v1/ledger.
`get_mandate`read-only	One mandate and its last 20 cycles, each with the strategies swept and the gate's reason for every candidate it did not propose (below the floor, cooldown, duplicate, max open), so 'why did nothing happen?' has an answer. Any key role. Same as GET /api/v1/mandates/{id}.
`get_model_contract`read-only	Get a model's machine-readable contract: required inputs with types and valid domains, cross-field constraints, sentinel-value meanings, and the government constants (with sources) the model uses. Set include_spec to also receive the full specification markdown (exact formulas, assumptions, exclusions, known issues).
`import_households`	Migrate a book (WS3.5): import up to 200 households in one call, with dryRun: true validating everything and writing NOTHING — iterate until the per-row, per-field report is clean, then run for real. Two shapes: households[] of { importKey, label?, household } documents, or template + records — a declarative mapping template (docs/data-migration.md) executed deterministically over raw exported records, so YOU draft the small reviewable template and the engine does the transcription. importKey is the caller's stable id: re-runs are idempotent (already-imported keys skip and report their householdId); imports never overwrite.
`list_decisions`read-only	The append-only history of coordination strategies run on a stored household, newest first — id, strategy, spec version, household version, record hash, when. Metadata only; get_decision returns one in full. Same as GET /api/v1/households/{id}/decisions.
`list_example_households`read-only	Twelve FICTIONAL households, each built to exercise a different part of the planning engine — accumulation, a Roth conversion window, drawdown on a low-basis portfolio, spousal Social Security coordination, running out of money, negative amortization, and more. Use one as a starting point for try_household_projection, or as a worked shape when helping someone describe their own household. Pass an id to get the full document back. No API key required.
`list_households`read-only	List the organization's stored households — id, label, advisorRef, version, status, when it was last computed — without the documents (get_household returns one in full). Defaults to active households; GET /api/v1/households returns every status — pass status: "all" for the same listing.
`list_mandates`read-only	The organization's mandates, newest first, optionally for one household or status, with an alert listing trigger events left open over an hour. Any key role. Same as GET /api/v1/mandates.
`list_models`read-only	List Worthune's Concordance-tested financial calculation models (an independent second implementation must agree with the engine, per the published spec). Returns model names and spec versions. Call get_model_contract before running a model.
`list_proposals`read-only	Proposals Lodestar filed for a person to decide, newest first, optionally filtered by status (pending, approved, rejected, expired, superseded, stale, withdrawn), mandate or household. Each carries the recommendation and its intents verbatim from the decision, the projected value (NOMINAL horizon-end dollars against the current plan, not discounted, not realized) with its basis, the alternatives considered, caveats, and the evidence (stored decision id, record hash, signature). Any key role. Same as GET /api/v1/proposals.
`list_questions`read-only	Lodestar's questions about one field of a household's data (a taxable account with no cost basis, a Social Security stream with no amount, living expenses of zero), asked by deterministic checks in every household cycle; at most one open per mandate. Filter by status (open, answered, confirmed, stale), mandate_id or household_id. Any key role. Same as GET /api/v1/questions.
`manage_preferences`	An advisor's standing preferences, which the gate enforces in every cycle: avoid-strategy (optionally until a date), min-value for a strategy, max-annual-conversion, avoid-alternative. action list (any role); add (an approver or owner key confirms it at once, a developer key only suggests it); confirm a suggestion (approver or owner); remove (a suggestion: developer and up; a confirmed preference: approver or owner). Same as /api/v1/mandates/{id}/preferences and /api/v1/preferences/{id}.
`narrate_decision`read-only	The Verified Narrative: client- or advisor-ready prose for a stored decision (decision_id) or an inline decision object. A model drafts the narrative FROM the decision; a deterministic gate then extracts every number in the draft and verifies each against the decision's own values — correctly-rounded restatements pass, invented numbers reject the draft whole (one retry, then refusal; a narrative is never patched). The response reports how many claims were checked.
`patch_household`	Apply a collection-level delta to a stored household without resending the whole document: set scalars (filingStatus, state), upsert entries by id (replace or append), remove entries by id. expectedVersion (from get_household) is REQUIRED — a delta is only meaningful against a version you have read. The merged result is validated in full; a delta can never produce an invalid household.
`project_household`	Run the deterministic multi-year projection on a stored household — income, RMDs, federal + covered state tax, expenses, amortization, cash flow, net worth per year — optionally with seeded Monte Carlo (same seed, same result). Assumptions: pass your own, pin a profile by id+version, or omit both for the labeled illustrative default; the response always names its assumptionsSource. Every simplification that fired is listed in projection.assumptionsApplied — show your work.
`replace_household`	Full-document replace with optimistic concurrency: pass expectedVersion (from get_household) and a stale write loses cleanly with the current version instead of clobbering a concurrent change.
`review_proposal`	Decide one pending proposal. APPROVER OR OWNER KEY ONLY: developer and viewer keys are refused, so the key that configures mandates cannot sign off their output. approve executes nothing; it writes one signed projected-value ledger entry (a re-pin proposal moves the mandate to the newer profile version instead). reject needs a reason: not-material, client-preference, timing, data-is-wrong, already-done, or other (with a note). Refused when the proposal is not pending, has expired, or the household changed since it was computed. An agent should only call this when the person it acts for has made the decision. Same as POST /api/v1/proposals/{id}/approve and /reject.
`run_mandate`	Record a manual trigger and run the mandate's cycle now: sweep its strategies on the household's current version, store each decision, and file proposals that clear the gate. Returns the cycle; read proposals with list_proposals and the reasons with get_mandate. Developer or owner key. Same as POST /api/v1/mandates/{id}/run.
`run_model`read-only	Run a Concordance-tested calculation model. Inputs must satisfy the contract from get_model_contract (all fields required, values inside their domains — out-of-domain requests are rejected, never clamped). The response echoes inputs, spec version, assumptions, triggered sentinels, and sourced constants; outputs are exactly what the engine computed, untouched. Share the matching interactive calculator with users: https://worthune.com/scenarios/<model> for scenario models.
`try_household_projection`read-only	Run the deterministic multi-year household projection on a document you pass in — income, RMDs, Roth conversions, federal and covered-state tax, expenses, amortization, the tax-grossed-up deficit draw, and net worth per year — optionally with a seeded Monte Carlo. NOTHING IS STORED: no household is created, no id issued, no record kept. Takes any key, a free sandbox key included (worthune.com/sandbox). The response carries every simplification that fired in projection.assumptionsApplied and an evidence record whose hash reproduces on an identical document, so you can show your work. Use list_example_households for a starting shape. For a household that persists — with an id, bulk import, webhooks and drift detection — see create_household.
`verify_claim`read-only	Verify claims about a model's outputs against the engine before presenting them to a user. Pass the model inputs plus one or more claims ({path, op, value}); each claim comes back verified, violated, or out-of-scope, with the engine's computed value as proof and a decision-record hash tying the verdict to this spec version and these inputs. Out-of-scope means the model does not compute the claimed quantity — this tool never guesses. Use it to check a number you are about to state; use run_model when you want the full output envelope.

Schemas: list_tools.

Similar MCP servers

Official server.json

{
  "name": "com.worthune/models",
  "icons": [
    {
      "src": "https://worthune.com/brand/icon-512.png",
      "sizes": [
        "512x512"
      ],
      "mimeType": "image/png"
    },
    {
      "src": "https://worthune.com/brand/icon-192.png",
      "sizes": [
        "192x192"
      ],
      "mimeType": "image/png"
    }
  ],
  "title": "Worthune Verified Financial Models",
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "remotes": [
    {
      "url": "https://worthune.com/api/mcp/mcp",
      "type": "streamable-http"
    }
  ],
  "version": "1.8.0",
  "websiteUrl": "https://worthune.com",
  "description": "61 verified financial models and a household planning engine: 20 MCP tools, 6 keyless, specs cited."
}