The same tools. A different way in.

One account, one assigned business

The account adapter uses a dedicated machine credential. Its account and business are fixed in the process configuration; tool arguments cannot select another business, supply a human session or widen a scope. Every call asks the API for current authority.

Customer reads

tallylane_list_account_customers and tallylane_get_account_customer return current scoped customer details, including permitted personal information.

Invoice reads

tallylane_list_account_invoices and tallylane_get_account_invoice return bounded draft/issued amounts. Unresolved VAT and gross remain null; a read does not prove payment or accounting transfer.

Create a customer

tallylane_create_customer sends one closed profile with the caller’s retained commandId. Requires customers:create and the accepted TEST write release.

Save an invoice draft

tallylane_create_invoice_draft sends quantity/price/tax-code lines. The server calculates totals. This saves a draft; it does not approve or issue an invoice.

Recover the original command

tallylane_get_account_create_command reads a historical creation receipt using the original commandId and operation scope, including after credential rotation.

Configure the account adapter

Ask your Tallylane administrator for the assigned account/business IDs and a scoped TEST machine credential. Store that credential in your system’s secret manager and inject TALLYLANE_ACCOUNT_TEST_TOKEN into the server environment. No signup, human-password sharing or provider key is needed for this adapter.

TALLYLANE_MCP_ENVIRONMENT=test
TALLYLANE_ACCOUNT_API_ORIGIN=https://tallylane-api.vercel.app
TALLYLANE_ACCOUNT_MCP_READ_CONTRACT=ACCOUNT_MACHINE_READ_V1
TALLYLANE_ACCOUNT_ID=<assigned-account-uuid>
TALLYLANE_ACCOUNT_BUSINESS_ID=<assigned-business-uuid>
# TALLYLANE_ACCOUNT_TEST_TOKEN is injected by your secret manager.
node /absolute/path/to/tallylane-mcp/src/account-stdio.mjs

Install with the repository’s pinned npm lock first. Use Node 24–26 and a compatible stdio MCP client. Default configuration exposes four reads. After the matching backend has passed acceptance, an operator can opt into writes with TALLYLANE_ACCOUNT_MCP_WRITE_CONTRACT=ACCOUNT_MACHINE_CREATE_V1; absent scope, revoked authority, an expired grant or a disabled backend still blocks the request.

A business identifier is not authorisation

The account API uses a tla_test credential with current scopes, finite expiry and the canonical managed-account assignment. It is separate from the partner-issued-invoice adapter, which uses tlp_test and a delegated partner read grant. Human JWTs, partner keys and account keys cannot substitute for each other.

Account creation credentials are returned once to an authorised administrator. A lost create/rotate response cannot be recovered as a secret by replay; inspect metadata and explicitly revoke or rotate. Restart the stdio process with the newly issued credential. Client confirmation does not replace a durable business approval.

Keep the original command when the answer is lost

Generate and persist a commandId once before submitting a customer or draft. Each distinct operation needs its own key. The adapter makes one POST and never retries or creates a replacement UUID. A timeout or invalid acknowledgement returns command_outcome_unknown with that original key.

{
  "commandId": "<original-command-uuid>",
  "command": "customers:create"
}

Call tallylane_get_account_create_command. Its receipt is version 1 at creation, not the resource’s current version; follow with a current detail read. A 404 is not permission to invent a new key or automatically repeat the write. Issuance, payment, email and accounting execution have their own workspace approval and access steps.

Trace effects without exposing credentials

The backend retains machine identity, canonical account/business, operation, durable receipt and audit outcome. The adapter does not cache authority or log tool input/results, access tokens, provider keys or customer data. Customer read output contains permitted personal information, so choose a client with appropriate data handling.

Repository acceptance and hosted availability

Local SDK/subprocess and synthetic HTTP checks prove adapter boundaries. Separate real PostgreSQL/HTTP tests prove the registered account API’s writes, reads, denials, audit and original-command recovery. Neither proves a deployed account has usable credentials or that a provider workflow ran. Verify the actual hosted release, flags and scoped grants before connecting a customer system.