Standard MCP
Works with Claude Desktop, Claude Code, and any compliant client, over the standard transport with no bespoke SDK to adopt.
Platform · platform & data
The Model Context Protocol lets an AI client reach a system directly. That is genuinely useful and it is also the fastest way to hand an unaccountable process write access to your ledger — so the interesting part of an MCP server is not what it exposes, it is what it refuses.
What it does
Works with Claude Desktop, Claude Code, and any compliant client, over the standard transport with no bespoke SDK to adopt.
Balances, transactions, customers, vendors, projects, and documents — the same objects the application reads, not a reduced reporting extract.
Each connection is an actor with its own permission set, so what a client can reach is a grant you make rather than everything the token owner could see.
Connections are read-only unless you explicitly grant more, and the grants available stop well short of posting, approving, or releasing anything.
A write attempted through MCP passes the same policy engine as one from the interface. There is no path that bypasses it, which is the entire design constraint.
Every call is an audit entry with the client identity, the query, the scope, and what was returned — so a question about what an assistant saw has an answer.
An MCP server is a door. The question every security review should ask is what happens when somebody puts an untrusted instruction in front of a model that holds the key — a prompt injected through a vendor invoice, an email, or a document the model was asked to read.
The defence cannot be that the model will not be fooled, because eventually it will be. It has to be that the door does not open onto anything dangerous. So the authority available through MCP is deliberately bounded below the level at which a successful injection matters: no posting, no approval, no payment release, no permission changes, no vendor banking.
An MCP connection is not a token that inherits its creator’s access. It is an actor with its own grants, expiry, and scope, which means a connection created by a controller does not silently carry that controller’s authority across nine entities.
Most customers scope a connection to read-only on one entity for the first month, look at the audit trail, and widen from there. That is the pattern we recommend rather than the one we merely permit.
Investigative work. Why did travel expense rise in the Denver office, which vendors are we paying under two records, which projects have unbilled work older than sixty days — questions that require several joined queries and would otherwise be a reporting request.
It is also good at drafting. Compose the variance commentary, summarise this contract against what was invoiced, prepare the schedule. The output arrives as a draft a person releases, which is where the authority boundary sits for good reason.
Not for bulk data movement — use the API, which is built for it and rate-limited accordingly. Not as an integration transport, because a conversational protocol is a poor substitute for one with delivery guarantees. And not as a way around a permission somebody was refused elsewhere; it will refuse them identically.
Limits
Posting, approving, releasing payment, changing permissions, and vendor banking are unavailable through MCP at any configuration. This is not a setting.
Rate-limited and designed for investigation. Moving large volumes belongs on the API or a warehouse export.
We scope and log what the connection may reach. What the client does with the results — where it stores them, who sees them — is governed on your side.
Questions
Tell us the client and the use case. We will scope it and show you the audit trail it produces.