Claude Connectors Directory

What this path is

Use this guide when OSuite needs to appear as a public Claude connector rather than a desktop-only package. The goal is a connector that reads like a business tool inside Claude: review sensitive work, route approvals, and share audit-ready records without exposing internal runtime vocabulary.

This path is not the same as the local Claude Desktop Extension.

• Claude Desktop Extension is the private or enterprise desktop package.
• Claude Connectors Directory is the public remote MCP connector path.

Choose this path when you want:

• public discovery inside Claude
• one OAuth-based connector flow instead of workspace API keys in local config
• a connector that can graduate from custom connector testing into Directory review
• a productized approval experience that reads like a business tool instead of an engineering bridge

What OSuite exposes

The remote connector keeps the same governance contract as the desktop package, but the end-user surface is deliberately smaller and more productized:

• review_planned_work
• check_if_approved
• record_final_outcome
• open_audit_record

Session creation, decision-context capture, replay packaging, and session closing are now handled inside OSuite rather than exposed as separate customer-visible tools.

The difference is transport and auth:

• transport: remote MCP over streamable HTTP
• auth: OAuth 2.0 authorization code flow with PKCE
• install channel: Connectors Directory

OAuth surface

OSuite now serves the standard metadata needed for Claude connector review:

• protected resource metadata at /.well-known/oauth-protected-resource/osuite-mcp
• authorization server metadata at /.well-known/oauth-authorization-server/osuite-mcp
• authorization endpoint at https://id.osuite.ai/authorize
• token endpoint at /api/connectors/osuite/oauth/token

The scope exposed for governed runtime work is:

• osuite.runtime.write

How the consent flow works

1. Claude opens the OSuite authorization endpoint.
2. The user signs in to OSuite Studio if needed.
3. The user chooses the workspace that should receive governed sessions and evidence.
4. OSuite issues an authorization code bound to that workspace and the connector client.
5. Claude exchanges that code with PKCE for a bearer token.
6. Tool calls use that token when creating runtime sessions, actions, assumptions, approvals, replay links, and proof exports.

What makes this publishable

For Directory submission, the connector now has:

• a remote MCP endpoint
• annotated tools with titles and read-only vs destructive hints
• OAuth 2.0 + PKCE
• a public privacy policy
• public documentation for installation and behavior

That does not mean the desktop package goes away. The correct packaging split is:

• Claude Connectors Directory for public discovery
• Claude Desktop Extension for desktop-first pilots, private rollout, and managed enterprise installs

Test it before review

Before submitting to Anthropic review, validate it as a custom connector:

1. Register the protected resource metadata URL with Claude.
2. Complete the OSuite authorization screen.
3. Confirm initialize and tools/list succeed.
4. Call review_planned_work and verify the runtime session and governed action appear in OSuite.
5. If the action escalates, call check_if_approved; when it completes, call record_final_outcome and confirm the audit links behave the same way as the desktop package.

Verification links

• Runtime bootstrap
• Runtime detail
• Control Center

Privacy

OSuite privacy policy: osuite.ai/privacy-policy

Recommended positioning

Do not position this as “OSuite does smarter approvals than Claude.”

Position it as:

• Claude provides runtime autonomy
• OSuite provides organizational authority
• replay, proof, approval evidence, and non-execution proof stay consistent across runtime vendors
• the connector presents those controls in plain product language, not internal runtime vocabulary