Skip to main content
Glama
Sign In

Layerz

by cc.layerz.app
OverviewDiscussionsAdmin

Set FINANCE.md

layerz_set_finance_md
DestructiveIdempotent

Replaces the FINANCE.md attached to a model with the given Markdown (YAML front matter + body, ≤ 5,000 chars). source: 'imported' marks content synced from a project-root file, 'user' (default) content authored in place. The content parses as a YAML front-matter document; schema warnings are returned without blocking. A template is a read-only published copy and is out of this tool's reach; a model's FINANCE.md becomes a template's usage guide when the model is published from the web app. Persists one version labelled with summary. Not advertised to read-only keys.

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>",
      "content": "<content>"
    },
    "name": "layerz_set_finance_md"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceNoProvenance: 'imported' (synced from a project-root FINANCE.md) or 'user' (default).
contentYesFull FINANCE.md Markdown (YAML front matter + body), max 5,000 chars.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / content / description
      Previous value: -"Full FINANCE.md Markdown (YAML front-matter + body). Max 5,000 chars — keep conventions in prose."New value: +"Full FINANCE.md Markdown (YAML front matter + body), max 5,000 chars."
    • 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 / source / description
      Previous value: -"Provenance: 'imported' when syncing from a project-root FINANCE.md, 'user' when editing in place. Defaults to 'user'."New value: +"Provenance: 'imported' (synced from a project-root FINANCE.md) or 'user' (default)."
    • 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\"."
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, but the description adds real behavior beyond them: the content is parsed as YAML front matter and schema warnings are returned without blocking the write, each call persists a version labelled with `summary`, and read-only keys cannot see the tool. The only soft gap is that per-call version creation sits in mild tension with idempotentHint=true, which the description does not reconcile.

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 core action and content constraint are front-loaded in the first clause, and later sentences each carry a distinct fact (provenance, parse behavior, template boundary, versioning, key scope). The dense parentheticals and semicolon-joined clauses make it slightly harder to scan than a bulleted structure would.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the questions that matter for a destructive write with no output schema: what is replaced, content format and size, provenance, non-blocking validation warnings, versioning, and the template/auth boundaries. It does not describe the failure/error shape when YAML parsing fails outright or when model_id is missing for user-scoped keys (the schema only implies this).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description restates content format and the 5,000-character cap and explains that `source` defaults to 'user' / 'imported' marks project-root sync, but the schema already documents both the enum values and the version-label role of `summary`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Replaces the FINANCE.md attached to a model with the given Markdown" gives a specific verb (replace) and a uniquely named resource (FINANCE.md), so an agent can distinguish it from generic write tools like layerz_patch or layerz_set_custom_instructions. It does not explicitly name those siblings, so differentiation is inferable rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description supplies exclusions and context: templates are "out of this tool's reach" and the tool is "not advertised to read-only keys", plus the remark that a model's FINANCE.md becomes a template's usage guide on publish. However it never states when to use this versus layerz_patch, layerz_set_custom_instructions, or layerz_import_branch, so the agent must infer routing from the resource name alone.

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