Authentication

The MCP server uses the same API tokens as the REST API. Every request carries the token in the Authorization header; each tool checks the token holds the right ability before running.

Mint a token

1. Open API tokens.
2. Click Create token, name it (e.g. "Claude Code").
3. Pick the abilities. Less is more — you can always mint another.
4. Copy the value. It's shown once.

Set it in your client config (Authorization: Bearer … for HTTP, AUTH_TOKEN env var for stdio).

Abilities

Ability	Powers
forms:read	List, fetch, see endpoints and metadata
forms:write	Create, update, publish, archive, restore
forms:test-email	Send test autoresponder / notification emails
submissions:read	Read submissions, files, signed URLs
submissions:write	Update, delete, bulk action
submissions:export	CSV / JSON exports
webhooks:read	List webhooks and deliveries
webhooks:write	Create, update, delete, replay
billing:read	Plan, usage, subscription, invoices
insights:read	Read AI insights
insights:write	Trigger regeneration
tokens:read	List your own tokens
tokens:write	Mint and revoke tokens (subset of caller's abilities)

Three checks per tool call

1. Ability — does the token hold the ability this tool needs?
2. Policy — for mutations, does the user have the policy permission?
3. Team — does the record belong to the calling team?

Miss any of them and the tool refuses.

Team scoping

Every token is minted in one team. Cross-team lookups return "not found" (not "forbidden") so an agent can't enumerate other teams. Switch teams in the dashboard before minting.

Revocation

Pull a token from API tokens in one click. The next call from the agent fails. No grace period.

Refusal message

Token missing required ability `submissions:write`.

The agent sees this in the tool result and either asks you, or falls back to a tool that's in scope.