Connections

Connections is where you connect services, verify the operations they expose, route them to the right specialists, choose approval policies, and inspect what ran.

What it is#

Each manifest-backed connection declares a service, authentication method, specialist routing, default risk, and the operations discovered or defined for it. The Studio joins that manifest with local credential state, live health, operation policies, pending one-time approvals, and recent audit events.

Connections is the control plane for manifest-backed third-party services. Settings still owns model configuration, operating-system services, and several native integrations. If a requested ID belongs to one of those native cards, Zimac routes you back to Settings rather than presenting a fake catalog item.

Built-in connections#

The current catalog spans source control and delivery, documents and knowledge, product and design, infrastructure and observability, security, people systems, and other MCP-capable services. The actual list and the operations a provider returns are dynamic; the Studio inventory in your build is authoritative.

Authentication can be a stored bearer credential, provider-specific setup fields, or browser-based OAuth when the provider supports the MCP OAuth flow. Credentials go to the local credential store and are not rendered back into the page.

Use an existing sign-in#

Found on this Mac scans local account names and profile metadata for reusable sessions and configurations. Supported adoption paths include GitHub CLI, AWS config, Google Cloud config or application-default credentials, kubeconfig, and Databricks config. Zimac does not use a discovered session until you click Use existing.

When AWS uses a credential process, the confirmation explains which executable the installed AWS CLI may invoke. Zimac asks the CLI for credentials after consent; it does not execute the profile command itself inside the page.

Custom MCP connections#

You can add a remote MCP endpoint with a display name, description, complete URL, authentication choice, and optional operation allowlist. Remote endpoints must use HTTPS; loopback HTTP is reserved for local development. The Studio currently caps custom connections at 16.

Leave the allowed-actions field blank to discover up to 20 operations, or list exact operation names to expose only that subset. New custom operations ask before they run. Tokens and request contents remain out of the activity log.

Readiness & discovery#

After setup, Refresh runs provider discovery and updates the health state. A connection can be not configured, needs attention, or healthy. “Needs attention” may mean a live verification failed, a sign-in expired, required setup is incomplete, or the build has no verifier for that integration.

Discovered operations are then joined to the specialists the manifest permits. The detail page shows what each specialist can access and how each operation is currently governed.

Operation policies#

Operations are classified as View Prepare Change Delete or Admin. Within the safe choices for that risk, a policy can make an operation automatic, require approval, or keep it unavailable for a particular specialist.

High-impact actions do not become blanket automatic operations. Delete and administrative risks, wildcard rules, and future operations keep stronger constraints so a broad policy cannot silently approve an unknown capability.

Approvals#

The Approvals tab lists exact requests waiting for you. A decision is tied to the service, operation, assistant, and request shown. Approve once cannot be reused for a different request; Don’t allow records the denial and leaves the operation blocked.

Past decisions remain visible separately from the current queue. The Studio polls while open so a request staged from chat can appear without a reload.

Activity history#

The History tab records the connection, operation, specialist, authorization path, risk, outcome, and error when one occurred. It intentionally excludes credentials and private request data. This is a useful local operational ledger, not a copy of every provider-side log or a substitute for the provider’s audit system.

Connection recipes#

A connection recipe lets teammates copy shareable setup: which built-in services a team uses, non-secret tenant or client settings, safe HTTPS endpoints, and operation policies. Credentials are never included. Applying a recipe previews endpoint and policy changes, asks separately before redirecting an endpoint, and finishes by telling each teammate which services still need sign-in.

Boundaries#

• A healthy connection means its current verification passed; it does not guarantee every future provider request will succeed.
• The operation catalog is provider- and build-dependent. Do not assume every MCP tool is exposed.
• Connections does not make arbitrary remote HTTP requests; custom entries use the MCP transport and declared operation boundary.
• Activity history omits request contents by design and is not a forensic export.
• Native/local integrations may continue to live in Settings rather than Connections.