Help

Overview — read this first All help

Overview — read this first

OPN Support is where OPN's operations support works: every question or problem an FI, an integrator or a merchant brings is a case, and everything that happens to it is on the case's timeline, in order, with who did it and how. If you are an agent connecting over MCP, this page gives you the shape of the whole tool before you drive any part of it.

What the tool holds

object ref what it is
Case CASE-2026-0130 One party's question or problem, worked to a resolution. Owned by one entity — the one that wrote to us — and may involve others. Carries the original request (as received, never edited), a working description, one next action, notes, and optionally a component (a part of the OPN stack).
Response (an id, on its case) One outbound message on a case — email or SMS — from draft through review to sent and delivered.
Broadcast BCAST-2026-015 One message OPN sends to an audience: updates, disruptions, maintenance, all-clears, outage alerts.
Time entry TIME-2026-000123 Minutes an operator spent on a case.
Persona PRS-0007 The name and address a customer sees on a response: yours, one of your own, or a shared one.
Entity a slug such as orange_bank An organisation in the tree: OPN at the root, FIs and integrators beneath.

Objects are addressed by ref, never by database id. Enumerated fields are plain words: statuses new, open, pending_customer, pending_internal, resolved, closed; priorities low, normal, high, critical; case types access, configuration, onboarding, transfer, incident, notice, security, defect, question, business, other, noise (docs://case-types has a playbook for each). docs://cases and docs://case describe each.

What makes the record trustworthy

  • The timeline is append-only. Nothing on it is edited or deleted; a correction is a new event. What you write is read months later by someone who cannot ask what you meant.
  • Every write is attributed. The actor is the token's owner, and the event records that it came through a token. You cannot write as someone else, and you cannot write anonymously.
  • Visibility is by entity. You see a case if your entity owns it, sits above the owner, or is involved in it. The tool applies this to every tool call; there is nothing to pass.
  • Versions guard concurrent edits. Every update_*, edit_* and send_* tool takes expected_version from a prior read. If the object changed underneath you, the result is isError with conflict: true, the current version and the fields that differ. Re-read and retry; never guess.

Your authority

You add no authority by connecting. The acting identity is always the token's owner, and the token's grants and cap narrow what the owner could do by hand. An agent token drafts and proposes — cases, notes, response drafts, broadcast drafts, time entries — and never sends, approves or administers. Those tools are absent from your tools/list and answer isError if called. A person reviews and sends what you draft; that is the design, not a limitation to work around.

Read order

  1. This page.
  2. Working a case — the workflow and the record conventions.
  3. Writing to customers — before you draft any response.
  4. Review and sending — what happens to a draft, and how to behave while it waits.
  5. Choosing a persona — whose name goes on it.
  6. Case or broadcast? — before creating anything.
  7. The query guide — before any query_* call.
  8. Case types and Lessons from past cases — the playbooks and the patterns that worked and didn't.

Page help (docs://cases, docs://case, docs://broadcasts, docs://library, docs://personas, and the rest) describes each screen; the tool descriptions state each tool's preconditions. When a page and a guide disagree, the tool's own answer wins: read the object again.