MCP server

PRYVC runs a Model Context Protocol server at https://mcp.pryvc.com, so an agent can read and act on consent records directly rather than scraping a dashboard.

• Transport: JSON-RPC 2.0 over HTTP POST
• Protocol version: 2025-03-26
• Server: pryvc-mcp v1.0.0
• Auth: Authorization: Bearer pat_…

Getting a token

Tokens are minted from the surface you already sign in to, and inherit exactly that principal’s access — there is no separate permission model to reason about.

You are	Mint at	Endpoint
A member	app.pryvc.com → Profile	POST /v1/me/agent-token
A business	portal.pryvc.com → Integrate	POST /v1/business/portal/agent-token

Tokens are shown once, expire in 90 days, and are stored hashed — we cannot recover one, only issue another.

Connecting

{
  "mcpServers": {
    "pryvc": {
      "url": "https://mcp.pryvc.com",
      "headers": { "Authorization": "Bearer pat_your_token" }
    }
  }
}

Verify by hand:

curl -s https://mcp.pryvc.com \
  -H "Authorization: Bearer pat_your_token" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Tools

Which tools appear depends on your token. A consumer token never sees business tools and the reverse holds — the server filters tools/list by principal, so an agent is not offered anything it would be refused.

Tool	Principal	What it does
pryvc_list_shares	either	Consumer: your shares. Business: shares consented to you.
pryvc_get_share	either	One share by id, with fingerprint and status.
pryvc_revoke_share	consumer	Sever a share. Starts the cease-contact obligation.
pryvc_update_field	consumer	Update one contact field; broadcasts to active in-scope shares.
pryvc_get_audit	either	Your tamper-evident audit history, most recent first.
pryvc_list_events	business	Recent outbound events for your business.

What an agent cannot do

Worth stating plainly, because the useful question about an agent is what it is unable to do.

• It cannot grant consent. There is no tool to create a share or issue a certificate. Granting requires a person at a consent screen, and an agent acting for you is not that person. It can revoke, because withdrawal never needs the same ceremony as agreement.
• It cannot read another principal’s records. Every tool is scoped to the token’s principal, enforced server-side.
• It cannot escalate. A token carries one realm, fixed when minting, and tools/list only advertises that realm’s tools. Calling across realms is refused server-side even if the agent guesses the name.
• It cannot tick a consent box anywhere, by any route. That constraint runs through the whole product, not just this surface.

Consent rails for agents

Agents that fill forms, place orders and request quotes on someone’s behalf need consent primitives a machine can act on and a machine can verify. That is what this surface and SP/1 are: tools an agent can call under a scoped token, and evidence it can recompute against a published specification with normative test vectors.

The contrast is the point. A screen recording is something only a person can watch and only a vendor can vouch for — an agent can neither produce a meaningful one nor check somebody else’s. A fingerprint over canonical facts is implementable by anyone and checkable by anything.

Why the tool list stops where it does

The absence of a consent-granting tool is the point of this surface, not a limitation of it.

Agents already fill forms on people’s behalf, and that breaks the assumption under most consent evidence. Session replay and behavioral scoring exist to show that a human was present: mouse paths, keystroke cadence, time on page. An agent generates none of it. The session either trips fraud scoring or looks clean and demonstrates nothing, and neither outcome is something you can hand a carrier.

Two properties keep the evidence meaningful when the filling is automated:

• Consent stays human. There is no tool here that creates a share or issues a certificate. An agent acting for someone is not that person at a consent screen, so it can read, update and revoke — never agree. A form filled by an agent still needs a person to tick the box, which is exactly what makes the resulting certificate worth holding.
• Evidence is recomputable, not watchable. A fingerprint over canonical facts can be checked by software against a published specification with test vectors. A screen recording can only be watched by a human and vouched for by the vendor storing it. When the actor is software, the first kind survives and the second does not.

Errors

Two different shapes, and the distinction matters when you are writing a client.

Protocol failures come back as JSON-RPC error objects:

Code	Meaning
-32001	Missing or unrecognized token (HTTP 401)
-32600	Malformed request — not JSON-RPC 2.0, or no method
-32601	Unknown method
-32000	Server could not reach storage (HTTP 500)

Tool failures are not protocol errors. tools/call returns a normal result with isError: true and the reason as text — an unknown tool, a wrong-realm tool, or a tool that ran and failed all arrive this way. Check isError; do not assume a result means success.

Calling a tool your principal may not use returns tool <name> requires a <realm> token, which does tell you the tool exists. That is deliberate — the tool list is published here anyway, and a clear message beats an agent retrying a call it can never make.