Skip to main content
A Horizon plan applies to an entire organization. It determines which product capabilities the organization can configure and use. Plans are cumulative: includes the capabilities in , and includes the capabilities in both lower tiers. Plan availability and access permissions are separate checks. A plan can make a feature available to the organization, while organization and server roles determine which actors can use or manage it.
This page describes standard product availability. Included usage, seat quantities, pricing, and contract terms appear in Horizon’s Billing area and can vary by organization.

​
Plan tiers

For an individual building and operating hosted MCP servers. It includes the core build, deployment, gateway, client, and observability workflow.
For teams operating MCP servers together. It adds organization collaboration, durable automation identities, external servers, and more control over hosted server networking and authentication.
For organizations that need centralized identity, governed server access, curated MCP surfaces, and custom serving domains.
Start with when one person owns the organization and its hosted servers. Choose when multiple people need access or when production automation should use a service account instead of a person’s identity. Choose when access must be managed with custom roles, capability-level policy, or single sign-on.

​
Feature availability

A checkmark means the capability is part of the standard plan. A blank cell means the organization needs a higher plan before it can configure or use that capability. The matrix covers generally available plan features. Separately purchased add-ons appear in the organization’s Billing area. An add-on enables its own capability without changing the organization’s base plan.

​
Feature gates

Horizon checks plan availability at both the dashboard and API boundaries. The dashboard keeps the surrounding workflow visible and marks unavailable actions with the plan required to unlock them. API requests for an unavailable feature return a forbidden response instead of applying the change. Permissions still apply after the plan check succeeds. For example, an organization can define custom server roles, but only an actor with the required organization permission can create or change those roles. A higher plan never grants an actor additional role permissions by itself.

​
Plan changes

The billing contact manages plan changes for the organization. The effective date shown during checkout or in Billing determines when the new feature set applies. An upgrade unlocks the higher tier’s features when the change becomes effective. A downgrade keeps the current feature set until its effective date, then applies the lower tier’s availability. Before a downgrade, review automations, servers, access policies, and identity settings that depend on the current tier. Requests that require a removed feature are denied after the lower plan takes effect. Product feature availability is distinct from technical and usage limits. See Limits for the runtime, build, request, and configuration boundaries that apply while a feature is in use.