The admin guide to setting up OAuth providers, configuring MCP servers, and controlling what your Organization's Charms can access.

Everything your Organization's Charms can connect to flows through you. You define which external services are available, configure the credentials that make connections possible and set the ceiling on what those connections are permitted to do. Users authorize their own individual accounts — but they can only authorize connections to services you've set up.

Two concepts to understand before configuring anything:

 — Your Organization's registered OAuth application with a provider (Google, GitHub, Slack, etc.). Created once. Shared across all users who connect to that provider.

 — The specific endpoints your Charms call. Each MCP server is tied to an Integration (for OAuth-protected services) or uses a static token or no authentication. You control which tools each MCP server exposes to your Organization.

Before users can authorize connections to an external service, you need to register your Organization's OAuth application with that provider and create an Integration in CharmIQ.

CharmIQ supports 34 built-in providers plus a Custom option for any OAuth-compliant service.

The client secret is stored encrypted and is never visible after creation.

 If you need to rotate it, create a new Integration and migrate your MCP server definitions to it.

With an Integration in place, you can add MCP server definitions — the actual endpoints your Charms will call.

The allowed tools setting is a ceiling, not a floor. Users can further restrict which tools individual Charms use — but they can never exceed what you've configured at the Organization level.

When you define an MCP server, you can specify exactly which tools it exposes to your Organization. A server might offer 40 tools; you might permit 10. Users can narrow that further when configuring individual Charms — but they can't go beyond what you've allowed.

The effective set of tools any Charm can use is always the intersection of three things:

Tighter ceilings mean cleaner audits. If your use case only needs read access, don't permit write tools.

When external tools connect to CharmIQ (Claude Code, VS Code, Zapier, custom integrations), they appear as OAuth clients. Two types require your attention:

 — Created automatically when MCP-compatible tools like Claude Code connect. They self-register and are cleaned up after 90 days of inactivity. No action needed from you.

 — Created by you for custom integrations that need a client secret (server-to-server flows). You create these in CharmIQ's admin settings, issue the Client ID and Secret, and distribute them to whoever is building the integration.

You can review all connected clients and revoke access to any of them at any time.

Some administrative actions have downstream consequences:

These are clean breaks — no orphaned credentials.

 — The user-facing view of what you're configuring here.

 — How users and developers connect external tools to CharmIQ using the OAuth clients you manage.

 — The conceptual overview of how integrations fit together.

 — How Organizations work, how users can belong to multiple, and how billing is tied to the active Organization.

The admin guide to setting up OAuth providers, configuring MCP servers and controlling what your organization's agents can access.

Type	When to Use
OAuth	Most cloud services (Google, GitHub, Slack, etc.) — requires an Integration
Static Token	Services that use API keys rather than OAuth
None	Public endpoints or services that authenticate through other means

Managing Integrations

Your Role as Organization Owner

Setting Up an Integration

Configuring MCP Servers

Controlling What Charms Can Do

Managing Inbound OAuth Clients

Cascade Effects

Patterns

Next Steps