Trust Center / MCP for Agents

MCP for Agents

TRAK exposes a Model Context Protocol (MCP) server so your AI agents can work with your NDIS data under your control. Every tool is permissioned, audited, and AU-resident. This page sets out how connection, authentication, and tool access work.

Connecting

  • Streamable HTTP MCP endpoint at /api/mcp. Machine-readable catalog at /.well-known/mcp.
  • Authentication is OAuth 2.1 with authorization code and PKCE. Compliant clients discover the authorization server via RFC 9728 protected-resource metadata and register dynamically, so there is no manual key exchange.
  • Access is scoped to the connecting user’s organisation and role. An agent can never reach another provider’s data; tenant isolation is enforced at the database with row-level security.

Safeguards

  • Every tool call is written to the tamper-evident, hash-chained audit log. No tool executes without an audit entry.
  • The MCP server is hosted in Australia on an Australian-owned host. NDIS participant data never leaves Australia through this surface.
  • High-risk tools require human-in-the-loop approval before they execute, and they fail closed until the backing controls are confirmed.
  • Tools whose result could drive a decision about a person carry an Automated Decision Making (ADM) disclosure, per the Privacy and Other Legislation Amendment Act 2024.

Tool Catalog

The tools currently registered on the TRAK MCP server. This list is generated from the server’s registry, so it always matches what is live.

ToolBehaviourRiskConsentADM disclosureWhat it does
list_participantsRead onlyLowNo confirmationNoList the active NDIS participants belonging to the caller's organisation. Returns minimal safe fields only (id, name, status, support flags). No PII (NDIS number, DOB, address, phone, email, funding allocation) is returned.
get_participantRead onlyLowNo confirmationNoGet a single participant by ID. Returns the participant only if they belong to the caller's organisation (enforced by RLS). Returns not-found if the participant does not exist or belongs to a different org — never surfaces another org's data.
get_funding_statusRead onlyLowNo confirmationNoGet a participant's funding status: their NDIS plan window (start date, end date, days remaining, whether the plan is active or expiring within 30 days, and plan management type) plus personal-spend ledger oversight (whether a ledger exists, transaction count, last activity date, and the latest monthly reconciliation status with an unreconciled-discrepancy flag). Scoped to the caller's organisation (RLS) and audited. Returns STATUS ONLY: no dollar amounts (plan allocation, ledger balance, and discrepancy figures are never returned through this surface). Returns not-found if the participant does not exist or belongs to another org.
query_at_inventoryRead onlyLowNo confirmationNoList the caller's organisation's assistive-technology inventory (funded equipment: commodes, electric beds, manual wheelchairs, Rifton chairs, and other). Optionally filter by participant, asset type, or status (active or retired; defaults to active). Each item includes its recurring safety-check schedule and status (overdue / due soon / upcoming) plus an overdue count, so an agent can tell at a glance whether any equipment is overdue a check. Ordered worst-status-first. Scoped to the org (RLS) and audited. The only participant reference returned is the opaque participant id; no participant name or NDIS number is surfaced.
query_audit_logRead onlyLowNo confirmationNoRead your organisation's tamper-evident audit log (owner/admin only). Returns metadata: who, what action, which record, when. Filter by table, action, and date range. No old_values/new_values are returned — metadata only so participant PII cannot leak through this endpoint.
submit_claimWrites dataHighHuman approval requiredYesSubmit an NDIS claim for a participant over a period. The claim is assembled FROM recorded shifts and journeys (never free-entered) and validated before submission: over-claiming is blocked as fraud, and soft holds (e.g. under-claim) require explicit operator acknowledgement. HIGH risk: requires human-in-the-loop approval. Fails closed until NDIS registration and legal sign-off are confirmed.