Skip to main content
Glama

Import data into branch

layerz_import_branch
Destructive

Writes values onto a branch of the model, creating the branch when branch.id names none (branch.display_name required then). Two sources, mutually exclusive: entries[] (one value per item and period, items resolved by item_uid or item_label, created as assumptions when absent; entry_uid / entry_label target one entry of a list-mode item) or file_id (an uploaded spreadsheet parsed server-side, rows classified with the source's mapping rules). A new version of a file already imported: file_id + replace_source_id, nothing else (refreshed in place on the branch it feeds, default included). A first file onto the base: file_id + branch.id: "default" (a new source, own rows only).A new file of a kind the model already has: file_id + rules_from_source_id (classified with that sibling's rules, copied onto the new source). An entry's timeline_ref equals the target item's grain or constant; on a formula / balance it is a per-period override; on a callup it lands on the source. replace: true (with branch.id) wipes the branch's rows before writing; replace_scope: 'import' wipes only this source's own rows; merge: true upserts cell by cell; dry_run: true returns the impact without persisting (purged_periods, overridden_items, validation_errors_new, suggested_replace_source). Returns counts, warnings and, on the file path, skipped, opening_entries, rules_copied, file_structure. Persists one version labelled with summary.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "summary": "<summary>",
      "branch": "<branch>"
    },
    "name": "layerz_import_branch"
  }
}

Input Schema

NameRequiredDescriptionDefault
mergeNo
branchYes
dry_runNo
entriesNo
file_idNoUpload id from layerz_create_upload_url ('f_' + 16 hex chars). Alternative to entries[].
replaceNo
summaryYesShort note (3–100 chars) describing the change, stored as the label of the resulting version. Examples: "Renamed Revenue to Net Revenue", "Imported 2024 OPEX from Excel".
model_idNoTarget model UUID. Required for user-scoped API keys; validated against the bound model for model-scoped keys.
sheet_nameNo
record_importNo
replace_scopeNo
replace_source_idNofile_id path only: refresh this existing file source in place (id from layerz_list_integrations) instead of creating a second one. The rows are classified with that source's own rules and replace its rows on the branch it feeds (the default branch included): `replace`, `replace_scope: 'import'` and `branch.id` are implied.
structure_overrideNoOverride auto-detected columns for a long-format/ledger file (e.g. value_column chose "Débit" and dropped credit rows, or an account-code column won the label). Omitted fields stay auto-detected.
rules_from_source_idNofile_id path, new source only: classify this upload with the rules of that source of the model (id from layerz_list_integrations) and copy them onto the new source, existing rules kept — a second file of the same kind starts mapped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / replace_source_id / description
      Previous value: -"file_id path only: refresh this existing file source in place (id from layerz_list_integrations) instead of creating a second one. The rows are classified with that source's own rules plus the model-wide ones, as its sync does."New value: +"file_id path only: refresh this existing file source in place (id from layerz_list_integrations) instead of creating a second one. The rows are classified with that source's own rules and replace its rows on the branch it feeds (the default branch included): `replace`, `replace_scope: 'import'` and `branch.id` are implied."
    • addedInput schema / properties / rules_from_source_id
      Added value: +{
      +  "description": "file_id path, new source only: classify this upload with the rules of that source of the model (id from layerz_list_integrations) and copy them onto the new source, existing rules kept — a second file of the same kind starts mapped.",
      +  "format": "uuid",
      +  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +  "type": "string"
      +}
    • addedInput schema / properties / structure_override / properties / category_column / description
      Added value: +"Category or journal-code column. An opening journal in it (AN, RAN, ANO, AD, or a journal labelled \"à nouveau\") is read as opening entries; remap or ignore this column to change that."
  2. Changed1 schema field changed
    • changedInput schema / properties / replace_source_id / description
      Previous value: -"file_id path only: refresh this existing file source in place (id from layerz_list_integrations) instead of creating a second one."New value: +"file_id path only: refresh this existing file source in place (id from layerz_list_integrations) instead of creating a second one. The rows are classified with that source's own rules plus the model-wide ones, as its sync does."
  3. Changed3 schema fields changed
    • changedInput schema / properties / model_id / description
      Previous value: -"Target model UUID. Required for user-scoped API keys; ignored (or validated against scope) for model-scoped keys."New value: +"Target model UUID. Required for user-scoped API keys; validated against the bound model for model-scoped keys."
    • changedInput schema / properties / structure_override / properties / header_row_index / description
      Previous value: -"0-based header row. Omitted: re-detected for the requested `layout` (a columnar override never inherits the wide-layout period-row guess); the row used is reported back (`file_structure` on layerz_import_branch, `suggested_structure` on layerz_parse_file)."New value: +"0-based header row. Omitted: re-detected for the requested `layout` (a columnar override is re-detected rather than inheriting the wide-layout period-row guess); the row used is reported back (`file_structure` on layerz_import_branch, `suggested_structure` on layerz_parse_file)."
    • changedInput schema / properties / summary / description
      Previous value: -"Required: 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\")."New value: +"Short note (3–100 chars) describing the change, stored as the label of the resulting version. Examples: \"Renamed Revenue to Net Revenue\", \"Imported 2024 OPEX from Excel\"."
  4. Changed1 schema field changed
    • addedInput schema / properties / structure_override / properties / header_row_index / description
      Added value: +"0-based header row. Omitted: re-detected for the requested `layout` (a columnar override never inherits the wide-layout period-row guess); the row used is reported back (`file_structure` on layerz_import_branch, `suggested_structure` on layerz_parse_file)."
  5. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the destructiveHint/readOnlyHint annotations by specifying exactly what gets wiped (`replace: true` wipes the branch's rows, `replace_scope: 'import'` only this source's rows), that `merge: true` upserts cell by cell, that `dry_run: true` returns impact keys without persisting, and that a version labelled with `summary` is persisted. The destructive scope and reversibility story is fully disclosed.

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?

Front-loads the core action and branch-creation rule before the mode recipes, and every sentence carries operational detail. It is dense and run-on in places (the file-path recipes are crammed into one paragraph), which slightly hurts scanability, but there is 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?

For a 14-parameter, nested, destructive write tool with no output schema, the description supplies return values itself (`counts`, `warnings`, `skipped`, `opening_entries`, `rules_copied`, `file_structure`, plus dry-run keys) and covers the destructive/merge/dry-run semantics. An agent has enough to call this correctly without inspecting further docs.

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?

Adds substantial meaning over a 43%-covered schema: item resolution by `item_uid`/`item_label`, `entry_uid`/`entry_label` targeting list-mode entries, and `timeline_ref` semantics per item type (grain or `constant`, per-period override on formula/balance, lands on the source on a callup). Several parameters remain unexplained in the description — `sheet_name`, `record_import`, `branch.priority`, `file_name`, `source_hint`, `actuals_through` — leaving the coverage gap only partly closed.

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 ('Writes values onto a branch of the model') and immediately defines the branch-creation side effect when `branch.id` names none. It is clearly distinguishable from siblings like layerz_parse_file or layerz_read, which do not persist values.

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?

Gives explicit mode recipes: `file_id` + `replace_source_id` for refreshing an already-imported file, `file_id` + `branch.id: "default"` for a first file onto the base, `file_id` + `rules_from_source_id` for a second file of a known kind, and `entries[]` vs `file_id` as mutually exclusive sources. It stops short of routing the agent away from related siblings such as layerz_parse_file or layerz_list_integrations for pre-flight steps.

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