Skip to main content
Glama
Sign In

Layerz

by cc.layerz.app
OverviewDiscussionsAdmin

List staged transactions

layerz_list_transactions
Read-onlyIdempotent

Returns a data source's staged transactions (API connector or csv/fec file import) annotated with their routing: the target item and whether a rule or an auto-created item matched, the skip reason otherwise (mapping is the only routing path, no fuzzy match), or ignored for a row an __ignore__ rule routes nowhere on purpose. period (YYYY-MM) and q (substring on description/category) filter the rows. The full staged import as a CSV file is layerz_export { target: 'transactions' }. A materialized legacy import derives one row per owned cell from the model's input rows.

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": {
      "connection_id": "<connection_id>"
    },
    "name": "layerz_list_transactions"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoKeeps rows whose description/category contains this text.
periodNoKeeps only this YYYY-MM period.
model_idNoTarget model UUID. Required for user-scoped API keys; validated against the bound model for model-scoped keys.
connection_idYesSource id as returned by layerz_list_integrations.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / format
      Removed value: -{
-  "description": "json (default): annotated rows inline. csv: a signed `download_url` of every staged row as a CSV file.",
-  "enum": [
-    "json",
-    "csv"
-  ],
-  "type": "string"
-}
  2. Changed5 schema fields changed
    • changedInput schema / properties / connection_id / description
      Previous value: -"Connection id from layerz_list_integrations."New value: +"Source id as returned by layerz_list_integrations."
    • changedInput schema / properties / format / description
      Previous value: -"Default json (annotated rows inline). `csv`: export every staged row of the source as a CSV file and return a signed `download_url` (same file as the web Sources panel download)."New value: +"json (default): annotated rows inline. csv: a signed `download_url` of every staged row as a CSV file."
    • 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 / period / description
      Previous value: -"Keep only this YYYY-MM period."New value: +"Keeps only this YYYY-MM period."
    • changedInput schema / properties / q / description
      Previous value: -"Keep rows whose description/category contains this text."New value: +"Keeps rows whose description/category contains this text."
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds substantive semantics — that mapping is the only routing path with no fuzzy match, the meaning of 'ignored' via __ignore__ rules, and that a materialized legacy import derives one row per owned cell from the model's input rows. What is missing is any note on result volume, pagination, or ordering for a potentially large transaction list.

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-loaded with the return shape, then filters, then the CSV sibling alternative — a sensible ordering with no filler sentences. The routing enumerations and the legacy-import clause are dense but each earns its place by clarifying what a row means.

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?

With no output schema, the description carries the burden of explaining return values and does so by describing the routing annotation fields per row and the skip/ignored states. Remaining gaps — pagination, result ordering, and whether routing detail is absent for unmapped sources — are modest for a filtered read tool.

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 both q and period are already documented in the schema (substring on description/category; YYYY-MM). The description restates both filters and adds no syntax, default, or interaction detail beyond that, so the baseline 3 applies — it does not add meaning the schema lacks.

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 ('Returns a data source's staged transactions') and enumerates the source types (API connector or csv/fec import). It goes further by describing what each row carries — routing target, rule vs auto match, skip reason, or ignored — which lets an agent distinguish this from siblings like layerz_list_mappings or layerz_export without opening a schema.

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?

Explicitly routes the agent to layerz_export { target: 'transactions' } when the full staged import as CSV is wanted, and implies this tool is for filtered row inspection via period/q. It does not state exclusions relative to layerz_list_mappings or when routing detail is unavailable, but the primary alternative is named with its condition.

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