Oakallow MCP Server

Runtime permission, approval, and audit governance for AI agent tool execution.

Oakallow is a hosted remote MCP server. It sits between an agent and the actions it wants to take, so that a specific action can be checked, gated behind human approval when it is risky, authorized with a single-use signed token, and recorded in an immutable audit log, at the moment of execution.

• Website: https://oakallow.com
• MCP endpoint: https://api.oakallow.io/mcp (Streamable HTTP)
• OAuth 2.1 compliance: https://oakallow.com/docs/oauth
• MCP protocol details: https://oakallow.com/docs/mcp

What this connector is for

Oakallow injects a governance checkpoint into a workflow that may also use other connectors. An agent does its investigative work (for example, looking up an account through another connector), forms a recommendation, and calls Oakallow to request approval for the action. A human approver then decides in the Oakallow dashboard or mobile app, under enforced multi-factor authentication.

The connector is a requester and pass-through, not a decider:

• It can list your tools, check permissions, request approvals, and mint run tokens once an action is approved.
• It cannot approve or deny on a human's behalf. Decisions happen on a separate, MFA-bound surface (the dashboard), never over the connector.

Standard tools

* check_permission returns a read-only verdict only — it does NOT create an approval or a reference. (The approval and its REF-… are created when you call the gated tool itself through oakallow.) It does have one side effect by design: checking an unregistered tool makes Oakallow auto-create a gated draft entry for it (with conservative, fail-closed defaults) so the eventual call is governed and the owner can triage it from the dashboard. This is intentional: an unknown tool is never silently trusted.

Choosing an organization

An Oakallow account can have more than one organization, and each org sets its own tools, permission rules, approvers, and alert paths. So an action must be checked against the right org — that is what determines who gets asked to approve and under which rules.

check_permission and list_my_tools accept an optional org argument: the org's external id (e.g. org_oak_…). The rule:

• One org on your account: omit org. The connector uses your only org.
• More than one org: pass org naming the org the action targets. If you omit it, the call is refused with guidance rather than guessing the wrong org.

You don't ask the connector to list your orgs — there is no org-enumeration tool. Instead, download the org-specific skill from that org's dashboard. Each org's skill carries its own org id and tells the agent to pass it. Install one skill per org you operate in; the agent reads the matching skill and passes the right org on every call.

The connector authorizes the org you pass against your signed-in identity: you can only target an org you can actually act in (you are its team owner/admin, or you are in that org's approver group). Passing an org you don't have access to is refused — the skill is a convenience, not a grant of access.

Resources

oakallow exposes two rea

... View full README on GitHub