Skip to lesson

AnthropicClaude Certified Architect – Professional2026-107.1 Configure Claude tools and environments for teams (e.g., Claude Code)

Review capabilities before distributing them broadly

Completed by the knowledge check

Learning objective

Distribute team capabilities through shared Skills, plugins, and connectors with review before broad rollout.

Core idea

A project skill shares a procedure, and an MCP server supplies integration capabilities. The professional addition is a distribution decision: what gets installed together, who approves executable content, how updates reach users, and which consumer surfaces receive the intended controls.

Do not turn a successful individual installation into an organization-wide requirement without reviewing its contents and update path. A plugin can introduce instructions, shell hooks, and server processes in one installation. A connector can introduce access to external data and actions without being a plugin at all. Review what the recipient can execute or disclose, rather than approving a familiar package name.

How it works

Choose the distribution unit by maintenance ownership

Keep a procedure in the repository’s .claude/skills/<name>/SKILL.md when its lifecycle follows that repository. For a reusable bundle across repositories, a Claude Code plugin packages components such as skills, agents, hooks, and MCP servers as one installable unit. A marketplace is the catalog that tells Claude Code where to fetch those plugins.

For organization-wide machine deployment, Enterprise skills live at .claude/skills/<skill-name>/SKILL.md inside the managed settings directory and reach users on machines where the organization deploys them. For account-linked distribution, organization-provided skills and plugins sync into terminal sessions on Claude Code v2.1.273 or later only under the developer’s claude.ai account sign-in, rather than API-key authentication. Synced skills download into ~/.claude/skills/synced/ and also load in Cowork and cloud sessions; synced plugins appear as <name>@synced and also load in Cowork. Choose machine deployment for endpoint ownership and account distribution when the required consumer sessions use that account.

This packaging reduces duplicated maintenance but widens the consequences of a release. If several teams use the same hook, the plugin maintainer owns compatibility with their environments. If teams need unrelated versions or approval rules, record that requirement before forcing one fleet-wide package.

Connectors supply external integrations. For the terminal and IDE sessions that fetch claude.ai connectors themselves, loading depends on an active claude.ai subscription login. An active API key, third-party provider, or CLAUDE_CODE_OAUTH_TOKEN from claude setup-token does not load those connectors. A service working in an engineer’s signed-in terminal therefore does not prove it is available to an API-key CI worker.

Review the actual package before installation

Use claude plugin marketplace list to inspect the catalog’s source. In /plugin, inspect the plugin’s details and its Will install inventory. That inventory can be incomplete for a remote package, and showing a hook’s existence does not show its command.

Read the plugin source, especially hooks/hooks.json, .mcp.json, and bin/. Verify command paths, server URLs, credential requirements, and the operations the procedure directs Claude to perform. You can inspect a cloned candidate without starting a session with claude --plugin-dir PLUGIN_DIRECTORY plugin details PLUGIN_NAME; replace the uppercase placeholders with the candidate directory and name. The command prints the discovered component inventory.

A catalog’s publisher does not establish that every component meets your team’s requirements. Anthropic’s security documentation calls for reviewing plugins regardless of their marketplace. Hooks and server processes run outside the Bash sandbox with the user’s permissions, so approving only the model’s tool-call list misses executable dependencies.

Give the review a named maintainer and an approved revision. Test representative successful work, rejected operations, missing credentials, and installation on a clean environment. These tests are the team’s release criteria, not a product-provided certification of plugin safety.

Register, enable, and restrict through separate settings

Fleet distribution uses extraKnownMarketplaces to register the source and enabledPlugins to select packages. This illustrative managed policy registers a reviewed internal catalog and requires its review plugin:

{
  "extraKnownMarketplaces": {
    "internal-tools": {
      "source": { "source": "github", "repo": "example/internal-tools" },
      "autoUpdate": false
    }
  },
  "enabledPlugins": {
    "service-review@internal-tools": true
  }
}

Replace the repository and package with your approved values. Users need read access to a private Git marketplace. Managed enabledPlugins: true force-enables the named plugin; a managed false blocks it. The same distribution keys can be set in project settings for repository scope, but project marketplaces require workspace trust. A package fetched from an external source may also require each contributor to run claude plugin install NAME@MARKETPLACE --scope project; replace NAME and MARKETPLACE with the plugin and marketplace names. A project enablement entry alone is not proof of installation.

Use managed strictKnownMarketplaces when the requirement is to restrict catalog sources. It neither registers a marketplace nor reviews individual entries inside it. It also does not cover --plugin-dir; disableSideloadFlags blocks that route. If one package in an otherwise approved catalog must be prohibited, set that package’s managed enabledPlugins entry to false.

Stage updates without assuming group-targeted remote policy

Marketplace autoUpdate determines whether its catalog and plugins refresh in the background. A managed value prevents users changing that update choice themselves. Turning it off supports a deliberate release window, but it is not an immutable content pin: the owner still needs an approved revision and a controlled update process.

For stable and pilot channels, Anthropic documents separate marketplaces pointing to different plugin refs, delivered through separate endpoint-managed configurations or gateway policies. Server-managed settings from the admin console apply uniformly to the organization and cannot assign separate settings to groups. Apply the managed-source selection rules in 7.1.2 before assuming a pilot MDM profile actually wins.

Verify connector controls on each consumer surface

For connectors Claude Code fetches itself, inspect /mcp after authenticating with the intended account. disableClaudeAiConnectors: true turns off that fetched connector route; it does not control connectors delivered by the cloud host or Desktop app.

Organization connector tool controls also differ by surface. In sessions where the ask control reaches Claude Code, a tool set to ask prompts on every call and is denied in dontAsk. Desktop local and SSH sessions instead receive connectors in-process: blocked tools are withheld, but the organization’s ask setting does not reach Claude Code, so ordinary session permissions apply. Review the precise surface before promising identical approval behavior everywhere.

Key distinctions and trade-offs

Procedure, package, and connection: A skill describes work; a plugin distributes components; a connector provides an integration. The three can cooperate without sharing an installation or authorization lifecycle.

Allowed source versus approved revision: A marketplace allowlist constrains origins. It does not establish that changed package contents passed review.

Central distribution versus targeted rollout: Fleet enablement improves consistency; pilot channels require a delivery mechanism that can actually target the pilot population.

Architecture / decision scenario

A technology company has 60 engineers across six repositories. A review skill and issue connector work for all 8 signed-in pilot engineers, but none of the 8 API-key automation trials obtain the intended issue data through that connector route. The tempting proposal is to force-enable the package for everyone because the interactive pilot succeeded.

The developer-tools owner keeps repository-specific instructions local and bundles shared review automation into a reviewed plugin. Security inspects the hook commands, server destination, and executable files. The integration owner gives automation an explicitly supported MCP connection rather than relying on the subscription connector route. The pilot receives its own marketplace through targeted endpoint policy, with controlled updates. Before expanding to the remaining engineers, the owner verifies plugin installation and connector approval behavior on the terminal and Desktop surfaces the company supports.

Common exam traps

  • Treating catalog inclusion as approval of all executable content.
  • Using strictKnownMarketplaces as a registration or per-package approval mechanism.
  • Assuming an allowlist blocks --plugin-dir.
  • Treating autoUpdate: false as immutable version pinning.
  • Expecting organization-wide server-managed settings to target a pilot group.
  • Assuming subscription connectors and approval controls behave identically in every surface.

What to remember

Review the contents and update route, then distribute through the smallest appropriate scope. Registering, enabling, restricting, and verifying capabilities are separate decisions. Test each consumer surface and authentication method before broad rollout.

Knowledge check

References