Skip to main content
Glama
Sign In

Zeno

by ch.zeno-works
OverviewDiscussionsAdmin

list_autopost_decisions

Recent AI-accountant autonomy decisions (CompanyMember) — the activity feed.

Shows what the autonomy policy posted (posted), would have posted in assist shadow mode (shadow), or held for human review (held). ai_no_match shadow rows (one per AI-consulted bank entry with no verdict) are feed noise and hidden by default; include_no_match=true surfaces them for audit. outcome / source_ref_id narrow server-side (ZET-75), so the held-review surfaces can see held rows beyond the newest-limit window.

Newest first, ordered (created_at DESC, id DESC). limit caps at 200 and offset walks the rest (R2-21): one fiscal year of a mid-size client makes more decisions than one page holds, so page with offset += limit until a call returns fewer than limit rows. The response is a bare list.

cause keeps the held rows of one hold cause. An agent may accept only rows with agent_acceptable true.

Input Schema

NameRequiredDescriptionDefault
causeNo
limitNo
offsetNo
outcomeNo
company_idYes
source_ref_idNo
include_no_matchNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / cause / anyOf
      Previous value: -[
-  {
-    "description": "Why a decision is sitting in the held tier.",
-    "enum": [
-      "not_a_decision",
-      "expense_receipt",
-      "autonomy_off",
-      "post_failed",
-      "period_closed",
-      "amount_cap",
-      "credit_note",
-      "duplicate_suspicion",
-      "self_counterparty",
-      "card_statement",
-      "payroll_liability_review",
-      "vat_uncertainty",
-      "fx_untranslated",
-      "risk_flags",
-      "open_questions",
-      "proposal_rejected",
-      "missing_original",
-      "settlement_mismatch",
-      "recognition_schedule",
-      "pre_llm_guard",
-      "low_confidence",
-      "fy_predates_books",
-      "fy_gap",
-      "unknown_vat_code",
-      "currency_mismatch",
-      "bank_history",
-      "bank_suspense",
-      "awaiting_review",
-      "unclassified"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Why a decision is sitting in the held tier.",
+    "enum": [
+      "not_a_decision",
+      "expense_receipt",
+      "autonomy_off",
+      "post_failed",
+      "period_closed",
+      "amount_cap",
+      "credit_note",
+      "duplicate_suspicion",
+      "self_counterparty",
+      "card_statement",
+      "payroll_liability_review",
+      "vat_uncertainty",
+      "fx_untranslated",
+      "risk_flags",
+      "open_questions",
+      "proposal_rejected",
+      "missing_original",
+      "settlement_mismatch",
+      "recognition_schedule",
+      "pre_llm_guard",
+      "low_confidence",
+      "fy_predates_books",
+      "fy_gap",
+      "unknown_vat_code",
+      "currency_mismatch",
+      "bank_history",
+      "bank_suspense",
+      "awaiting_review",
+      "unclassified",
+      "reopened_after_reversal",
+      "booked_differently"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / outcome / anyOf
      Previous value: -[
-  {
-    "description": "Outcome recorded for one autonomy decision (``gl_autopost_decision``).\n\n``posted`` — ``auto`` mode, policy cleared, entry was posted (AI).\n``held`` — policy did not clear; nothing posted, falls back to human review.\n``shadow`` — ``assist`` mode, policy *would* have posted but did not (shadow).",
-    "enum": [
-      "posted",
-      "held",
-      "shadow"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Outcome recorded for one autonomy decision (``gl_autopost_decision``).\n\n``posted`` — ``auto`` mode, policy cleared, entry was posted (AI).\n``held`` — policy did not clear; nothing posted, falls back to human review.\n``shadow`` — ``assist`` mode, policy *would* have posted but did not (shadow).\n``dismissed`` — held, then closed unposted: the document was decided another way.",
+    "enum": [
+      "posted",
+      "held",
+      "shadow",
+      "dismissed"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
  3. Changed1 schema field changed
    • addedInput schema / properties / cause
      Added value: +{
+  "anyOf": [
+    {
+      "description": "Why a decision is sitting in the held tier.",
+      "enum": [
+        "not_a_decision",
+        "expense_receipt",
+        "autonomy_off",
+        "post_failed",
+        "period_closed",
+        "amount_cap",
+        "credit_note",
+        "duplicate_suspicion",
+        "self_counterparty",
+        "card_statement",
+        "payroll_liability_review",
+        "vat_uncertainty",
+        "fx_untranslated",
+        "risk_flags",
+        "open_questions",
+        "proposal_rejected",
+        "missing_original",
+        "settlement_mismatch",
+        "recognition_schedule",
+        "pre_llm_guard",
+        "low_confidence",
+        "fy_predates_books",
+        "fy_gap",
+        "unknown_vat_code",
+        "currency_mismatch",
+        "bank_history",
+        "bank_suspense",
+        "awaiting_review",
+        "unclassified"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
  4. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses the default suppression of ai_no_match noise rows, the newest-first ordering key (created_at DESC, id DESC), the 200-row cap, the pagination termination rule, and that the response is a bare list. It omits permission/auth requirements and any cost or rate characteristics, which keeps it out of the top band.

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?

Purpose and feed semantics are front-loaded, and each subsequent sentence adds operational value (filtering, pagination, hold causes). Some space is spent on internal ticket references (ZET-75, R2-21) and the '(CompanyMember)' parenthetical that mean little to an agent.

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?

No output schema and no annotations exist, so the description has to define the return shape — it does ('the response is a bare list', plus ordering and the row states). Combined with the pagination and filter guidance, an agent can call this correctly; only auth/permission preconditions and the row field list are left implicit.

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 0%, so the description must compensate, and it largely does: include_no_match, outcome, source_ref_id, cause, limit and offset all get meaning (including the server-side narrowing behavior of outcome/source_ref_id). company_id — the one required parameter — is never explained, and the row-level agent_acceptable flag is mentioned without tying it to a parameter.

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: 'Recent AI-accountant autonomy decisions (CompanyMember) — the activity feed.' It then enumerates the three states the feed surfaces (posted/shadow/held), which cleanly separates it from write-side siblings like accept_autopost_decision and from aggregate siblings like get_work_list or reconciliation_summary.

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?

It gives concrete usage rules: set include_no_match=true only for audit, use outcome/source_ref_id to reach held rows beyond the newest-limit window, use cause to isolate one hold cause, and page with offset += limit until a short page returns. It does not name a sibling alternative for the 'what should I review instead' case, so it stops short of full when/when-not routing.

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

All Zeno toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources