Skip to main content
Glama

Build from blueprint

layerz_build_from_blueprint
Destructive

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'merge' (default): add to the existing model, reusing items by display_name. 'replace': wipe non-default sections first.
dry_runNoValidate the blueprint and report errors without writing anything.
summaryYesRequired: short human-readable note (3–100 chars) summarising what this change does. Shown as the label in the model version history. Be specific (e.g. "Renamed Revenue to Net Revenue", "Imported 2024 OPEX from Excel").
model_idNoTarget model UUID. Required for user-scoped API keys; ignored (or validated against scope) for model-scoped keys.
blueprintNoStrict Blueprint object. Shape: { project?: string, timelines?: { monthly?: {start,end}, yearly?: {start,end}, quarterly?: {start,end} }, lists?: [{ display_name, items: [{label, mapped_to?: Record<targetListDisplayName, sourceLabels[]>}] }], sections: [{ name: "P&L", items: [{ role: "assumption" | "formula" | "callup" | "balance" | "chart" | "dashboard" | "kpi" | "mini_table", name, timeline_ref?, value?, values?, formula?, item_style?, opening_balance?, liste_ref?, timeline_values?: Record<elementLabel, (number|null)[]>, children?: [{name}], … }] }], dashboards?: [{ name, items: [{role: "chart" | "kpi" | "mini_table", …}] }] }. At least one section is required. Items reference each other by display_name (formula inputs, callup source, chart series). Stock-flow pattern: declare a `balance` with `opening_balance` and put `callup` items inside its `items` referencing the source flows by name; outflows must be formulas that return negative values; break self-referencing cycles with the lag suffix `_M-1` / `_Q-1` / `_Y-1` on the balance name. Roll-forwards & recursion use the lag suffix `<name>_M-N` / `_Q-N` / `_Y-N` (self-referencing lag is allowed, e.g. `Tariff = Tariff_Y-1 * (1 + Inflation)`); for BOP/EOP prefer a `balance` with `opening_balance` and `children` for the period flows. Full roll-forward cookbook (debt, DSRA, rolling min DSCR, balance-list) in docs/mdk-format.md. List mode (per-element series via the lists registry): declare named lists in `lists: [{display_name:"Functions", items:[{label:"Engineering"},{label:"Sales"},{label:"G&A"}]}]`, then bind a consumer item via `liste_ref:"Functions"` and provide `timeline_values: {Engineering:[1200000,1500000], Sales:[800000,950000], "G&A":[400000,420000]}` keyed by **element label** (resolved to UIDs at compile time). Works for `assumption`, `formula`, and `balance`. Two-dimension breakdowns compose with `mapped_to` on the list element: `lists:[{display_name:"Products", items:[{label:"Pro"},{label:"Enterprise"}]}, {display_name:"Channels", items:[{label:"Direct", mapped_to:{Products:["Pro","Enterprise"]}}, {label:"Partner"}, {label:"Self-serve"}]}]` says channel Direct rolls up products Pro and Enterprise, enabling Revenue × Products × Channels cross-aggregation. Balance-list rule: a `balance` with `liste_ref` requires every list-typed child to share the same `liste_ref`; scalar children broadcast. Set `dry_run: true` to validate without mutating; errors come back with a path you can fix. Full schema: src/core/blueprint-schema.ts.
template_idNoApply a stored template as a module instead of an inline blueprint (mutually exclusive with `blueprint`). Discover ids via layerz_list_templates.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare destructiveHint=true, and the description adds substantial behavioral context: the 'replace' mode wipes non-default sections, dry_run validates without writing, lagged references return 0 at period 0, and the tool is unavailable for read-only keys. It also explains the merge vs replace semantics and the post-apply workflow (read template guide, update FINANCE.md). This goes well beyond what annotations alone provide, though it doesn't enumerate every side effect of a merge operation.

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

Conciseness3/5

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

The description is information-dense and front-loaded with the core purpose, but it is very long and somewhat sprawling. It covers naming rules, lag suffixes, cross-granularity behavior, template workflow, and list mode in a single block. While every sentence carries useful information, the density makes it harder to scan. A more structured layout (short paragraphs or bullets) would improve readability without losing content.

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?

For a complex tool with 6 parameters, no output schema, and destructive potential, the description is remarkably complete. It covers the blueprint schema shape, naming constraints, recursion semantics, cross-granularity behavior, template mode, dry-run validation, and the post-apply workflow. It even points to external docs (docs/mdk-format.md, src/core/blueprint-schema.ts) for deeper detail. An agent has everything needed to decide whether and how to invoke this tool correctly.

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?

Schema description coverage is 100%, so the schema already documents all 6 parameters. The description adds significant meaning beyond the schema: it explains the blueprint shape in detail (sections, items, roles, lists, mapped_to, timeline_values), the lag suffix syntax for recursion, the stock-flow pattern, and the mutual exclusivity of blueprint and template_id. It also clarifies the summary parameter's role as a version-history label. This is rich semantic context that the schema alone doesn't provide.

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?

The description opens with a specific verb+resource: 'Build/extend a model from a strict Blueprint.' It immediately distinguishes itself from layerz_patch by stating this is for bulk creation of whole sections with hierarchy, while incremental single-item edits should use layerz_patch. The title 'Build from blueprint' is expanded with concrete detail about what a blueprint contains (sections, items, names, formulas), so the agent knows exactly what this tool does and how it differs from siblings.

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?

The description gives explicit when-to-use guidance: 'Use this for bulk creation of whole sections with their hierarchy; for incremental edits on a single item or two, prefer layerz_patch.' It also explains when to use template_id instead of blueprint, and notes the tool is 'Not available for read-only API keys.' This is model-level routing guidance that tells the agent exactly when to select this tool versus alternatives.

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