ch.zeno-works/zeno · v0.1.0 · finance-and-payments
Zeno is healthy: it completed an MCP handshake in 2256 ms and exposes 51 tools.
AI bookkeeper for Swiss small companies: books invoices, reconciles the bank, keeps VAT current.
Endpoint: https://app.zeno-works.ch/mcp (streamable-http)
No repository listed · Website · JSON · Add to my inventory
| Users (last 30 days) | 0 |
| Handshake | Healthy |
| Auth needed | None |
| Tool count | 51 |
| Latency | 2256 ms |
| Last checked (UTC) | 2026-10-17T01:05:41.372Z |
| Checked (UTC) | Status | Latency | Error |
|---|---|---|---|
| 2026-10-17T01:05:41.372Z | Healthy | 2256 | |
| 2026-10-15T18:15:15.072Z | Healthy | 1685 | |
| 2026-10-14T17:20:52.183Z | Healthy | 3599 |
find_operations | 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 unl |
describe_operations | 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 ou |
call_operation | 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 callin |
request_api_key | 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 o |
start_signup | 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`, show |
collect_api_key | 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 |
whoami | 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 |
list_companies | List companies (jwt, scoped). Non-admins see only their member companies. |
get_company | Get one company (jwt, scoped). 403 for a non-member non-admin, 404 if absent. |
global_search | 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). |
get_kpi_report | 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. ``f |
get_work_list | Everything waiting for this user in this company, most severe first. |
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 verdic |
accept_autopost_decision | 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 accepte |
upload_intake | 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, CS |
upload_document | 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 |
get_intake | Get one intake row by id (scoped to its company: 404/403 split). |
list_items | 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_statu |
get_item | Item metadata (any source). |
gl_trial_balance | 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) |
gl_profit_and_loss | 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 t |
gl_balance_sheet | 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 ``asse |
list_gl_accounts | List the postable chart (CompanyMember). ``fiscal_year`` filters to one year's chart (the chart is FY-scoped, so codes repeat across years). |
get_gl_account_ledger | 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 reve |
list_gl_periods | 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 |
list_gl_open_items | 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 f |
list_gl_journal_entries | 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-si |
get_gl_journal_entry | 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 indistinguish |
create_gl_journal_entry | 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. ``documen |
post_gl_journal_entry | 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-poin |
reverse_gl_journal_entry | **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_da |
list_bank_accounts | 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 cod |
list_bank_entries | List Bank Entries |
get_bank_entry | Get Bank Entry |
entry_candidates | Entry Candidates |
settle_entry | 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. T |
reconciliation_summary | 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_a |
list_ar_invoices | 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"}``. |
get_ar_invoice | 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``), ``d |
create_ar_invoice | 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_dat |
issue_ar_invoice | 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, |
list_counterparties | 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. |
list_gl_vat_periods | List Gl Vat Periods |
list_payroll_runs | 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 c |
list_payroll_employees | 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 (``e |
get_financial_statements | 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 acc |
customer_statement | 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. |
get_bank_status | 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}/cover |
zeno_info | 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. |
zeno_overview | 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. |
onboarding_guide | 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 |