Skip to main content
Glama
Sign In

Layerz

by cc.layerz.app
OverviewDiscussionsAdmin

Export to file

layerz_export

Generates a file from a model and returns { download_url, filename, size, file_id, expires_at }. target: 'model' (default) is the Excel workbook (the same export as the web app: Intro + per-section sheets, native charts and dashboards, live formulas), plus structure_hash / values_hash; when the model has branches, the statements and single-value widgets follow branch_id (default: the base branch) while dashboards keep every branch they break down by. target: 'transactions' is the full staged import of the data source source_id as a CSV file (no filters, no routing annotations), plus row_count. Each call persists a new private file in Storage, where the file and its signed download_url expire after 24h; the model itself is not modified, so the tool stays available to read-only keys, off quota.

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": "layerz_export"
  }
}

Input Schema

NameRequiredDescriptionDefault
targetNomodel (default): the Excel workbook of the model. transactions: the staged import of `source_id` as a CSV file.
model_idNoTarget model UUID. Required for user-scoped API keys; validated against the bound model for model-scoped keys.
branch_idNotarget model only. Branch the statements and single-value widgets follow (default: the base branch). Dashboards keep every branch.
source_idNotarget transactions only (required there). Data source id as returned by layerz_list_integrations.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / branch_id / description
      Previous value: -"Branch the statements and single-value widgets follow (default: the base branch). Dashboards keep every branch."New value: +"target model only. Branch the statements and single-value widgets follow (default: the base branch). Dashboards keep every branch."
    • addedInput schema / properties / source_id
      Added value: +{
+  "description": "target transactions only (required there). Data source id as returned by layerz_list_integrations.",
+  "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 / target
      Added value: +{
+  "description": "model (default): the Excel workbook of the model. transactions: the staged import of `source_id` as a CSV file.",
+  "enum": [
+    "model",
+    "transactions"
+  ],
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / branch_id / description
      Previous value: -"Branch to export for the statements/single-value widgets. Defaults to the base branch. Dashboards keep every branch regardless. Discover ids via layerz_list_branches."New value: +"Branch the statements and single-value widgets follow (default: the base branch). Dashboards keep every branch."
    • 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."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

It adds substantial context beyond the annotations: each call persists a new private file, that file and its signed URL expire after 24h, and the model itself is untouched so the tool works with read-only keys and bypasses quota. The non-idempotency is effectively explained by "persists a new private file" on every call, though the slight tension with readOnlyHint=false could be spelled out more explicitly.

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?

The return contract is front-loaded and the two modes are laid out in sequence, so the structure mirrors how an agent should read it. The sentences are long and heavily parenthesized, which costs some scannability, but no sentence is 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?

There is no output schema, and the description compensates by enumerating every returned field for both modes, including the conditional structure_hash/values_hash and row_count. Combined with expiry and permission semantics, nothing an agent needs in order to call this correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not carry: branch_id governs statements and single-value widgets while dashboards retain every branch, and the transactions target is explicitly described as unfiltered and without routing annotations. This is meaningful elaboration rather than repetition.

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?

Opens with a specific verb and resource ("Generates a file from a model") and immediately names the exact return shape. It then splits the tool into two well-defined modes, `target: 'model'` and `target: 'transactions'`, so an agent can tell precisely what each produces.

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?

The description makes the choice between the two modes concrete: model is the default Excel workbook, transactions is the full staged CSV import with no filters or routing. It gives clear context for when each mode applies, but it never contrasts this tool with plausible siblings such as layerz_create_upload_url, layerz_list_transactions, or layerz_share_model, leaving that routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Layerz toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources