Connect multiple providers

Plan each provider independently

Use this recipe when one person’s client needs reviewed context from more than one upstream system. Begin with providers that have a supported setup path in your deployment, and identify a permitted read for each. The connection directory alone does not prove that a provider is ready to activate.

• Identify the upstream organization or workspace for each installation.
• Decide the team scope and the account that will authorize each provider.
• Review the commercial effect of enabling separate production connections.
• Choose read-only validation requests that make the provider and resource unambiguous.

Why one gateway

Instead of configuring your MCP client with separate connections for GitHub, Jira, and Slack, point it at Durin once. Durin routes each tool call to the right upstream provider based on the connection configuration. All requests go through the same governance path.

Set it up

Add multiple connections to one Durin workspace.

1. Add a GitHub connection for your engineering organization.
2. Add a Jira connection for your project management workspace.
3. Add a Slack connection for your team workspace.
4. Complete consent, discovery, permission review, read-only testing, and billing confirmation separately for each connection before enabling it.
5. Your MCP client can discover reviewed, active tools available to your identity through one personal Durin endpoint.
6. Organization policy applies alongside team access, reviewed tool resources, and each connection’s credential boundary.

Verify one connection before adding the next

Complete the first provider’s consent, discovery, review, test, and activation checkpoints, then verify a member’s read through the personal endpoint. Repeat that process for the second provider instead of enabling several untested drafts at once.

This sequence isolates failures. A missing Slack grant should not be confused with a GitHub resource denial, and a successful read from one provider does not establish another provider’s scope or current credential. Keep the evidence identified by connection.

Check the combined client view

Once the intended connections are enabled, refresh discovery in the client and inspect the reviewed tools available to the signed-in identity. Use that identity’s endpoint throughout; you do not need a separate personal Durin endpoint for every upstream connection.

1. Run a small reviewed read against the first provider and verify its activity record.
2. Run an independent read against the next provider and verify that it used the expected connection.
3. Check a person who should have access to only one team-scoped installation.
4. Confirm that a missing grant or disabled connection is diagnosed on that installation, without weakening organization policy.

Track cost and access as the set grows

Each enabled, verified production connection contributes to the organization’s connection quantity. Users, agent clients, and tools inside those installations do not multiply the unit count. Review the current billing preview before every activation.

Keep ownership of provider consent, team membership, and troubleshooting clear as more systems are added. When retiring one provider, disabling its installation should be an explicit decision; removing a tool from one client’s display is not a workspace-wide access change.