{
  "markdown": "# Oakallow MCP Server\n\n[![MCP Badge](https://lobehub.com/badge/mcp/oakallow-oakallow-mcp)](https://lobehub.com/mcp/oakallow-oakallow-mcp)\n[![MCP Badge](https://lobehub.com/badge/mcp-full/oakallow-oakallow-mcp)](https://lobehub.com/mcp/oakallow-oakallow-mcp)\n\nRuntime permission, approval, and audit governance for AI agent tool execution.\n\nOakallow is a hosted remote MCP server. It sits between an agent and the actions it\nwants to take, so that a specific action can be checked, gated behind human approval when\nit is risky, authorized with a single-use signed token, and recorded in an immutable audit\nlog, at the moment of execution.\n\n- **Website:** https://oakallow.com\n- **MCP endpoint:** `https://api.oakallow.io/mcp` (Streamable HTTP)\n- **OAuth 2.1 compliance:** https://oakallow.com/docs/oauth\n- **MCP protocol details:** https://oakallow.com/docs/mcp\n\n## What this connector is for\n\nOakallow injects a governance checkpoint into a workflow that may also use other\nconnectors. An agent does its investigative work (for example, looking up an account\nthrough another connector), forms a recommendation, and calls Oakallow to **request**\napproval for the action. A human approver then decides in the Oakallow dashboard or mobile\napp, under enforced multi-factor authentication.\n\nThe connector is a **requester and pass-through**, not a decider:\n\n- It can list your tools, check permissions, request approvals, and mint run tokens once an\n  action is approved.\n- It cannot approve or deny on a human's behalf. Decisions happen on a separate,\n  MFA-bound surface (the dashboard), never over the connector.\n\n## Standard tools\n\n| Tool | Purpose | Reads only |\n|------|---------|:---:|\n| `list_my_tools` | Enumerate the tools available to the signed-in user in the named org (`org` arg; see below) | yes |\n| `check_permission` | Ask whether a given tool call would be allowed, require approval, or be blocked (takes an `org` arg; see below) | yes* |\n| `list_pending_approvals` | List approval requests still awaiting a human decision | yes |\n| `check_approval_status` | Poll a pending approval request by reference number | yes |\n\n\\* `check_permission` returns a read-only verdict only — it does NOT create an approval or\na reference. (The approval and its `REF-…` are created when you call the gated tool itself\nthrough oakallow.) It does have one side effect by design: checking an unregistered tool\nmakes Oakallow auto-create a gated draft entry for it (with conservative, fail-closed\ndefaults) so the eventual call is governed and the owner can triage it from the dashboard.\nThis is intentional: an unknown tool is never silently trusted.\n\n## Choosing an organization\n\nAn Oakallow account can have more than one organization, and each org sets its own tools,\npermission rules, approvers, and alert paths. So an action must be checked against the\n**right** org — that is what determines who gets asked to approve and under which rules.\n\n`check_permission` and `list_my_tools` accept an optional **`org`** argument: the org's\nexternal id (e.g. `org_oak_…`). The rule:\n\n- **One org on your account:** omit `org`. The connector uses your only org.\n- **More than one org:** pass `org` naming the org the action targets. If you omit it, the\n  call is refused with guidance rather than guessing the wrong org.\n\nYou don't ask the connector to list your orgs — there is no org-enumeration tool. Instead,\n**download the org-specific skill from that org's dashboard.** Each org's skill carries its\nown org id and tells the agent to pass it. Install one skill per org you operate in; the\nagent reads the matching skill and passes the right `org` on every call.\n\nThe connector authorizes the `org` you pass against your signed-in identity: you can only\ntarget an org you can actually act in (you are its team owner/admin, or you are in that\norg's approver group). Passing an org you don't have access to is refused — the skill is a\nconvenience, not a grant of access.\n\n## Resources\n\noakallow exposes two read-only MCP resources. They are preflight signals an agent (or a\nclient UI) can read before committing to route an action through oakallow. Both require\nthe `mcp:read` scope, neither is a tool call, and neither is billed.\n\n| Resource | Returns | Reads only |\n|----------|---------|:---:|\n| `oakallow://status` | Liveness of the connector for the signed-in session: status, endpoint, server version, protocol version, and the granted scopes. A successful read is itself the proof the session is valid. No account identity or PII is returned. | yes |\n| `oakallow://credits` | Whether a governed call would currently be funded for the org this session resolves to, so an agent can fail fast before requesting an approval that could not be paid for. | yes |\n\n`oakallow://credits` is scoped to the caller's own billing org and resolves it the same\nway a real tool call does, so a `can_fund: true` result genuinely means the eventual\napproval will be funded (including team-pool fallback). It returns only a `can_fund`\nboolean and the org's name and external id. It deliberately discloses no balance figures:\ndollar amounts are surfaced only to the team owner in the dashboard, never over the\nconnector. If the session resolves to no org, or to more than one, it returns\n`can_fund: false` with a reason rather than guessing which org would be billed.\n\n## Connecting\n\n**There is no anonymous access.** An oakallow account is the prerequisite for connecting,\nand the endpoint accepts two credential types: interactive OAuth 2.1 (PKCE) for a\nhuman-driven client, or an `oak_agent_` bearer token for an autonomous agent (see\n[Autonomous agents](#autonomous-agents-oak_agent_-token) below).\n\nFor the human-driven OAuth path, add `https://api.oakallow.io/mcp` as a custom connector\nin your MCP client (Claude, Claude Desktop, Cowork, ChatGPT, or any Streamable HTTP MCP\nhost). You will be redirected to sign in to Oakallow and approve the requested scopes:\n\n- `mcp:read`: list tools, view pending approvals, check permissions, read activity.\n- `mcp:write`: create approval requests and mint run tokens.\n\nYou don't configure any of this by hand: an unauthenticated request returns `401` with a\n`WWW-Authenticate` header pointing to the endpoint's RFC 9728 protected-resource metadata\n(`/.well-known/oauth-protected-resource`), so a spec-compliant MCP client discovers the\nauthorization server and runs the OAuth flow automatically.\n\nSee `examples/` for a Claude Desktop config and an OAuth flow walkthrough.\n\n### Autonomous agents (`oak_agent_` token)\n\nOAuth assumes a human can complete the interactive sign-in. An autonomous agent that runs\non its own authenticates to the same `https://api.oakallow.io/mcp` endpoint with a\npre-issued bearer token instead: `Authorization: Bearer oak_agent_...`. The endpoint\nchecks for an `oak_agent_` bearer before the OAuth provider, so no consent screen or\ninteractive login is involved.\n\nAn agent identity is scoped to one organization, can submit and check permission requests\nbut never approve, is rate-limited per identity, and is stored only as a SHA-256 hash (the\nraw token is shown once at creation). Provision one from the dashboard's Account →\nAgents page (owner/admin only). See [oakallow.io/info/agents](https://oakallow.io/info/agents)\nfor the full model.\n\n## Skill\n\n[`SKILL.md`](./SKILL.md) is an agent skill that documents when and how to use the\noakallow tools: the request, approve, poll, and act workflow, how to phrase\napproval reasons, and what to do on `allowed`, `requires_approval`, or `blocked`\nverdicts. Point your agent at it to govern tool actions correctly.\n\n## Trigger prompts\n\n[`PROMPT.md`](./PROMPT.md) has short, copy-paste one-liners to drop into your\nagent's system prompt so it actually consults the skill. The skill is the\nprocedure; a trigger prompt is what makes the agent look. Three options, from\n\"gate every tool call\" to \"gate a customer-named set,\" plus an inline example\npattern for a real request.\n\n## How a governed call works\n\n1. The agent calls Oakallow with its credential.\n2. Oakallow resolves the permission rule for the specific tool, tenant, and resource.\n3. If the action is allowed, Oakallow mints a single-use, HMAC-signed run token.\n4. If approval is required, an approval request is created and a human is notified. The\n   agent's call is held until the request is decided or expires.\n5. The agent uses the run token to perform the action; Oakallow writes an immutable audit\n   row capturing the outcome.\n\nOakallow lives outside the execution path. It governs and records what was reported; it\ndoes not run your tools or receive your tool parameters beyond a PII-scrubbed reason.\n\n## License\n\nSee [LICENSE](./LICENSE).\n\n## Changelog\n\nSee [CHANGELOG.md](./CHANGELOG.md).\n\n---\n\n© Islemonics Studios LLC. Patent pending.\n",
  "bytes": 8805,
  "sha": "e4efab3f9e8e308126858f9063de70b1b86c5676af4afefffa22f6e30fc7ba2d",
  "repo_slug": "oakallow/oakallow-mcp",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_oakallow_oakallow_fe84066f/readme"
}