Developer
Assistant tools
Every tool the MCP server exposes, the feature each one needs, and why writes arrive as proposals.
The MCP server exposes two kinds of tool. Reads answer questions about the books. Proposals ask a person to approve something — they never post.
Read tools
| Tool | Feature it needs (read) |
|---|---|
| get_customers | `sales_customers` |
| get_vendors | `purchases_vendors` |
| get_items | `ops_products` |
| get_documents | Whichever feature owns the `document_type` asked for — Invoice → `sales_invoices`, Bill → `purchases_bills`, Purchase order → `purchases_purchase_orders`, and so on. An unrecognised type is denied. |
| get_statement_of_account | `sales_customers` **and** `purchases_vendors` — a party name alone does not say which side it is on, so both are required |
| get_accounts | `finance_coa` |
| get_journal_entries | `finance_journals` |
| get_currencies | `finance_coa` |
| get_taxes | `finance_taxes` |
| get_centers | `ops_business_units` |
| get_production | `ops_productions` |
| get_stock_movements | `ops_inventory` |
| get_employees | `people_payroll` |
Proposal tools
| Tool | Needs (create) | Result |
|---|---|---|
| propose_invoice | `sales_invoices` | A proposed sales invoice, waiting for a person to approve it in the app |
| propose_receipt | `sales_receipts` | A proposed customer receipt |
| propose_bill | `purchases_bills` | A proposed vendor bill |
| propose_payment | `purchases_payments` | A proposed vendor payment |
Nothing is numbered, journalled or settled by a proposal. A person opens it, checks it, and approves it — at which point the ordinary producer runs and the ordinary rules apply.
How a call is authorised
Four gates, in order, all failing closed:
- Staff can never reach a finance, people, document or reporting tool — whatever the key was minted with and whatever a role config says.
- An unmapped tool is denied. There is no default-allow.
- The key's grants narrow the tools. A tool is reachable only if its feature is on the key. A key minted read-only cannot reach a
propose_*tool even if its user could create in the app. - The bound user must hold the feature right now, on a live subscription.
⚠️An assistant cannot see more than its human
Every tool call resolves the same principal a signed-in session carries. Location allow-lists, data_scope, the Staff boundary — all of it applies. If the person who minted the key cannot open a screen, the assistant cannot read it either.
Related
- AI assistants (MCP) — connecting a client
- How access is decided
- Mint an API key