Agent & MCP — integrate with LedgerFlow at AI speed
Point your coding agent at LedgerFlow and build your integration in an afternoon.
The public MCP server is a Model Context Protocol endpoint that customers connect to from the connector features of their own tools — VS Code (GitHub Copilot Agent), Claude Code, Claude Desktop, Cursor — with a single token. The agent then explores this deployment live and writes correct integration code against the real API, instead of you hand-translating docs.
It exposes a curated, read-only set of LedgerFlow tools plus documentation search, so the agent grounds its code in how the platform actually works — every call bounded by the same role grants and row-level security as a normal API client.
How customers integrate — your tools, our platform
The connector closes the gap between reading the docs and shipping working code. Your agent connects from your environment (left), talks to the curated public MCP connector (middle), which forwards every call into the same NGINX → PostgREST → PostgreSQL path the rest of the platform uses (right).
Why it accelerates integration:
- No SDK to install, no schema to copy. The agent reads the live tool surface and stays in sync with this deployment automatically.
- Grounded, not guessed. RAG search over the documentation means generated code matches the real endpoints, parameters and rules — not a hallucinated API.
- Safe to explore. Read-only, role- and RLS-bounded, fully audited — hand a partner or contractor a scoped token and let their agent learn the platform without risk.
What an agent can do once connected
Two kinds of tools, one token:
Data tools (read-only) — accounts & balances, transactions (and exceptions, notes, reversal chains), transaction rules, fraud/anomaly signals, maker-checker batches, reconciliation, payments, customers & KYC documents, and reference data (currencies, FX, tax rates). Every result is scoped by the token's role and row-level security.
Knowledge tools (RAG) — search_ledgerflow_knowledge, get_integration_example, and
explain_ledgerflow_concept search LedgerFlow's documentation so the agent grounds its answers and
code in how the platform actually works, not guesswork. Only documents marked agent-visible are
ever returned.
Three steps to a working integration
1 · Connect — generate an MCP Plugin Token and paste it into your client's config (60 seconds).
2 · Explore — your agent reads real accounts, transactions and reconciliation data, and searches the docs — grounded in this deployment, bounded by your role + RLS.
3 · Ship — the agent writes your integration against the genuine REST API surface. Reads happen through the connector to learn; production writes go through your own authenticated API keys.
The result: integrations that would take days of doc-reading land in an afternoon, and stay correct because the agent is reading the live platform, not a stale PDF.
Read-only, RLS-bounded
A connecting user resolves to their own LedgerFlow role (or the dedicated read-only
j_public_mcp_r role when there is no local account) — it can only ever read, and only what
row-level security allows. Admin and internal tools (user administration, SSO/system configuration,
the security audit log, scheduler/queue internals) are not exposed at all. The token never grants
write access.
Stateless & forwarded
The server is stateless: it forwards your bearer token to the same API (PostgREST) the rest of the platform uses, so permissions, RLS and audit logic apply uniformly. NGINX method-routing sends reads to the replica pool and any write-mode RPC to the primary, so RAG and statement tools work without ever loosening the security boundary. Tokens are signed for this deployment only; revoke by letting them expire or by rotating the deployment's JWT secret.