Skip to content
TEAMS

Shared MCP and skills for every developer environment

Configure org-wide MCP servers and shared skills once. Each developer inherits them inside their own isolated cloud environment.

12.4k GitHub stars1.7k forks

Team setup without a shared runtime

CloudCLI syncs the shared pieces into each developer's own container. The baseline is common; credentials, terminal state, and running processes stay personal.

Org-wide MCP servers

The tools every project needs, shared once. Personal MCP servers stay personal.

Shared skills

Store them once, then sync them into the environments in scope.

Reusable developer environments

New teammates inherit the setup when they start work.

Separate developer runtimes

Shared setup does not mean a shared runtime.

Configure team setup once

The organization owns the MCP servers and shared skills. Each developer's container, credentials, and terminal state stay theirs.

Add org-wide MCP servers and skills

Add org-wide MCP servers from Settings, choose stdio or http, and decide whether OAuth uses one organization connection or each user's own token. CloudCLI syncs the server into the environments in scope and records sync results per environment.

Open a new environment with setup already synced

When a teammate's environment is created or started, CloudCLI syncs the org MCP servers and shared skills that apply to them. No one copies a private MCP config over chat, and the developer's container stays theirs.

Shared baseline. Separate runtime.

Standardize what should be common while credentials, OAuth tokens, running processes, and terminal state stay attached to each developer.

One org baseline

Org MCP servers and shared skills define the baseline every developer starts from.

Personal scope stays personal

User-scoped MCP, OAuth tokens, credentials, and terminal state stay attached to the developer.

No shared runtime

Every developer starts from the same baseline inside their own isolated cloud environment.

FAQ

It is a hosted development setup where the team standardizes the parts that should be common while each developer works in a separate runtime. In CloudCLI, the shared layer is org-wide MCP servers and shared skills, and each developer still opens their own reusable, sandboxed cloud environment.

Standardize the setup, not the runtime. CloudCLI syncs organization-level MCP servers and shared skills into each developer's own environment, so the team starts from the same baseline without sharing one container.

Teams create org-wide MCP servers in CloudCLI settings. Org-wide servers are visible to the organization and sync to environments in scope. User-scoped MCP servers sync only to the environments owned by the developer who created them.

Yes. Team setup can be shared, but each developer still gets a separate cloud environment. Their container, credentials, running processes, and terminal state are not a shared team runtime.

A new teammate inherits the org-wide MCP servers and shared skills that apply to their environment. They still get their own reusable sandbox, container state, credentials, and running processes.

Yes. User-scoped MCP servers and skills sync only to the creator's environments. For OAuth MCP servers, CloudCLI supports either one organization connection or per-user OAuth, so personal tokens do not have to become team-wide state.

Yes, and the same applies to Cursor CLI, Codex, and Gemini CLI. Org-wide MCP servers and shared skills are configured once and sync into every developer's environment, so a Claude Code team stops re-doing setup per laptop. Each developer still works in their own isolated container, and personal credentials stay personal.

Give every developer the same agent setup

Configure MCP servers and skills once. Every developer inherits them inside their own reusable, sandboxed cloud environment.

No pitch, just answers →