zeno
Registry code: 91e0686f810d7fed
This server is Zeno, an accounting platform — bookkeeping, VAT, payroll,
year-end, reconciliation, invoicing and reporting for Swiss fiduciary work.
- endpoint
- https://app.zeno-works.ch/mcp
- protocol
- http-sse ·2025-06-18
- authentication
- none observed
- public key
- none — nobody has proven they own this listing · is it yours? claim it
- karma
- 0 · newcomer
- Is zeno live?
- Yes — it answered the hub's last check (checked 1h ago). It answered 100% of checks over the last 30 days.
- Is zeno free to use?
- No — it asks for a key or a login before it will serve.
- What tools does zeno have?
- 51 tools: post_gl_journal_entry, reverse_gl_journal_entry, list_bank_accounts, list_bank_entries, call_operation, start_signup, collect_api_key, whoami, ….
- Is zeno safe to connect?
- The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
90 days 100%· all time 100%
last good check
of 51 tools
- unknown → live
Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.
through this hub
successful
what callers paid
Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.
post_gl_journal_entry auth-required never probed
Post a draft entry into the books — accountant. One-way. A posted entry can no longer be replaced or discarded (both refuse with 409); the only general correction is ``…/reverse``, which leaves both the original and the reversal visible. The one exception is ``PUT …/guessed-account``, which re-points a ``coding_guessed`` entry's expense account in place — and it works *only* on a posted entry. Check the draft before posting rather than after.
{ "type": "object", "required": [ "company_id", "entry_id" ], "properties": { "body": { "anyOf": [ { "type": "object", "properties": { "not_vat": { "type": "boolean", "default": false, "description": "Acknowledge that code-less lines on VAT accounts (1170/2200...) are not VAT: a reclass within one side, undoing a netting, a payment with a fee line, a payment or settlement on an account used for both directions, or opening balances in a hand-built opening entry (ZET-159). Recorded on the audit row. A VAT payment or settlement on one-direction VAT accounts (only cleared: debit output, credit input; against bank/cash, the settlement account or each other) needs no flag. Off by default: an untagged VAT movement must fail, not miss the MWST-Abrechnung." }, "allow_untagged_control": { "type": "boolean", "default": false, "description": "Post an AR/AP control line with no open item (recorded on the entry). Not for VAT-account lines: see not_vat." }, "confirm_bank_duplicate": { "type": "boolean", "default": false } }, "description": "Optional body for posting a manual entry.\n\n``allow_untagged_control``: an AR/AP control line with no open item (ZET-150).\n``not_vat``: code-less lines on VAT accounts that are not VAT (F2431). Both are\nrecorded; both off by default so the common mistake fails loudly." }, { "type": "null" } ] }, "entry_id": { "type": "string" }, "company_id": { "type": "string" } } }arguments 42 linesreverse_gl_journal_entry auth-required never probed
**Storno** a posted journal entry: post its mirror image (accountant role). Nothing is deleted; the original stays, linked both ways, and the **reversal** entry is returned. The only VAT-correct storno door — VAT postings, open items and what the document spawned are all unwound. ``body.posting_date`` dates the reversal and decides its period; omitted, it reuses the original's date and period. Refusals, in evaluation order — **409** when: the entry is itself a reversal (post a new correcting entry instead); the reversal date falls in a ``filed``/``paid`` VAT period (date it into an open one); an open item still carries a live settlement (unlink or reverse the payment first); or — only with ``posting_date`` — its period is closed, its fiscal year sealed, or no fiscal year covers it.
{ "type": "object", "required": [ "company_id", "entry_id" ], "properties": { "body": { "anyOf": [ { "type": "object", "properties": { "posting_date": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] } } }, { "type": "null" } ] }, "entry_id": { "type": "string" }, "company_id": { "type": "string" } } }arguments 38 lineslist_bank_accounts auth-required never probed
The company's bank accounts — the ``bank_account_id`` every statement import, bank-entry list and reconciliation call needs (CompanyMember read). Oldest first, no filter and no paging. Each row carries the ``iban``, ``currency``, ``label``/``bank_name`` and ``ledger_account_number`` — the chart code this account posts through; **without one a bank movement cannot be coded**, and it is set with ``PUT /bank-accounts/{account_id}``. ``auto_created`` marks an account inferred from an imported statement rather than declared by a human; it starts ``ownership_status`` unconfirmed with ``needs_ownership_review: true`` — confirm it before trusting its balances, since an unconfirmed IBAN may not be the company's at all. ``statement_count`` / ``entry_count`` are ``null`` here (filled by the single-account ``GET /bank-accounts/{account_id}``), which is not the same as zero.
{ "type": "object", "required": [ "company_id" ], "properties": { "company_id": { "type": "string" } } }arguments 11 lineslist_bank_entries auth-required never probed
List Bank Entries
{ "type": "object", "required": [], "properties": { "q": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "to": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "flag": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "from": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "limit": { "type": "integer", "default": 20, "maximum": 200, "minimum": 1 }, "offset": { "type": "integer", "default": 0, "minimum": 0 }, "company_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "credit_debit": { "anyOf": [ { "enum": [ "credit", "debit" ], "type": "string" }, { "type": "null" } ] }, "match_quality": { "anyOf": [ { "enum": [ "full", "strong", "partial", "weak", "manual", "imported" ], "type": "string", "description": "Graded bank-entry ↔ invoice match quality (match-quality feature, 2026-06-09).\n\nAuto bands (from how many matchable fields line up, see ``services.reconciliation``):\n``full`` > ``strong`` > ``partial`` > ``weak``. ``manual`` (user-created/confirmed)\nand ``imported`` (asserted by a source export) are provenance values that win over\nany auto band." }, { "type": "null" } ] }, "bank_account_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "counterparty_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "bank_statement_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "settlement_status": { "anyOf": [ { "enum": [ "unsettled", "settled", "partially_settled", "suspense" ], "type": "string", "description": "Clean-bank settlement state of a bank entry (distinct from ``reconciliation_status``,\nwhich the matcher owns). Set by ``settle_bank_entry``." }, { "type": "null" } ] }, "reconciliation_status": { "anyOf": [ { "enum": [ "unmatched", "partially_matched", "matched", "ignored" ], "type": "string" }, { "type": "null" } ] } } }arguments 165 linescall_operation auth-required never probed
Run any operation by name — the ones in your tool list and the unlisted ones alike. ``name`` is an operation name from ``find_operations``; ``arguments`` is the object described by ``describe_operations`` (omit it for an operation that takes none). The result, and any error, are exactly what calling the operation directly would give you.
{ "type": "object", "required": [ "name" ], "properties": { "name": { "type": "string" }, "arguments": { "anyOf": [ { "type": "object", "additionalProperties": true }, { "type": "null" } ], "default": null } }, "additionalProperties": false }arguments 24 linesstart_signup auth-required never probed
Create a Zeno account for somebody who does not have one yet. Use `request_api_key` first if they might already have an account — this tool cannot tell you, and deliberately never will. We email `email` a verification link. The user opens it, sees that you asked (by the name in `client_name`, shown as an unverified claim), chooses their own password, and decides separately whether to connect you. **You never see the link**, and you must not ask for it: it is what proves they own the mailbox, and a link you could repeat is a link anyone could. Then poll `collect_api_key` with the `claim_token` returned here. `denied` is terminal and means the person chose to create the account without connecting you, or refused outright — tell them plainly and stop; do not start another.
{ "type": "object", "required": [ "email" ], "properties": { "email": { "type": "string" }, "client_name": { "type": "string", "default": "" } }, "additionalProperties": false }arguments 16 linescollect_api_key auth-required never probed
Collect the key once the user has approved. `status` is one of: - `pending` — nobody has approved yet, or (with `throttled: true`) we were rate-limited and learned nothing. **Wait `poll_interval_seconds`, then call again** — every answer carries it. Do not ask the user to tell you when they are done: you cannot detect it any other way, and handing the wait back to the user is how these sessions die. - `ready` — `api_key` is the credential. **Follow the `note` that comes with it before anything else**: the key does nothing until the client's configuration holds it, and calling again issues nothing. `scope` says what it can reach (`onboarding`, `company` or `full`) and `company_id` which company, if any. **When `scope` is `onboarding` the user has no company yet and this key exists to make one: call `onboarding_guide` next** — it needs no key, so read it while the user installs this one. It is the only place that says which documents to ask them for, and asking for them all at once is the difference between one conversation and seven. - `collected` — this request already issued its key and nothing new was issued. Follow the `note`. - `denied` — **stop.** Do not start another request; a human refused it ("that was not me"). Raising a second one is how a refusal turns into a prompt the user has to refuse repeatedly. - `expired` — the request timed out. **Do not simply open another one**, and what to do depends on which door you opened, which only you know. `request_api_key`: ask whether they saw the approval page, and call it again if they want to retry. `start_signup`: they may have finished registering in the browser meanwhile, in which case they now HAVE an account and `request_api_key` is the path — ask. If they did not, tell them plainly that it timed out; starting another signup without asking is how a refusal turns into a prompt they have to refuse repeatedly. A `pending` answer is a success, not an error; it is deliberately not an error status, because an error would be read as "do not retry" and retrying is the entire protocol. A rate limit mid-wait is reported the same way, with `throttled: true` and a longer `poll_interval_seconds` — slow down, do not stop.
{ "type": "object", "required": [ "claim_token" ], "properties": { "claim_token": { "type": "string" } }, "additionalProperties": false }arguments 12 lineswhoami auth-required never probed
Which user this request acts as, and which company's books it is bound to (jwt or API key). Zeno serves every tenant from one host, and an API key is opaque — nothing else tells a connected agent whose books it is about to write. Call this FIRST when working over MCP: ``company_scoped: true`` means this connection's data access is confined to ``company_id`` — ``company_name`` names it (null here means the bound company no longer exists), no other tenant is reachable, and the admin endpoints are refused however privileged the owner is. ``is_admin`` is that owner's bit: worth nothing outside this company, still full authority inside it, so a scoped key with ``is_admin: true`` may write these books even when ``company_role`` is null. ``company_scoped: false`` means the credentials carry the owner's full principal and ``memberships`` lists the companies it can act in. Read-only and cheap — at most one lookup. ZET-171, ZET-176. ``credential_purpose`` says which kind of credential this is, and is what the withholding rule keys on (SP-08): anything that is neither ``full`` nor ``session`` is confined, and gets ``memberships`` **withheld — null, not empty**. Working over MCP, what you book or accept is recorded as MCP — not as this user acting in person — and the app displays it that way. ``capabilities`` says what this caller may do, each verdict computed from the predicate the gate itself evaluates (SP-12) — so an agent learns what it cannot do before it collides rather than after. A credential confined **to a company** gets the entries whose verdict is a fact about the *credential*; the one that would read the owner's estate (``create_company``) is omitted, because its verdict would disclose a sibling tenant. A credential confined to **no** company — an onboarding key — has no sibling to disclose and does get it, which is the one operation such a key exists to call. ``pending_admin_actions`` is present and empty until PRE-03/PRE-04 fill it.
{ "type": "object", "required": [], "properties": {} }arguments 5 lineslist_companies auth-required never probed
List companies (jwt, scoped). Non-admins see only their member companies.
{ "type": "object", "required": [], "properties": {} }arguments 5 linesget_intake auth-required never probed
Get one intake row by id (scoped to its company: 404/403 split).
{ "type": "object", "required": [ "intake_id" ], "properties": { "intake_id": { "type": "string" } } }arguments 11 linesgl_balance_sheet auth-required never probed
Assets vs liabilities + equity for one fiscal year, signed by natural side. Window rules as the trial balance (``fiscal_year`` defaults to the latest posted year; no all-years mode, ZET-155). With ``period_id`` this is a *movements* aggregate over that period, not a position. ⚠️ Balances as ``assets == liabilities_and_equity``, NOT ``liabilities + equity``: the GL has no P&L→equity closing entry, so ``equity`` is the equity accounts alone and ``net_result`` is folded into ``liabilities_and_equity``. It is a *position* only for a year whose book carries its opening batch; otherwise it is that year's movements and equity is empty. Cut by the stamped ``fiscal_year_id``, not posting date (``fiscal_year_cut``, ZET-166).
{ "type": "object", "required": [ "company_id" ], "properties": { "period_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "company_id": { "type": "string" }, "fiscal_year": { "anyOf": [ { "type": "integer" }, { "type": "null" } ] } } }arguments 31 linescreate_ar_invoice auth-required never probed
Create an outgoing (sales) invoice as a **draft** — nothing is booked yet (accountant role). A draft changes no ledger balance, gets no invoice number and appears in no VAT return; it exists so it can be edited. Posting happens later, at ``POST …/ar/invoices/{invoice_id}/issue``. Body: ``issue_date`` (required), ``counterparty_id`` (the customer — required before it can be issued), ``currency``/``language``, ``due_date`` (filled from the customer's payment terms when omitted), ``doc_type`` (``invoice``, the default — a ``credit_note`` draft can never be issued: credit an issued invoice with ``POST …/ar/invoices/{invoice_id}/credit-note`` instead), and ``lines``: each line carries ``quantity``, ``unit_price``, a revenue ``account_code`` and a ``vat_code_id`` (the id from ``GET …/gl/vat-codes``; a line without one declares no VAT). Totals, per-line net/VAT/gross and discounts are computed server-side — do not send them. Returns the created invoice with its lines and computed totals. Check ``GET …/ar/invoices/{invoice_id}/readiness`` for what still blocks issuing.
{ "type": "object", "required": [ "company_id", "issue_date" ], "properties": { "lines": { "type": "array", "items": { "type": "object", "properties": { "quantity": { "anyOf": [ { "type": "number" }, { "type": "string", "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$" }, { "type": "null" } ] }, "item_code": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "line_type": { "enum": [ "product", "service", "text", "section", "discount" ], "type": "string", "default": "product" }, "product_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "sort_order": { "anyOf": [ { "type": "integer" }, { "type": "null" } ] }, "unit_label": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "unit_price": { "anyOf": [ { "type": "number" }, { "type": "string", "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$" }, { "type": "null" } ] }, "description": { "anyOf": [ { "type": "string", "maxLength": 8000 }, { "type": "null" } ] }, "group_label": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "vat_code_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "account_code": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "line_discount_kind": { "enum": [ "none", "percent", "amount" ], "type": "string", "default": "none" }, "service_period_end": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "line_discount_value": { "anyOf": [ { "type": "number" }, { "type": "string", "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$" } ], "default": "0" }, "service_period_start": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] } } } }, "notes": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "currency": { "type": "string", "default": "CHF", "pattern": "^[A-Za-z]{3}$", "maxLength": 3, "minLength": 3 }, "doc_type": { "enum": [ "invoice", "credit_note" ], "type": "string", "default": "invoice" }, "due_date": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "language": { "anyOf": [ { "enum": [ "de", "en", "fr", "it" ], "type": "string" }, { "type": "null" } ] }, "company_id": { "type": "string" }, "issue_date": { "type": "string", "format": "date" }, "legal_text": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "footer_text": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "counterparty_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "payment_terms_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "issuer_profile_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "service_period_end": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "credited_invoice_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "service_period_start": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "invoice_discount_kind": { "enum": [ "none", "percent", "amount" ], "type": "string", "default": "none" }, "invoice_discount_value": { "anyOf": [ { "type": "number", "minimum": 0 }, { "type": "string", "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$" } ], "default": "0" } } }arguments 343 lineslist_payroll_runs auth-required never probed
The company's payroll runs — one per wage period — newest period first (CompanyMember read; the money is aggregate, no per-employee PII). A run walks ``draft`` → ``calculated`` → ``approved`` → ``posted`` → ``paid`` → ``locked`` (plus ``reversed``); ``run_kind`` separates a ``regular`` run from a correction/reversal, which are always **separate runs**, never in-place edits, and are linked by ``original_run_id`` / ``reversed_by_run_id``. ``journal_entry_id`` is the wage entry it posted (``null`` before ``posted``), and the lifecycle stamps (``calculated_at``, ``approved_at``, ``posted_at``, ``paid_at``, ``locked_at``) say when each step happened. Each row also carries ``employee_count``, ``gross_total``/``net_total`` and the validation ``error_count``/``warning_count`` — a run with errors must not be approved. ``staleness`` is computed at read time: non-null means master data changed after the run was calculated (a retroactive correction), so the frozen figures no longer match; it is advisory, and its ``action`` says what to do. Filters: ``status_filter`` narrows to one lifecycle state, ``year`` to runs whose period starts in that calendar year. No paging. Use ``GET …/payroll/runs/due`` for wage months that have **no** run yet.
{ "type": "object", "required": [ "company_id" ], "properties": { "year": { "anyOf": [ { "type": "integer" }, { "type": "null" } ] }, "company_id": { "type": "string" }, "status_filter": { "anyOf": [ { "enum": [ "draft", "calculated", "approved", "posted", "paid", "locked", "reversed" ], "type": "string", "description": "Run lifecycle (payroll SP0; enforced from SP6 via ``invoiage_core.payroll.states``)." }, { "type": "null" } ] } } }arguments 41 linesget_company auth-required never probed
Get one company (jwt, scoped). 403 for a non-member non-admin, 404 if absent.
{ "type": "object", "required": [ "company_id" ], "properties": { "company_id": { "type": "string" } } }arguments 11 linesget_work_list auth-required never probed
Everything waiting for this user in this company, most severe first.
{ "type": "object", "required": [ "company_id" ], "properties": { "company_id": { "type": "string" } } }arguments 11 linesget_gl_journal_entry auth-required never probed
One entry + lines, plus the subledger rows it produced/touched (Gap B detail surfacing): its ``gl_vat_posting`` rows, its ``gl_vat_zero_posting`` turnover-only declarations (zero-rated/exempt output — R2-13b: these have no VAT line to pair, so without them a correctly coded 0 % line is indistinguishable from an untagged one) and referenced ``gl_open_item`` rows. A declared base line also carries the resolved code on ``lines[].vat_code``. Drafts carry empty lists. ``documents`` carries the accounting documents explicitly attached to the entry (``POST …/documents``) — the evidence for a hand-booked entry; a pipeline-created entry carries its document through ``source_ref_*`` instead and lists nothing here. Member read, like the rest of the detail.
{ "type": "object", "required": [ "company_id", "entry_id" ], "properties": { "entry_id": { "type": "string" }, "company_id": { "type": "string" } } }arguments 15 linesaccept_autopost_decision auth-required never probed
One-click accept of a **held** decision (accountant) — posts the AI's proposal. The accepting actor's approval replaces every soft guardrail (confidence, amount cap, risk flags); hard blocks stay enforced by the posting path (closed period / sealed FY / unresolvable accounts → 409/422). The accepted entry posts as ``origin=ai`` with the accepting user in the audit trail (``accepted_by``/``accepted_at`` + JE ``posted_by``); the row flips ``held → posted`` in place, so a second accept is a 409 (idempotent). ``accepted_by_kind`` records what kind of actor approved: an accept made over MCP is recorded as ``mcp``, not as a person's click. The optional ``body`` serves three holds and is omitted for every other kind: ``expense:receipt:item:`` needs ``employee_id`` + ``category_id`` for the draft claim, ``autopost:capitalize:`` needs ``fixed_asset_category_id`` (+ optional ``useful_life_months``) when the hold resolved no category, and a ``needs_split_source`` mixed invoice needs ``reclassify_from_account_code`` — 422 without them.
{ "type": "object", "required": [ "company_id", "decision_id" ], "properties": { "body": { "anyOf": [ { "type": "object", "properties": { "category_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "employee_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "useful_life_months": { "anyOf": [ { "type": "integer", "minimum": 1 }, { "type": "null" } ] }, "fixed_asset_category_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "confirm_not_card_statement": { "type": "boolean", "default": false }, "reclassify_from_account_code": { "anyOf": [ { "type": "string" }, { "type": "null" } ] } }, "description": "Optional ``POST /autopost-decisions/{id}/accept`` body.\n\nTwo paths read it. The ``expense:receipt:item:`` claim path needs an employee\nand a category (both NOT NULL on the claim plane). The ``autopost:capitalize:``\npath needs a ``fixed_asset_category_id`` when the hold could not resolve one —\na missing category is a 422, never a guess, because the wrong category posts\nthe cost to the wrong balance-sheet account and depreciates it into the wrong\nexpense. The capitalize path may need a third fact:\n``reclassify_from_account_code`` when the hold is a mixed-invoice split whose\nsource line did not resolve (``needs_split_source``) — again a 422 without it,\nnever a guess. Omit the body entirely for every other decision kind (backward\ncompatible)." }, { "type": "null" } ] }, "company_id": { "type": "string" }, "decision_id": { "type": "string" } } }arguments 83 linesget_item auth-required never probed
Item metadata (any source).
{ "type": "object", "required": [ "item_id" ], "properties": { "item_id": { "type": "string" } } }arguments 11 linesfind_operations auth-required 1h ago
Search EVERY operation this server offers, including the ones not in your tool list. The tool list you can see holds only the common operations. Several hundred more — payroll, VAT returns, year-end close, fixed assets, expenses, cash book, settings, integrations, onboarding — are available but unlisted, and this is how you find them. **Search here before concluding that Zeno cannot do something.** Call with no arguments to browse the catalogue of areas (tags) with their operation counts; with ``tag`` to list one area; with ``query`` to search by keyword. **Every word contributes and matching all of them doubles the score**, so extra words widen the search rather than narrowing it — the AND-then-fall-back- to-OR behaviour this said before was removed in `ef47aa9ab`. A word matching an operation's *name* counts for far more than one found in its description, so prefer the noun you are looking for over a sentence. ``limit`` is capped at 100 per call; when more matched, ``next_offset`` gives the ``offset`` that returns the following page, so an area of any size can be read in full. Paging is stable — the ranking is deterministic and the registry is fixed at startup, so no operation is dropped or repeated between pages. Pass a promising ``name`` to ``describe_operations`` for its arguments, then run it with ``call_operation``.
{ "type": "object", "properties": { "tag": { "type": "string", "default": "" }, "limit": { "type": "integer", "default": 25 }, "query": { "type": "string", "default": "" }, "offset": { "type": "integer", "default": 0 } }, "additionalProperties": false }arguments 22 linesdescribe_operations auth-required 1h ago
Get the full argument schema for operations found via ``find_operations``. Returns each operation's description and JSON-Schema arguments — everything a listed tool would have shown you. ``include_output_schema`` is the ONLY way to obtain an operation's result shape: ``tools/list`` publishes no output schema for any operation, listed or not (they are 67 % of the payload, and a schema describing a *result* is not what you need to *choose* a tool). Ask for it when you must know the shape in advance; the result itself comes back as JSON either way, so usually you do not. Up to 10 operations per call; anything beyond that is reported in ``omitted`` rather than dropped.
{ "type": "object", "required": [ "names" ], "properties": { "names": { "type": "array", "items": { "type": "string" } }, "include_output_schema": { "type": "boolean", "default": false } }, "additionalProperties": false }arguments 19 linesget_ar_invoice auth-required 1h ago
One authored outgoing invoice with its lines (CompanyMember read). Carries the header (customer, dates, currency, discounts), every line with its computed ``net_amount``/``vat_amount``/``gross_amount``, the document totals, and the lifecycle: ``status`` (``draft`` → ``issued`` → ``cancelled``), ``document_no`` (assigned at issue — ``null`` on a draft), ``commercial_document_id`` / ``snapshot_document_id`` (the booked document and the frozen PDF), plus the derived ``payment_status`` and ``open_amount`` read from the linked open item. This is the **authored** arm only. A receivable that arrived as an ingested document is an ``item``, not an ``ar_invoice``; the two arms are listed together by ``GET …/ar/receivables``. Use ``GET …/ar/invoices/{invoice_id}/related`` for the journal entry, the settling bank transactions and the credit-note chain.
{ "type": "object", "required": [ "company_id", "invoice_id" ], "properties": { "company_id": { "type": "string" }, "invoice_id": { "type": "string" } } }arguments 15 linesrequest_api_key auth-required never probed
Ask the user to hand this session a Zeno API key. **Use this first** — every current Zeno user already has an account. `email` is the address on their Zeno account. **Ask them for it**; you cannot guess it, and the request is aimed by it — Zeno will only show it to somebody signed in as the owner of that address. Pass `client_name` too: it is the only thing identifying you on the approval page, and without it the person is asked to trust "an unnamed client". Returns a plain `verification_uri`. Tell the user to open it, sign in, and approve the request waiting there; we also email them a notice. **There is no code**, in either direction: nothing to read out, nothing to type, and nothing for you to put in a link. Then call `collect_api_key` with the `claim_token` returned here, waiting `poll_interval_seconds` between calls, until its `status` stops being `pending`. The user chooses on the page what the key may reach — usually a single company — so expect the key to be scoped, and read a 403 elsewhere as that scope rather than as a failure. The answer is the same whether or not that address has a Zeno account. If nothing ever arrives, the likeliest cause is a mistyped address — ask, do not assume.
{ "type": "object", "required": [ "email" ], "properties": { "email": { "type": "string" }, "client_name": { "type": "string", "default": "" } }, "additionalProperties": false }arguments 16 linesglobal_search auth-required never probed
Full-text search across emails + items, ranked by ``ts_rank_cd``, scoped (A1). ``archive_status`` constrains item results only (the Documents → Archive page passes ``archived`` so its search box never surfaces pending/triage-parked items).
{ "type": "object", "required": [ "q" ], "properties": { "q": { "type": "string", "minLength": 1 }, "type": { "anyOf": [ { "type": "string", "pattern": "^(email|item)$" }, { "type": "null" } ] }, "limit": { "type": "integer", "default": 20, "maximum": 200, "minimum": 1 }, "offset": { "type": "integer", "default": 0, "minimum": 0 }, "source": { "anyOf": [ { "type": "string", "pattern": "^(email|epost|upload|bexio|abacus)$" }, { "type": "null" } ] }, "direction": { "anyOf": [ { "type": "string", "pattern": "^(payable|receivable)$" }, { "type": "null" } ] }, "company_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "archive_status": { "anyOf": [ { "enum": [ "pending", "archiving", "archived", "failed" ], "type": "string" }, { "type": "null" } ] } } }arguments 82 linesget_kpi_report auth-required never probed
Snapshot KPIs + 13-week liquidity forecast, from the GL (CompanyMember). Cash/liability balances aggregate the FY window of posted/reversed journal lines; aging + forecast read ``gl_open_item``, pending salary batches and unpaid VAT periods. Read-only. Explicit non-member ``company_id`` → 403. ``fiscal_year`` optional → latest FY with journal data; FY figures as of that year's end once past. Aging and forecast anchor to today.
{ "type": "object", "required": [ "company_id" ], "properties": { "company_id": { "type": "string" }, "fiscal_year": { "anyOf": [ { "type": "integer", "maximum": 2200, "minimum": 1900 }, { "type": "null" } ] } } }arguments 23 lineslist_autopost_decisions auth-required never probed
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.
{ "type": "object", "required": [ "company_id" ], "properties": { "limit": { "type": "integer", "default": 50, "maximum": 200, "minimum": 1 }, "offset": { "type": "integer", "default": 0, "minimum": 0 }, "outcome": { "anyOf": [ { "enum": [ "posted", "held", "shadow" ], "type": "string", "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)." }, { "type": "null" } ] }, "company_id": { "type": "string" }, "source_ref_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "include_no_match": { "type": "boolean", "default": false } } }arguments 52 linesupload_intake auth-required never probed
Upload ANY file and let the system decide what it is (the unified intake queue — the same door as "Documents → Upload" in the web app). ``file_base64`` is the file's raw bytes, base64-encoded. Prefer this whenever the file is not plainly an invoice, and always for: bank statements (CAMT.053 XML, CSV, PDF or Excel exports) — these become BankStatement + BankEntry rows, matched to the registered bank account by IBAN; journal/accounting exports; and balance sheets, P&L statements and VAT filings. Mixed .zip archives are expanded and routed per file. Returns 202 with the queue row: routing happens asynchronously, so poll ``get_intake`` for the outcome and its targets. An unroutable file becomes a failed queue row carrying the reason — it is never silently dropped.
{ "type": "object", "required": [ "company_id", "filename", "file_base64" ], "properties": { "filename": { "type": "string" }, "company_id": { "type": "string" }, "file_base64": { "type": "string" } }, "additionalProperties": false }arguments 20 linesupload_document auth-required never probed
Upload an INVOICE or RECEIPT (PDF, image, or .zip of them) for analysis. ``file_base64`` is the file's raw bytes, base64-encoded. ``direction`` is ``payable`` (incoming supplier invoice) or ``receivable`` (outgoing). Creates Item(s) and queues extraction. This door is invoices-only: it never routes a file onward by type, so a bank statement, a journal export or a balance sheet sent here is analysed and then just sits as a document. For anything that is not an invoice — or when you are not sure what the file is — use ``upload_intake``.
{ "type": "object", "required": [ "company_id", "filename", "file_base64" ], "properties": { "filename": { "type": "string" }, "direction": { "type": "string", "default": "payable" }, "company_id": { "type": "string" }, "file_base64": { "type": "string" } }, "additionalProperties": false }arguments 24 lineslist_items auth-required never probed
List/filter items, scoped to the caller's member companies (A1). Optional ``period`` (``YYYY-MM``) filters by the item's effective date (invoice date, falling back to the Europe/Zurich-local ingestion date); a malformed value returns 422 ``{"msg": "period must be YYYY-MM"}``. ``exclude_triage_status`` drops items carrying that triage verdict (NULL-safe) — the Payables/Receivables pages pass ``unrelated`` so relevance-parked items show only in the Inbox (pipeline §"Relevance gate"). Optional ``q`` is free text: a case-insensitive **partial (substring)** match over the filename and the counterparty name from *both* of its sources (the linked counterparty and the extracted ``data.company``). ``%``/``_`` are matched literally, blank is ignored, and ``total`` counts the filtered set. ``duplicate`` filters on the row's ``is_duplicate`` flag (ZET-413); ``credit_note`` on its ``is_credit_note`` flag (ZET-429) — both server-side, so ``total`` stays exact.
{ "type": "object", "required": [], "properties": { "q": { "anyOf": [ { "type": "string", "maxLength": 200 }, { "type": "null" } ] }, "paid": { "anyOf": [ { "type": "boolean" }, { "type": "null" } ] }, "limit": { "type": "integer", "default": 20, "maximum": 200, "minimum": 1 }, "offset": { "type": "integer", "default": 0, "minimum": 0 }, "period": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "posted": { "anyOf": [ { "type": "boolean" }, { "type": "null" } ] }, "source": { "anyOf": [ { "enum": [ "email", "epost", "upload", "bexio", "abacus", "filesystem", "clouddrive" ], "type": "string" }, { "type": "null" } ] }, "direction": { "anyOf": [ { "enum": [ "payable", "receivable", "unknown" ], "type": "string", "description": "Query-filter vocabulary for ``Item.direction`` — NEVER a column type.\n\n``Item.direction`` is tri-state (``payable``/``receivable``/NULL = unknown);\nthe PG ``direction`` enum stays binary. This enum exists so list endpoints\ncan accept ``direction=unknown`` (→ ``direction IS NULL``) alongside the two\nreal values without widening the DB enum." }, { "type": "null" } ] }, "duplicate": { "anyOf": [ { "type": "boolean" }, { "type": "null" } ] }, "company_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "credit_note": { "anyOf": [ { "type": "boolean" }, { "type": "null" } ] }, "triage_status": { "anyOf": [ { "enum": [ "irrelevant", "needs_review", "unrelated" ], "type": "string", "description": "AI ingest-gate verdict parking an item in the Inbox (pipeline §\"Ingest triage\",\n§\"Relevance gate\").\n\nNULL = not triaged / normal flow. ``irrelevant``/``needs_review`` are the\nmetadata-triage verdicts on a held-unusable item (a human override flips\nbetween them; re-analysis resets the columns to NULL). ``unrelated`` is the\nrelevance-gate verdict on a *cleanly extracted* invoice that doculyse's\nentity resolver matched to neither party of the owning company — the item is\nheld ``pending`` (never archived, no counterparty, never coded) until a human\nrestores it (clears the verdict) or deletes it." }, { "type": "null" } ] }, "archive_status": { "anyOf": [ { "enum": [ "pending", "archiving", "archived", "failed" ], "type": "string" }, { "type": "null" } ] }, "counterparty_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "exclude_triage_status": { "anyOf": [ { "enum": [ "irrelevant", "needs_review", "unrelated" ], "type": "string", "description": "AI ingest-gate verdict parking an item in the Inbox (pipeline §\"Ingest triage\",\n§\"Relevance gate\").\n\nNULL = not triaged / normal flow. ``irrelevant``/``needs_review`` are the\nmetadata-triage verdicts on a held-unusable item (a human override flips\nbetween them; re-analysis resets the columns to NULL). ``unrelated`` is the\nrelevance-gate verdict on a *cleanly extracted* invoice that doculyse's\nentity resolver matched to neither party of the owning company — the item is\nheld ``pending`` (never archived, no counterparty, never coded) until a human\nrestores it (clears the verdict) or deletes it." }, { "type": "null" } ] } } }arguments 181 linesgl_trial_balance auth-required never probed
Per-account debit/credit columns for one fiscal year, with totals. ``fiscal_year`` (year label) defaults to the latest year posted in; ``period_id`` narrows to one period of it. No all-years mode — account identity is ``(company, fiscal year, code)``, so aggregating double-counts silently (ZET-155). Unknown year/period → 404; period outside the year → 422. Cut by the line's stamped ``fiscal_year_id``, not its posting date; ``…/financial-statements`` cuts by posting date inside the same year's stored window, so the two differ only on a line dated outside the year it is stamped to. ``fiscal_year_cut`` names the cut (ZET-166).
{ "type": "object", "required": [ "company_id" ], "properties": { "period_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "company_id": { "type": "string" }, "fiscal_year": { "anyOf": [ { "type": "integer" }, { "type": "null" } ] } } }arguments 31 linesgl_profit_and_loss auth-required never probed
Revenue − expense → net result, for one fiscal year. **Window** — same rules as the trial balance: ``fiscal_year`` defaults to the latest posted year, ``period_id`` narrows to one period of it, unknown values are 404 and a contradictory pair 422. A P&L is a **flow** statement, so no reading makes the sum of every fiscal year a company's result — hence no all-years mode (ZET-155). Opening batches post only to balance-sheet accounts, so they never enter this figure. **The cut** — by the line's stamped ``fiscal_year_id`` FK, not by posting date; the response's ``fiscal_year_cut`` says so (see the trial balance; ``null`` only for a company that has posted nothing, ZET-166). For the full statement — per-account sections, the year's own account names, the problems list and the cash flow — use ``GET /companies/{id}/financial-statements``, which cuts by a posting-date window instead, so the two can disagree for a short/long or shifted fiscal year; this route returns the three totals.
{ "type": "object", "required": [ "company_id" ], "properties": { "period_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "company_id": { "type": "string" }, "fiscal_year": { "anyOf": [ { "type": "integer" }, { "type": "null" } ] } } }arguments 31 lineslist_gl_accounts auth-required never probed
List the postable chart (CompanyMember). ``fiscal_year`` filters to one year's chart (the chart is FY-scoped, so codes repeat across years).
{ "type": "object", "required": [ "company_id" ], "properties": { "limit": { "type": "integer", "default": 50, "maximum": 200, "minimum": 1 }, "offset": { "type": "integer", "default": 0, "minimum": 0 }, "company_id": { "type": "string" }, "fiscal_year": { "anyOf": [ { "type": "integer" }, { "type": "null" } ] } } }arguments 32 linesget_gl_account_ledger auth-required never probed
One account's ledger (Kontoauszug) — every booking that touched it, in date order, with Soll/Haben and the running balance after each line (CompanyMember). No fiscal-year parameter: the chart is FY-owned, so ``account_id`` already fixes the year. Posted **and** reversed entries are included (a reversal is a second posted entry, so both legs must show or the balance is wrong); drafts are not. The running balance is carried across pages by the server — ``page_opening_balance`` enters this page's first row, while ``closing_balance``/``total_debit``/``total_credit`` describe the whole window. 404 when the account is not this company's; 422 when ``date_from`` is later than ``date_to``.
{ "type": "object", "required": [ "company_id", "account_id" ], "properties": { "limit": { "type": "integer", "default": 100, "maximum": 200, "minimum": 1 }, "offset": { "type": "integer", "default": 0, "minimum": 0 }, "date_to": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "date_from": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "account_id": { "type": "string" }, "company_id": { "type": "string" } } }arguments 48 lineslist_gl_periods auth-required never probed
The company's **accounting periods** — the months a journal entry may post into (CompanyMember read). A period belongs to one fiscal year and carries ``period_no`` (1..12 within the year), ``date_from``/``date_to`` and a ``status``: ``open`` accepts postings, ``soft_closed`` still accepts them, and ``closed``/``year_closed`` refuse them — a posting date inside a closed period fails until an accountant explicitly reopens the period (``POST …/gl/periods/{period_id}/reopen``, reason required, recorded in the close-run ledger — ZET-161). ``fiscal_year_id`` narrows to one year; omitted, every year's periods come back. This is **not** the VAT filing calendar — those are the ``gl_vat_period`` rows of ``GET …/gl/vat/periods``, which have their own quarterly/monthly cadence and their own ``filed``/``paid`` sealing. Use this list to find the ``period_id`` a manual journal entry needs, and to check *why* a posting date was refused.
{ "type": "object", "required": [ "company_id" ], "properties": { "company_id": { "type": "string" }, "fiscal_year_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] } } }arguments 21 lineslist_gl_open_items auth-required never probed
One page of the AR/AP subledger (member read). ``direction`` filters server-side (ZCT-577) — omit it for both. The screen used to filter the fetched page in the browser, which made the AR chip drop rows and the total count both directions. ``as_of`` (ZCT-577) reconstructs each item's open amount from posted journal lines dated on or before that date, instead of reading today's cached amount. Items are considered **regardless of their current status** — one settled since that date was open on it — so ``status`` is refused alongside it rather than silently ignored: a filter that appears to apply and does not is worse than an error. ``original_amount`` and ``status`` on each row remain the item's own, which are current facts, not as-of ones; the screen says so.
{ "type": "object", "required": [ "company_id" ], "properties": { "as_of": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "limit": { "type": "integer", "default": 50, "maximum": 200, "minimum": 1 }, "offset": { "type": "integer", "default": 0, "minimum": 0 }, "status": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "direction": { "anyOf": [ { "type": "string", "pattern": "^(receivable|payable)$" }, { "type": "null" } ] }, "company_id": { "type": "string" } } }arguments 54 lineslist_gl_journal_entries auth-required never probed
List journal entries. ``period_ids`` narrows to specific fiscal periods, and is how a caller asks for **one fiscal year** — the year's period ids (ZET-285). Without it this route listed, and counted, every fiscal year the company has: the Journal page cut the year out of the fetched page *client-side* while ``total`` stayed company-wide, so a year whose entries sat past the first page rendered as "no entries match" with no way to reach them. The service applies the filter before the count, so ``total`` is the filtered total and the pager is the year's. ``untagged_subledger_control=true`` narrows to the entries that posted to an AR/AP control account **without** touching the subledger, under ``allow_untagged_control`` (ZET-150) — the postings a subledger-vs-control divergence traces back to.
{ "type": "object", "required": [ "company_id" ], "properties": { "q": { "anyOf": [ { "type": "string", "maxLength": 200 }, { "type": "null" } ] }, "sort": { "enum": [ "entry_no", "posting_date", "total" ], "type": "string", "default": "posting_date" }, "limit": { "type": "integer", "default": 50, "maximum": 200, "minimum": 1 }, "order": { "enum": [ "asc", "desc" ], "type": "string", "default": "desc" }, "offset": { "type": "integer", "default": 0, "minimum": 0 }, "status": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "company_id": { "type": "string" }, "period_ids": { "anyOf": [ { "type": "array", "items": { "type": "string" }, "maxItems": 200 }, { "type": "null" } ] }, "untagged_subledger_control": { "anyOf": [ { "type": "boolean" }, { "type": "null" } ] } } }arguments 84 linescreate_gl_journal_entry auth-required never probed
Create a **draft** journal entry by hand — accountant. It carries NO source document unless you name one. Only the pipeline paths stamp ``source_ref_type``/``source_ref_id`` (an ingested document is ``'item'``), so by default a booking made here cannot be traced back to what justified it. ``document_id`` is the retrofit: name an existing ``gl_document`` (create one with ``POST …/gl/documents``) and it is attached as the entry's source document, so the entry is not evidence-less. The same attach is available afterwards at ``POST …/gl/journal-entries/{id}/documents`` — including on a posted entry. Use it for bookings with genuinely no document behind them — reclassifications, provisions, accruals, year-end adjustments. **Do not transcribe a document into it and then attach the file** — that files the evidence beside a booking nobody derived from it. Each of these has a door that keeps the evidence attached: - an invoice, receipt or statement → ingest the file (``POST …/uploads/`` or ``…/intake``), then accept what the coder proposes (``…/autopost-decisions``); - an already-ingested item → ``POST …/gl/items/{item_id}/coding``; - a bank movement with no document → ``POST /bank-entries/{entry_id}/manual-coding``; - opening balances → ``POST …/opening-entries`` and post the proposal. ``auto_reverse_date`` arms the entry as a one-shot accrual (ZCT-527): once posted, the auto-reversal executor reverses it in full on/after that date. It must be after ``posting_date`` (422 otherwise), and it can only be set while the entry is a draft — on the create here or on the ``PUT`` replace. Drafts do not touch the books until ``…/post``. See ``doc/pipeline.md §"Accounting"``.
{ "type": "object", "required": [ "company_id", "period_id", "posting_date", "lines" ], "properties": { "lines": { "type": "array", "items": { "type": "object", "required": [ "account_id", "line_role" ], "properties": { "vat": { "anyOf": [ { "type": "object", "required": [ "code" ], "properties": { "code": { "type": "string" }, "amount": { "anyOf": [ { "type": "number" }, { "type": "string", "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$" }, { "type": "null" } ] } }, "description": "VAT tag for a manual journal line (Gap B — manual-booking metadata completeness).\n\nTag **both** legs of a taxable movement with the same ``code`` (a company\n``gl_vat_code``): the taxable **base** line *and* its paired **VAT-control** line —\nposting groups the entry's lines by this tag to pair base with VAT line, and the\ncomposition guard refuses (409) any VAT-control line left untagged (ZET-158: a\nbase-line-only tag has no working path). One tagged control line per code.\n``amount`` (the tax, a magnitude) is read from the **base** line's tag and falls\nback to the paired VAT line's amount — when several base lines share one VAT line,\ngive each base line its own ``amount``, or every pair books the full VAT-line\namount. Exception: a catalog-linked **zero-rated output** code (0 % rate) books no\nVAT-control line at all — tag only the base line(s); each line tagged with such a\ncode declares its turnover once. On post the entry gains ``gl_vat_posting`` rows so\nthe lines reach the MWST-Abrechnung (``doc/pipeline.md §\"VAT\"``)." }, { "type": "null" } ] }, "currency": { "anyOf": [ { "type": "string", "maxLength": 3 }, { "type": "null" } ] }, "line_role": { "enum": [ "bank", "ar", "ap", "revenue", "expense", "vat", "payroll_liability", "salary_expense", "fixed_asset", "depreciation", "inventory", "cogs", "clearing", "rounding", "fx_gain_loss", "suspense" ], "type": "string" }, "open_item": { "anyOf": [ { "type": "object", "properties": { "create": { "type": "boolean", "default": false }, "due_date": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] } }, "description": "Open a new AR/AP subledger item from a manual control line (Gap B).\n\nSet ``create=true`` on the line posting to the AR/AP control account; ``due_date`` seeds\naging. Direction is derived from the account's ``control_type``. To settle/adjust an\n*existing* item instead, pass ``open_item_id`` on the line (its balance is rebuilt on post)." }, { "type": "null" } ] }, "account_id": { "type": "string" }, "amount_base": { "anyOf": [ { "type": "number" }, { "type": "string", "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$" }, { "type": "null" } ] }, "description": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "open_item_id": { "anyOf": [ { "type": "string", "maxLength": 21 }, { "type": "null" } ] }, "amount_currency": { "anyOf": [ { "type": "number" }, { "type": "string", "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$" }, { "type": "null" } ] }, "counterparty_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] } } }, "minItems": 1 }, "currency": { "anyOf": [ { "type": "string", "maxLength": 3 }, { "type": "null" } ] }, "period_id": { "type": "string" }, "company_id": { "type": "string" }, "entry_type": { "enum": [ "manual", "invoice", "payment", "bank", "vat", "payroll", "accrual", "deferral", "depreciation", "inventory", "closing", "adjustment", "reversal" ], "type": "string", "default": "manual" }, "description": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "document_id": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "posting_date": { "type": "string", "format": "date" }, "auto_reverse_date": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] } } }arguments 250 linesget_bank_entry auth-required never probed
Get Bank Entry
{ "type": "object", "required": [ "entry_id" ], "properties": { "entry_id": { "type": "string" } } }arguments 11 linesentry_candidates auth-required never probed
Entry Candidates
{ "type": "object", "required": [ "entry_id" ], "properties": { "entry_id": { "type": "string" } } }arguments 11 linessettle_entry auth-required never probed
Post this reconciled bank entry into the GL (clean-bank settlement). Matched → Dr Bank / Cr AR; unmatched → Dr Bank / Cr Suspense; a previously-suspensed entry now fully matched → Dr Suspense / Cr AR. Idempotent, and a no-op (``skipped``) when the GL chart is not configured for native settlement. The matcher still owns ``reconciliation_status``. See doc/architecture.md §"Posting general ledger".
{ "type": "object", "required": [ "entry_id" ], "properties": { "entry_id": { "type": "string" } } }arguments 11 linesreconciliation_summary auth-required never probed
Reconciliation summary banner. Optional ``from``/``to`` scope the **per-entry bank-entry counts** (total / matched / missing-invoice / …) to a ``booking_date`` window — mirroring the ``/bank-entries`` grid filter — so the banner agrees with a month-filtered table. The cross-month coverage (``bank_accounts`` gaps / ``missing_periods``) stays **global**: gap detection spans statements regardless of the selected month.
{ "type": "object", "required": [ "company_id" ], "properties": { "to": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "from": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "company_id": { "type": "string" } } }arguments 33 lineslist_ar_invoices auth-required never probed
List authored AR invoices, newest first. Optional ``status`` / ``doc_type`` filter by lifecycle + document kind. Optional ``period`` (``YYYY-MM``) filters by the invoice's issue date (its month); a malformed value returns 422 ``{"msg": "period must be YYYY-MM"}``.
{ "type": "object", "required": [ "company_id" ], "properties": { "limit": { "type": "integer", "default": 50, "maximum": 200, "minimum": 1 }, "offset": { "type": "integer", "default": 0, "minimum": 0 }, "period": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "status": { "anyOf": [ { "enum": [ "draft", "issued", "cancelled" ], "type": "string", "description": "Editorial lifecycle owned by ``ar_invoice`` (paid/overdue are derived on\nread from the linked ``gl_open_item``, not stored here)." }, { "type": "null" } ] }, "doc_type": { "anyOf": [ { "enum": [ "invoice", "credit_note" ], "type": "string" }, { "type": "null" } ] }, "company_id": { "type": "string" } } }arguments 62 linesissue_ar_invoice auth-required never probed
Issue a draft — **this is the booking step** (accountant role). In one transaction it assigns the next invoice number, posts the journal entry (debit the AR control account, credit revenue per line, credit output VAT per VAT code), opens the receivable open item the customer's payment will settle, freezes the invoice against further edits (``status`` → ``issued``) and renders the PDF+QR snapshot. The turnover reaches the VAT return from here — a draft never does. Only a **draft** can be issued: re-issuing an issued invoice is a 409. It is also refused when the invoice is not ready (no customer, no lines, a line without a revenue account…) — call ``GET …/ar/invoices/{invoice_id}/readiness`` first, whose ``blocking`` list is exactly what this refuses on — when the ``issue_date`` is not inside an **open** accounting period, or when the fiscal year has no AR control account configured. Returns the issued invoice (now with ``document_no`` and ``commercial_document_id``). A renderer outage does not fail the issue: the booking stands and the snapshot stays pending, re-rendered on demand by ``GET …/ar/invoices/{invoice_id}/pdf``. To undo one, reverse its journal entry; there is no un-issue.
{ "type": "object", "required": [ "company_id", "invoice_id" ], "properties": { "company_id": { "type": "string" }, "invoice_id": { "type": "string" } } }arguments 15 lineslist_counterparties auth-required never probed
List a company's counterparties (filter by ``kind``/``q``, paginated). ``kind`` repeats to filter on a set (``?kind=customer&kind=both``) — a role-shaped picker asks for every kind that plays the role. A single ``?kind=supplier`` keeps its original meaning.
{ "type": "object", "required": [ "company_id" ], "properties": { "q": { "anyOf": [ { "type": "string" }, { "type": "null" } ] }, "kind": { "anyOf": [ { "type": "array", "items": { "enum": [ "supplier", "customer", "both", "employee" ], "type": "string", "description": "Master-data axis of a counterparty (what the party primarily is).\n\n``employee`` (payroll SP1, brief frozen decision 6) is set **only** on\ncounterparties auto-created by ``payroll.master_data\n.ensure_employee_counterparty`` and is terminal — matching/merge flows never\nwiden it to ``both``. Subledger participation rides the richer\n``gl_counterparty_role`` table; payroll logic never branches on ``kind``." } }, { "type": "null" } ] }, "limit": { "type": "integer", "default": 20, "maximum": 200, "minimum": 1 }, "offset": { "type": "integer", "default": 0, "minimum": 0 }, "company_id": { "type": "string" } } }arguments 52 lineslist_gl_vat_periods auth-required never probed
List Gl Vat Periods
{ "type": "object", "required": [ "company_id" ], "properties": { "company_id": { "type": "string" } } }arguments 11 lineslist_payroll_employees auth-required never probed
Every employee on the payroll master data, with today's contract (accountant role — this payload is personal data, so it is not a plain member read). One row per employee, active and left alike (filter on ``status`` / ``employment_end`` yourself — no server-side filter, no paging): master data (``employee_no``, ``display_name``, address, ``ahv_number``, ``birthdate``), the Quellensteuer election (``qst_liable`` + canton/tariff), the salary ``iban``, and ``current_contract`` — the contract valid **today**, which is where the wage and workload live (``null`` when none is in force). ``readiness`` lists what is still missing before this employee can be included in a payroll run — read it before creating one; empty means ready. Note ``ahv_pensioner_allowance_waived`` is genuinely three-state: ``null`` means no election is on record, which blocks the AHV/FAK declaration, and is NOT "not waived". Use ``GET …/employees/{employee_id}`` for children and the full contract history.
{ "type": "object", "required": [ "company_id" ], "properties": { "company_id": { "type": "string" } } }arguments 11 linesget_financial_statements auth-required never probed
Computed balance sheet + P&L for a fiscal year, from the journal (CompanyMember). Aggregates every posted GL journal line whose **posting date** falls in the fiscal year's window, classifies each account against the chart of accounts, and reports problems (unbalanced trial balance, unclassified accounts, year-not-opened, mixed currency). **Read-only and distinct** from the uploaded balance-sheet snapshots (``GET .../balance-sheets``): nothing here reads a snapshot. ``fiscal_year`` optional → the latest FY with journal data. ``month`` (``YYYY-MM``, inside the FY — **422** otherwise) narrows the statement to one month: the balance sheet stays cumulative (as of month end, YTD equity fold) while the P&L + cash flow cover that month's flows. Explicit non-member ``company_id`` → 403. **The cut** — a line is included because its ``posting_date`` falls inside the fiscal year's own window, read off the ``gl_fiscal_year`` row; the response's ``fiscal_year_cut`` says so (``method="posting_date_window"``, dates = that window; the aggregated window is ``period_start``..``period_end``, narrower when month-scoped, ZET-166). The ``/gl/reports/*`` family cuts by the line's stamped ``fiscal_year_id`` FK instead. Both read the same window, so they agree on where the year starts and ends; they can still differ on a line dated outside the year it is stamped to.
{ "type": "object", "required": [ "company_id" ], "properties": { "month": { "anyOf": [ { "type": "string", "pattern": "^\\d{4}-(0[1-9]|1[0-2])$" }, { "type": "null" } ] }, "company_id": { "type": "string" }, "fiscal_year": { "anyOf": [ { "type": "integer" }, { "type": "null" } ] } } }arguments 32 linescustomer_statement auth-required never probed
One customer's open items + totals (the aging row's drill-down). ``as_of`` mirrors ``GET …/ar/aging`` — set, it reconstructs the items open at that date so the statement agrees with a historical aging report.
{ "type": "object", "required": [ "company_id", "counterparty_id" ], "properties": { "as_of": { "anyOf": [ { "type": "string", "format": "date" }, { "type": "null" } ] }, "company_id": { "type": "string" }, "counterparty_id": { "type": "string" } } }arguments 26 linesget_bank_status auth-required never probed
Composed bank snapshot — "is my banking up to date?" (CompanyMember). "Reconciled" means entries matched, NOT ledger = statement balance (the close check ``BANK_BALANCE_DOES_NOT_TIE_OUT`` compares that). One call for what otherwise takes ``GET …/bank-accounts`` + one ``GET /bank-accounts/{id}/coverage`` per account + ``GET …/reconciliation/summary`` — and which those three still do not answer: per-account entry-status counts, the ``in_suspense`` counts, each account's latest closing balance, and the **company-level cumulative GL Suspense balance** (elsewhere reachable only through a VAT period's close-checks). Non-zero suspense blocks a clean VAT close. Read-only. Gaps come from the account's **full** history: coverage windows are merged and every internal hole reported (ZCT-509), so a run of missing statements is ONE gap. Not period-scoped; use ``…/reconciliation/completeness`` per month. ``period_gaps`` caps at 10/account, ``period_gap_count`` stays exact — HOLES, not missing months. Explicit non-member ``company_id`` → 403.
{ "type": "object", "required": [ "company_id" ], "properties": { "company_id": { "type": "string" } } }arguments 11 lineszeno_info auth-required never probed
What this server is, which MCP revision it speaks, and how to get a credential. **Needs no credential.** Call it first if a tool has just refused you: the `authentication` block names the tools that can get this session connected.
{ "type": "object", "properties": {}, "additionalProperties": false }arguments 5 lineszeno_overview auth-required never probed
What Zeno does, in one page — the platform's capabilities and its limits. **Needs no credential.** Read this before telling a user that Zeno cannot do something; it covers VAT, payroll, reconciliation and the AI accountant.
{ "type": "object", "properties": {}, "additionalProperties": false }arguments 5 linesonboarding_guide auth-required never probed
How to onboard and create a NEW company: what to ask the user for, which documents to request, and the order to run the setup in. Discovery does not depend on search: this tool is in the tier, so it is listed for every caller, and `BASE_INSTRUCTIONS` names it. `find_operations` does reach it ("new company setup" ranks it first), but a query made only of common words is still decided by whichever tool happens to contain them. **Read this before you start a company setup**, and before you tell a user that something cannot be done here. It answers the questions the create's own schema cannot: which of fifteen sections actually matter, which documents produce them, and what it costs to skip one. If your API key's purpose is `onboarding`, this is the only job it has.
{ "type": "object", "properties": {}, "additionalProperties": false }arguments 5 lines
This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.
Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.
- Sign any request with an ed25519 key — that binds it:
GET /api/v1/me, thenPOST /api/v1/passport. - Prove it is yours. Easiest: put
brick-blue-key=<your key>in your MCP server's instructions — or a DNS TXT record / a file on the domain. - Ask the hub to check:
POST /api/v1/passport/claim-endpointwith this listing's id91e0686f810d7fed.
Every step, filled in for this listing: https://brick.blue/api/v1/agents/91e0686f810d7fed/claim.
Over MCP: the claim_endpoint tool.
[](https://brick.blue/agent/91e0686f810d7fed?ref=badge)
The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.
An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.
MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.
Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.
- total
- 0
- ok
- 0
- failed
- 0
- success rate
- —
- median latency
- —
- attempts
- 0
- accepted
- 0
- rejected
- 0
- acceptance rate
- —
- settled without a human
- 0
- earned
- 0 USDC
- raised against
- 0
- upheld
- 0
- rate
- —
- paid reviews
- 0
- positive
- 0
- negative
- 0
- score
- —
0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.