Layerz

Name: Layerz
Author: layerz

Layerz is a structured financial modeling layer for AI agents.

От сообществаРаботаетБез входаГлобальныйБесплатноТолько чтение

Что умеет

Layerz List Models: List models the authenticated user can access. Each result includes can_write (true when owner or editor). For model-scoped API keys, returns only the bound model.
Layerz Get Model: Read full detail of a model: items, lists, timelines, and metadata. Heavy payload — prefer layerz_read for snapshots.
Layerz Create Model: Create a new financial model. Returns the model detail with its UUID. Propose a `glyph` coherent with the model's business/profile (kebab-case Lucide name): SaaS/growth→"trending-

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

Layerz is a structured financial modeling layer for AI agents. Build, version, and audit financial models without drift, then export to Excel, from Claude or any MCP client. It separates model logic (the DAG of variables, timelines, formulas) from data, so models stay auditable, reusable, and safe to change. Remote MCP server with OAuth. Endpoint: https://app.layerz.cc/mcp . Learn more: https://app.layerz.cc/for-agents

Список инструментов сервера (41)

Технические названия из tools/list. Нужны только разработчикам.

layerz_list_models	List models the authenticated user can access. Each result includes can_write (true when owner or editor). For model-scoped API keys, returns only the bound model.
layerz_get_model	Read full detail of a model: items, lists, timelines, and metadata. Heavy payload — prefer layerz_read for snapshots.
layerz_create_model	Create a new financial model. Returns the model detail with its UUID. Propose a `glyph` coherent with the model's business/profile (kebab-case Lucide name): SaaS/growth→"trending-up"/"chart-line"/"rocket", banking/debt→"landmark"/"banknote", real estate→"house", restaurant/café→"utensils"/"coffee", energy→"wind"/"sun", HR/headcount→"users", valuation/DCF→"scale", budget/treasury→"wallet"/"credit-card". Not available for model-scoped or read-only API keys.
layerz_list_templates	List reusable model templates (curated `system` templates + your own). Each entry carries name, subtitle, glyph (Lucide emblem icon), description (the template's markdown usage guide), category, scope, and a structure summary (top-level section names + item count) so you can pick the right base from a prompt. Account-level, read-only. Fork a whole template into a new model with layerz_create_model({ template_id }); apply one as a module into an existing model with layerz_build_from_blueprint({ template_id, mode: "merge" }).
layerz_get_template	Read a template in full: its blueprint plus its `description` — the markdown usage guide (what it is, how to use it, which business rules to fill). The guide IS the underlying model's FINANCE.md (a template's id equals its model id): to edit a template's guide, edit that model's FINANCE.md via layerz_set_finance_md — it propagates live, not as a snapshot. After forking or applying a template, follow the guide and update the new model's FINANCE.md so the conventions and objective match the project. Account-level, read-only.
layerz_promote_template	Promote a model you own into a reusable template — flips it in place (no copy), so it keeps its content and stays editable, and surfaces in layerz_list_templates. The template's blueprint is derived on demand and its usage guide IS the model's FINANCE.md, so edit the guide later via layerz_set_finance_md on the same model. `scope` defaults to `user` (private, Pro feature). `scope: 'system'` publishes into the curated onboarding catalog visible to everyone and is admin-only. Not available for read-only or model-scoped API keys.
layerz_read	Read model snapshot (items + optional computed values). Filter by UIDs or roles. Pass with_values=true to compute. If the response leads with `computable: false`, the DAG is broken (see `errors[]`, e.g. CIRCULAR_DEPENDENCY): every series is a degenerate zero-fill — fix the model before reasoning on values.
layerz_dependencies	Trace an item's dependency graph: `precedents` (items its formula references) and `dependents` (items that reference it). Like Excel trace precedents/dependents. Use `depth` for transitive walks and `direction` to scope.
layerz_validate_model	Audit a model without writing: runs the core model validator (structural / formula / timeline checks) and returns a structured report `{ ok, error_count, warning_count, errors[], warnings[] }`. This is NOT a byte-for-byte preview of a write: the write path auto-repairs some of these (e.g. it strips a dangling `source_uid`/`inputs` instead of refusing) and enforces a few invariants this audit does not (e.g. a dangling `parent_uid` is rejected only at write), so `ok:true` is a sanity signal, not a guarantee the next write succeeds. Each issue carries a category `code` (e.g. UNKNOWN_UID = dangling ref, CIRCULAR_DEPENDENCY, INVALID_ROLE_CHILD = misplaced chart/kpi/mini_table, TIMELINE_MISMATCH) + `message` + `item_uids`. Read-only — use it as an agent-side sanity check before sharing.
layerz_patch	Mutate a model with batched ops (create/replace/update/delete/move/list_create/list_update/list_delete/meta). `ops` must be JSON objects with a string `op` field, never JSON-encoded strings. The batch is all-or-nothing: if one op fails validation or a `replace` migration is incompatible, nothing is persisted. Give a create op a temp `id` and reference it as `parent`/`source`/`target`/`series` on later ops in the same batch (wire references before the real UID exists). Temp ids also resolve inside FORMULAS (`$_my_id * 1.2`), matching whole tokens only, so a full dependency chain ships in one batch — including a SELF-reference: a create may reference its own temp id (or its own `name`) in its formula, e.g. `{op:"create",id:"_y",name:"Annee",formula:"IF($_y_Y-1 = 0, $start, $_y_Y-1 + 1)"}` — no dummy-formula + update round-trip. To swap a referenced item atomically, prefer `replace` over create+rewire+delete. Hierarchy rules: only `section` and `dashboard` live at root; `section` accepts every role except chart/kpi/mini_table AND can be nested inside another `section` to model true sub-sections (use this for structural grouping with no values); `dashboard` accepts ONLY chart/kpi/mini_table; `balance` and `formula`-with-no-expression act as aggregators that sum their children (use a no-expression `formula` when you need an aggregate VALUE — e.g. "Total Revenue" — and use a nested `section` when you just need structural grouping with no computed value); a `formula` is an aggregator XOR a transformation — giving it BOTH an expression and children is rejected (`FORMULA_EXPR_AND_CHILDREN`); `assumption` and `callup` are leaves. Callup role: a `callup` is a typed mirror of ONE source whose value flows INTO its parent container — use it for balance flows (a flow attached as a callup child of a `balance`) and for surfacing a value inside a section/subtotal. Set `source` to the source item's UID (or a temp `id` from the same batch). The callup inherits its source's `display_name` and `timeline_ref` — do not set `timeline_ref` on a callup. Do NOT use a callup for arithmetic: inside a real formula, reference the source directly (e.g. `Revenue * 1.2`) rather than mirroring it through a callup first. On create/replace, a `formula` whose expression is a single bare reference with no `timeline_ref` override is auto-posed as a `callup` mirror, so a plain pass-through like `formula:"Revenue"` becomes `callup{source:Revenue}`. Stock-flow modeling (rolling balances — cash, ARR, retained earnings, debt, fixed assets): (1) create a `balance` with `opening_balance: X`; (2) for each flow, create a formula whose value is the per-period delta — outflows must return negative values; (3) attach each flow as a `callup` child of the balance with `source: <flow_uid>`; (4) if a flow depends on the balance itself (interest on debt, churn on ARR), use the lag suffix `_M-1` / `_Q-1` / `_Y-1` on the balance UID to read the previous-period value and break the cycle. A balance without callup children stays flat at `opening_balance` forever — that is almost always a modeling bug. List mode (per-element series): three coexisting concepts must not be confused — (a) "Dataset entity" (plan/actual/forecast, see layerz_import_branch) is a stacked input version of the model; (b) the "Lists registry" (`list_create`/`list_update`/`list_delete`) is a named registry of elements (Functions, Products, Channels, Debt Tranches, Employees…); (c) "list-mode items" are assumption/formula/balance items that carry `liste_ref` and expand to one virtual instance per element. The pre-MDK 0.2.0 `layer` role is gone. Pattern: (1) `{op:"list_create",id:"_functions",name:"Functions",items:[{id:"_eng",label:"Engineering"},{id:"_sales",label:"Sales"}]}` — list_create is idempotent by `name`; both the list itself and each item can carry an `id` (temp_id) usable from later ops in the same batch. (2) Bind on the consumer with `liste_ref:"_functions"` (temp id), display_name, or the returned UID. (3) Populate per-element data via `timeline_values` keyed by element UID, label, or item temp_id: value = `null \| number \| (number\|null)[]`; a scalar is auto-wrapped into a 1-element array. Passing scalar `value`/`values` on a list-mode item is rejected — those fields are silently dropped at compute time. Balance-list rule: when a `balance` carries `liste_ref`, every list-typed child MUST share the same `liste_ref` (mismatch → validator-outputs.ts: "Children of a list-mode balance must share the same list or be scalar"); scalar children broadcast across all elements. Cross-list bridging is declared on the list element itself via `list_update` with `items:[{label:"Direct",mapped_to:{Products:["Pro","Enterprise"]}}]` (channel Direct rolls up products Pro and Enterprise). Values — two regimes, keyed on `liste_ref`: (a) LIST-MODE item → `timeline_values` keyed by element UID/label/temp-id IS the normal write path (see List mode above); `value`/`values` are rejected. (b) NON-LIST item → type a plan/forecast with `value` (scalar, broadcast to every period) or `values` (array at the item’s grain); the patch surface never writes `timeline_values` there, nor on a computed line (formula/balance) — imported actuals/overrides are import-owned (use layerz_import_branch or the Sources import). A one-cell edit uses a period-keyed map `{"2026-06":[val]}` (also "2026" / "2026-Q1"): it merges into the typed `values` series, leaving the other periods intact. Formula language: operators `+ - * / ^ ( )` (`^` = power, Excel semantics: left-associative, binds tighter than ``) and comparisons `> < >= <= = !=`. Scalar functions: IF, AND, OR, NOT, MAX, MIN, ABS, POW, POWER, EDATE, YEAR, MONTH, IN_PERIOD, NPV, IRR, PMT, IPMT, PPMT. IRR/NPV consume a FULL series and must be the item's ENTIRE formula, their series argument a single item reference — `IRR($fcfe)`, `NPV($rate, $fcfe)`; nesting them in a larger expression or passing an expression as the series is rejected (SCALAR_FUNCTION_MISUSE); the result is a single timeless value (timeline `constant`). `IRR($fcfe, CUMULATIVE)` is the temporal variant: one IRR per period over the series from the start through that period (the project-finance run-up line; 0 before convergence). Per-period tokens: `PERIOD_YEAR` (calendar year of the evaluated period — date-gate lines with `IF(PERIOD_YEAR >= commissioning_year, ...)`, no hand-rolled year counter needed) and `PERIOD_INDEX` (0-based position on the item's timeline). Aggregate functions over a UID/list: SUM(operand), AVG(operand), COUNTA(operand), SUMIF(operand, condition_ident OP number), COUNTIF(...), AVGIF(...) — `OP` ∈ `< <= > >= = !=`, RHS must be a numeric literal. The magic identifier `CURRENT_PERIOD` returns the current period's end as a date serial — use it for time-gated patterns: store `Hire Date` as a date serial and write `IF(Hire Date <= CURRENT_PERIOD, salary, 0)` for hire ramps, contract activation, ramp-up, depreciation windows. The magic identifier `LIST_INDEX` (list-mode formulas only) is the current element's 0-based position in the list — auto-populate age/seniority offsets: `cohort_lag = LIST_INDEX`, then `retention = retention_curve_M-$cohort_lag` reads the curve at each cohort's age with no manual per-element inputs. Lag suffix on any UID or back-ticked name: `_M-N`, `_Q-N`, `_Y-N` (e.g. `cash_eop_M-1`, `` `Total Revenue`_Y-1 ``); variable lag `_M-$delay` reads the offset from another item (`$` + name or uid; rounded, clamped ≥ 0, converted at the reading item's grain). In a list-mode formula a list-dimensioned offset resolves PER ELEMENT (each element shifts by its own lag — the ramp-up/cohort primitive); a list offset that cannot project onto exactly one element is rejected (LIST_LAG_REF_AMBIGUOUS). Self-referencing lags are legal and the standard way to break instant cycles. Subscript syntax: `` Item[`key`] `` slices a list-dimensioned item by a list-item UID/label of its `liste_ref` (returns that element's scalar series), or by a key from any list reachable via `mapped_to` (auto-aggregates the matching source items — equivalent to a SUMIF over `mapped_to`). Lag suffixes also apply to a subscript: `` Salary[`Sales`]_Y-1 ``, and `Item[i]_M-1` is the current element's previous-period value — the per-element roll-forward (`Headcount[i] = Hires[i] + Headcount[i]_M-1`); a bare lagged self-ref in a list-mode formula is the list TOTAL re-added into every element (×N compounding, warning BARE_SELF_LAG_IN_LIST_FORMULA) — use `[i]_M-N`. MDK 0.7.0: a bare reference to a list-dimensioned item is its TOTAL (sum across the dimension) in EVERY context; `wrap in SUM(...)` only to also collapse across time. For the per-element value inside a list-mode formula (one whose own `liste_ref` is set), use the current-element subscript `Item[i]` — same-list → that element, cross-list → the items mapped to it. Example allocation: `G&A[i] = Shared G&A Revenue[i] / Revenue` (per-element numerator, bare total denominator). Do NOT introduce a scalar callup to get a total — a bare reference already is the total. Not supported: string literals (use backtick-quoted identifiers or numeric literals), SUMIFS / COUNTIFS with multiple criteria (compose with a list-mode formula instead), user-defined functions, ternary `?:` (use `IF(...)`). KPI items targeting monthly data may use annual shorthand like `2028`, which normalizes to `2028-12`. The `meta` op sets model identity: `name`, `subtitle`, `finance_md`, `timelines`, `formats`, `default_branch`, and `glyph` — the model emblem, a kebab-case Lucide icon name (https://lucide.dev/icons) validated at write time (unknown names rejected with suggestions; aliases like cash→banknote normalized; `null` → monogram). Formula-list (cross-dimension aggregation): a scalar formula whose operand carries a `liste_ref` auto-aggregates that operand by sum across its dimension; combined with `mapped_to` on the operand list, the subscript `` Operand[`key`] `` rolls up the source elements mapped to `key` (a SUMIF over the mapping). This is the most powerful Layerz pattern: prefer it over a parallel "code" column + `SUMIF(..., = N)`. Inspect existing mappings via `layerz_read` (each list exposes `mappings` per element). Chart list rendering: `list_mode` (chart field) picks how list-backed series render — 'split' (default) explodes EVERY list-backed source into one series per list element (a single-source chart becomes the stacked breakdown, titled after the source; a multi-series chart prefixes each element with the item name — two 10-element lists = 20 legend rows), 'total' plots each item's aggregate as ONE series (chart a list total directly, no `$item * 1` mirror formula needed). Pass `compute` with UIDs to get calculated values back. Not available for read-only API keys.
layerz_list_branches	List the Layer definitions on a model (id, display_name, priority, source_hint, file_name, actuals_through, actuals_through_locked, created_at). The default Layer is always present. actuals_through_locked means the real/forecast cutover was pinned by the user — source syncs will not move it.
layerz_update_branch	Patch an existing Layer (display_name, priority, source_hint, file_name, actuals_through). The default Layer only accepts display_name/source_hint/file_name/actuals_through. Setting actuals_through PINS the real/forecast cutover: window-derived source syncs stop rewriting it (actuals_through_locked: true on the Layer). actuals_through: null resets to auto — the pin and the manual value are cleared and the next windowed sync re-derives the cutover. Not available for read-only API keys.
layerz_delete_branch	Delete a Layer and every input row that carries its dataset_id. Refuses to delete the default Layer. Not available for read-only API keys.
layerz_import_branch	Import a stacked branch of values onto the model. Default mode creates a BranchDefinition (scenario branch) and writes the supplied entries as input rows tagged with the new dataset_id. Optionally set branch.actuals_through to mark its real/forecast cutover. Pass `replace: true` together with `branch.id` to atomically refresh an existing branch instead: its id and created_at are preserved, its mutable metadata is patched with any value you supply (`display_name` is optional here — omit it to keep the current name; supplying it is an explicit rename), the previous input rows are wiped and the new entries written — all in one persist call. Carry-forward: for a period the new entries do NOT cover, the prior value is retained (so a narrower re-sync never silently zeroes the uncovered tail). To actually clear a period, send it explicitly with value 0. The result `warnings` flag any line the import left all-zero though it had values before. Entries reference items by item_uid (existing) or item_label (matched by display_name, else created as assumption). Instead of `entries`, pass `file_id` (from layerz_create_upload_url) to import a spreadsheet server-side: the file is parsed, each row is classified with THIS model's mapping set (the same rules layerz_list_mappings shows — no need to copy them), aggregated per (item, period), and written. A rule targeting a LIST-MODE item resolves each row's list entry from its category/dimension column (cost center / BU — e.g. the DATEV Kostenstelle) matched against the list entries by label; a row whose dimension matches no entry is skipped per-row, never a whole-import failure. A raw DATEV EXTF/Buchungsstapel export is detected natively (metadata line skipped, Umsatz signed by the Soll/Haben mark, compact Belegdatum dated from the fiscal-year header) — pair it with the Germany (SKR03) or (SKR04) mapping template matching the ledger's chart. Add `sheet_name` for a multi-sheet workbook and `structure_override` to fix a misdetected ledger (e.g. a Débit/Crédit split, an S/H `sign_column`, or an account-code column taken as the label). Re-importing an existing source? Pass `replace_source_id` (id from layerz_list_integrations) to refresh that file source's staged transactions in place instead of creating a second one; a legacy empty file source bound to the branch is adopted automatically. Exactly one of `entries` or `file_id` is required; the result then also carries `skipped` (rows that produced no entry) and `mapping_drift` (rules whose target item no longer exists). Each entry's timeline_ref must match the target item's native grain exactly (or be `constant`, which broadcasts to any grain). Any other grain — finer or coarser — is rejected to avoid corrupting other periods, because rows resolve cell-by-cell by raw array index. Aggregate (or split) the source to the item's grain before importing. Targeting a formula or balance item writes a per-period override (actual): on covered periods the imported value replaces the computed one and feeds downstream periods (e.g. actuals-then-forecast). Compute resolves cells by branch priority at load time. Result: `entries_written` counts supplied entries; `inputs_written` counts persisted rows after per-period compaction (≤ entries_written) and mirrors `delete_branch.inputs_removed`. Pass `dry_run: true` to preview the impact WITHOUT persisting: the model is left untouched and the result carries `would_persist:false`, the same `inputs_written`/`inputs_removed`/`created_items`/`matched_items` counts, `overridden_items` (existing items whose value this branch would overlay), and `validation_errors_new` (errors the import would introduce). Audit it, then re-call without `dry_run` to commit. Deterministic. Prefer the `file_id` path for spreadsheets (server-side parse + classify); build `entries` by hand only for values you compute yourself. Not available for read-only API keys.
layerz_list_integrations	List every data source feeding a model: API connectors (Qonto, Pennylane, Stripe, Airtable, Metabase) AND file imports (kind csv \| fec — a staged upload from the web wizard or layerz_import_branch { file_id }). Each row carries kind, display_name, branch_ids (the branches it feeds), sync status and last_synced_at. A row with `legacy_import_id` set is a materialized pre-staging import: it owns input rows in the model but staged no transactions — layerz_list_transactions derives its detail from those rows, and layerz_delete_integration purges its values. Never returns stored credentials. Browse a source's staged rows with layerz_list_transactions; mutate it with layerz_manage_integration (a file source supports sync/update/rebind too — its sync replays the projection over the staged rows) or disconnect it with layerz_delete_integration. Connect a new API key from the web app.
layerz_manage_integration	Sync or reconfigure a data source (API connector Qonto, Pennylane, Stripe, Airtable, Metabase, or a csv/fec file import) by `op`. `sync`: pull the provider's actuals into the bound branch — an idempotent replace of this source's own rows, never the baseline; `dry_run: true` previews the impact without committing; on a FILE source there is nothing to fetch, so sync replays the projection over its already-staged rows (use it after changing mapping rules); for a still-unbound connection, `target_branch_id` lands actuals on an existing branch (e.g. `default`). `rebind`: re-point the connector at a different set of existing branches (`branch_ids`) — wipes its rows from detached branches and reprojects into the new ones, never clobbering manual edits. `update`: rename the source (`display_name`, pure metadata) and/or change its non-secret import config (see the `config` field docs) and replay the projection over the staged rows; changing `config.import_level` or a tabular source's mapping re-fetches + re-stages instead. Every projecting op reports `unmapped` (keys routing to no line), `proposed_window` (the span to confirm), `deletable_items` (empty import-only items a remap orphaned — proposed, never auto-deleted), `cutover_changes` (a rewritten real/forecast cutover — pin it with layerz_update_branch { actuals_through } if a window should not close periods) and `warnings`. To disconnect a source, use layerz_delete_integration. Connecting a new key stays in the web app — credentials are never sent over MCP. Not available for read-only API keys.
layerz_delete_integration	Disconnect a data source (API connector or file import), drop its staged transactions AND purge everything it projected into the model — its input rows, provenance tags and import entry. Items and the branch it fed are kept, emptied of its values, so a re-import can refill them. When the purge would destroy values the source cannot re-project (zero staged transactions, e.g. a materialized legacy import), the delete is refused with PURGE_CONFIRMATION_REQUIRED plus a preview of what disappears (rows, items, period span) — surface the preview to the user, then retry with `confirm_purge: true` to purge anyway (rollback stays possible via version restore). Not available for read-only API keys.
layerz_list_shares	Read a model's sharing roster: everyone with access — the owner, active collaborators (viewer\|editor) and pending email invites — each with its role and id. Available to any member, including read-only API keys. Sharing is invitation-only — there is no public link; the model URL (see `url` on get_model/list_models) is the same for access and for sharing, and a logged-out visitor is routed through signup.
layerz_share_model	Invite an email to a model as a viewer or editor: a registered user gets an active share, an unregistered one a pending invite; both receive an email. Owner-only; not available for read-only API keys. Read the roster with layerz_list_shares.
layerz_revoke_share	Remove a collaborator or pending invite from a model by `principal_id` (the id returned by layerz_list_shares — a user id for an active share, or the pending-invite id). Owner-only; not available for read-only API keys.
layerz_external_ref_status	List a model's external references (links to items of other Layerz models), each with a `stale` flag (the source model changed since the last sync in a way that moves the values) and its source health. Readable by any member, no source-model access needed. Mutate links with layerz_external_ref / layerz_unlink_external_ref.
layerz_external_ref	Link this model to an item of ANOTHER Layerz model (external ref, like an Excel linked workbook) by `op`. `link`: create (or retarget with `uid`) a non-list assumption whose `values` hold a materialized snapshot of the source item's computed series, projected to this model's grain (periods outside the source's coverage stay null); requires read access to the source model; the line is then referenceable in formulas like any assumption. `refresh`: re-read every linked source (or just `uids`) and rewrite the snapshots — the ONLY way values update; never automatic; per-link failures (source deleted/inaccessible or item gone) are reported without touching the stored values. Read links with layerz_external_ref_status; detach one with layerz_unlink_external_ref. Not available for read-only API keys.
layerz_unlink_external_ref	Detach an external reference by `uid`, keeping its snapshot values — the line becomes an ordinary assumption that no longer follows its source. Not available for read-only API keys.
layerz_list_transactions	Read a data source's staged transactions (API connector or csv/fec file import — any id from layerz_list_integrations) annotated with where the projection routes each one: the target item and whether it matched a `rule` or an `auto`-created item, or the reason it was skipped. A row with no matching rule is skipped (mapping is the only routing path — no fuzzy match) unless the source opts into auto-create; a row matched by an `__ignore__` rule has status `ignored` (deliberately out of scope). Read-only — it never writes. Use it to find rows that route nowhere before writing a mapping rule. Filter with `period` (YYYY-MM) and `q` (substring on description/category). Pass `format: "csv"` to instead re-download the FULL staged import as a CSV file: returns a 24h signed `download_url` (filters don't apply, no routing annotations — the normalized rows as-staged).
layerz_list_mappings	List the import classification rules in scope for a model. Each mapping set is labeled with a `scope`: `model` (this model's own rules), `system_template` (the curated country catalogs — PCG, US GAAP, UK, SKR03/04), or `user_template` (your reusable catalogs). A model classifies ONLY with its own `model` rules — catalogs and templates apply by being imported (see layerz_import_mapping_template), never implicitly (a pre-cutover account source may still classify through the legacy PCG overlay until its next sync materializes those rules into the model set). A `pattern` is a case-insensitive GLOB where `` matches anywhere: `641` (prefix), `PERPLEXITY` (contains), `641` (suffix), or exact `601000` (no ``). The default result == what the importer actually applies; pass `include_user_mappings: true` to ALSO surface your account-wide catalogs for discovery. Pass `include_coverage: true` to add, per rule, the count of staged transactions it matches (`match_count`) plus a `coverage` block (auto-created count + the top unrouted keys) — the actionable input for writing rules. `templates` lists the catalogs you can fork. Read-only.
layerz_import_mapping_template	Import a mapping template (or one of your catalogs) into this model by DUPLICATING its rules into the model's single mapping set ("one model = one set"; an imported rule wins on a pattern conflict). Each rule's target is translated to this model's items by display name. This is how a template "applies" — there is no implicit cross-model application. `template_id` is a set id from layerz_list_mappings `templates` (scope `system_template` or `user_template`). Re-sync to classify with the new rules. Not available for read-only API keys.
layerz_set_mapping	Create or update an import classification rule (upsert by pattern) in this model's single mapping set ("one model = one set"; created on first use). `pattern` is a case-insensitive glob where `` matches anywhere (`Apport` prefix, `PERPLEXITY` contains, `*641` suffix, exact `601000`) tested against the keyed source field; `target` is the item display name or uid it routes to — or the literal `__ignore__` to deliberately route matching rows nowhere (they classify as `ignored` and stop counting as unmapped); `sign` (natural \| negate \| absolute) adjusts the amount. To reuse a catalog's rules instead, import it first (layerz_import_mapping_template). Re-sync (or layerz_manage_integration { op: "update" }) to apply. Not available for read-only API keys.
layerz_delete_mapping	Delete an import classification rule by id (from layerz_list_mappings). Re-sync to re-project without it. Not available for read-only API keys.
layerz_create_upload_url	Issue a short-lived signed URL to upload an Excel/CSV file straight into Storage, then call layerz_parse_file with the returned file_id. PUT the file to signed_url directly (e.g. `curl -X PUT "<signed_url>" -H "Content-Type: <content_type>" --data-binary @file`) — the binary never enters the agent context. Limits: 25 MB, MIME whitelist (xlsx, xls, csv, json, txt); the file_id expires after 24h.
layerz_parse_file	Parse an Excel/CSV file uploaded out-of-band via layerz_create_upload_url. Returns the detected timeline, structure (suggested_structure), row labels, and column headers (with samples) — token-optimized, never includes the raw binary. The agent typically pipes the row labels into layerz_match_items, then builds entries[] for layerz_import_branch. If a long-format ledger is misdetected (e.g. a "Débit" column chosen as the value, dropping credit rows, or an account-code column taken as the label), re-call with structure_override to correct the columns.
layerz_match_items	Resolve free-text labels (e.g. row labels from a parsed Excel) to existing item UIDs on a model. Returns the top 3 candidates per label across four methods (exact_uid, exact_name, slug, fuzzy Levenshtein), with a score. Empty candidates means the agent should create the item before importing. No LLM call — purely deterministic.
layerz_export	Generate the model as an Excel (.xlsx) workbook and return a short-lived download URL — the same export the web app produces (Intro + per-section sheets + native charts and dashboards, with live Excel formulas). When the model has branches, the statements and single-value widgets reflect one branch: pass `branch_id` to pick it (defaults to the base/default branch); dashboards always keep every branch they break down by. The file is stored out-of-band in private Storage and the response carries a signed `download_url` the user can open directly; the binary never transits the agent context. The URL and the stored file expire after 24h, then a daily purge removes them. Re-call the tool to refresh an expired link. Returns { download_url, filename, size, file_id, expires_at, structure_hash, values_hash }. A read operation — available for read-only API keys too.
layerz_build_from_blueprint	Build/extend a model from a strict Blueprint. Each item carries a single `name` (visible label + formula identifier). Names must be unique within the model (case-insensitive). Callup items omit `name` — they inherit it from `source`. Multi-word names use back-ticks in formulas (e.g. `` `Annual Revenue` * 12 ``). Use this for bulk creation of whole sections with their hierarchy; for incremental edits on a single item or two, prefer layerz_patch (which also supports section+children in one batch via temp `id`/`parent`). Recursive time-series (roll-forwards, cumulative trackers, indexation) use the lag suffix `<name>_M-N` / `<name>_Q-N` / `<name>_Y-N` (and `<name>_M-$var` for dynamic lag). Self-referencing lag is allowed (`A = A_M-1 + delta`) — only zero-lag self-reference (`A = A + …`) is rejected. Cross-granularity: `_Y-1` on a monthly item = 12 periods, `_Q-1` on monthly = 3, `_Y-1` on quarterly = 4. At period 0 a lagged ref returns 0 (or `opening_balance` for balance items). For canonical BOP/EOP patterns prefer a `balance` item with `opening_balance` and children for the period deltas. Alternatively pass `template_id` (mutually exclusive with `blueprint`, discover via layerz_list_templates) to apply a stored template as a module: its blueprint is loaded server-side and merged in. After applying, read the template guide (its `description`, via layerz_get_template) and update the model FINANCE.md (layerz_set_finance_md) to match the project. Not available for read-only API keys.
layerz_get_finance_md	Read the FINANCE.md attached to a model — the open standard (current draft: v0.1) for the financial conventions that govern this model (currency, language, glossary, plus all the rationale in the Markdown body). Call this FIRST when starting to work on a model. Every other tool result must be interpreted under those conventions (denomination, sign convention, glossary, …). Spec — https://github.com/layerzlabs/finance-md. Returns { raw, source: "auto"\|"user"\|"imported", spec_version, generated_at?, updated_at?, front_matter, validation_errors }. `null`/204 if the model has no FINANCE.md yet.
layerz_set_finance_md	Upsert the FINANCE.md for a model. Accepts the full Markdown (YAML front matter + body). Typical usage: an agent running locally reads `FINANCE.md` at the project root and pushes it here at session start so subsequent layerz_patch / layerz_build_from_blueprint calls operate under the same conventions. Set `source: "imported"` when syncing from a local file, `"user"` when authoring/editing in-place. `"auto"` is reserved for generator output. When the model is a template (its id equals the template id), this FINANCE.md IS the template's usage guide (layerz_get_template `description`) — editing it here updates the guide live. The content must parse as a YAML front-matter document. Structural schema warnings are surfaced in the response but do not block persistence — the spec is intentionally progressive. Not available for read-only API keys.
layerz_get_custom_instructions	Read the account-wide custom instructions the user has set for AI agents (their "Custom instructions", capped at 3000 chars). These are user-level, not model-level — they apply across every model in the account, on top of each model’s FINANCE.md. They are also delivered in the MCP server instructions at session start. Treat them as standing preferences (conventions, tone, modelling habits) and follow them unless a specific model’s FINANCE.md overrides them. Returns { content }. `content` is an empty string when none are set.
layerz_set_custom_instructions	Upsert the account-wide custom instructions for the authenticated user (max 3000 chars). Plain Markdown/text. Account-level: applies to all models. Prefer editing FINANCE.md for model-specific conventions; use this for cross-model preferences. Not available for read-only API keys.
layerz_history	List the most-recent change history (versions) for a model. Each version is a full snapshot persisted at a single mutation boundary (one chat turn, one user save, one API push, …). Use the returned `revision_id` (sha256 of the snapshot) with `layerz_diff` or to detect concurrent writes — a stable revision_id between two reads means the model has not changed. Versions older than the user plan history window are filtered out server-side. Pass `since` (ISO timestamp) or `limit` to scope the response. Returns { current_revision_id, current_version_number, versions: [{ revision_id, version_number, created_at, trigger_type, actor_user_id, label, conversation_id, turn_index }] } — newest first.
layerz_history_for_item	Trace the per-item change history for one UID — when it was added, modified, or removed, who did it, and which fields changed each time. Walks the version history oldest→newest, diffs consecutive snapshots, and reports only events where the requested UID changed. `fields` is the same shape as `layerz_diff` field-level entries. Returns { uid, events: [{ revision_id, version_number, created_at, actor_user_id, trigger_type, status: "added"\|"removed"\|"modified", fields?: [{ field, oldValue, newValue }] }] } — newest first.
layerz_diff	Compute a semantic diff between two model revisions (added / removed / modified items, plus metadata changes). Each endpoint accepts exactly one of `{ revision_id }` (preferred — stable sha256), `{ version_number }`, or `{ id }` (raw row UUID). Omit `to` to diff against the current live model. Returns { from: { revision_id, version_number, created_at }, to: { revision_id, version_number, created_at }, diff: { items: [{ uid, displayName, status, fields? }], metadata: [...], summary: { added, removed, modified } } }.
layerz_restore_version	Restore the model to a previous version, replacing the current items, schema, and inputs with that snapshot. Identify the target with exactly one of `{ revision_id }` (preferred — stable sha256 from layerz_history), `{ version_number }`, or `{ id }` (raw row UUID). Non-destructive: the current live state is first saved as a new `restore` version, so a restore can itself be undone by restoring that backup. The restored state is then recorded as its own history entry labelled with your `summary`. `backup_version_id` is null when the live state already matched the latest snapshot (nothing new to back up) — the prior state stays recoverable from that existing snapshot. Pick the target by reading layerz_history / layerz_diff first. Returns { ok, restored_version_id, restored_version_number, restored_revision_id, backup_version_id }. Mutating — not available for read-only API keys. Requires write access; the target must be inside the plan history retention window.