Deploy from code
Link a repository, build a Python MCP or FastMCP server, and publish a live
endpoint for MCP clients.
Secure every request
Authenticate callers, enforce access, preserve sessions, and record request
metadata before traffic reaches server code.
Observe behavior
Inspect requests, server logs, sessions, clients, users, builds, and usage
patterns from one place.
Connect existing servers
Register remote MCP servers alongside hosted servers so teams can manage
access from the same Horizon surface.
Why Horizon exists
FastMCP made MCP servers easy to build. That changed the bottleneck. When teams can create useful servers quickly, the next question is how to share them safely: a remote endpoint clients can reach, a catalog where people can find approved servers, and access controls that match how work actually happens. Some tools should be available to everyone. Some should only be available to engineering, finance, or an on-call team. Some servers should be visible across the organization, while individual tools remain restricted to the people who need them. Horizon exists for that second phase of MCP adoption: turning individually useful servers into shared, governed infrastructure. Local servers are good for development. Shared servers need a lifecycle: builds, deployment URLs, previews, rollbacks, environment variables, authentication, authorization, logs, metrics, and a clear owner. Horizon brings that lifecycle to MCP without asking every team to rebuild the same platform around each server.What is an MCP gateway?
An MCP gateway sits between MCP clients and MCP servers. Instead of every client connecting directly to every server, the gateway receives requests first and handles shared platform concerns such as routing, authentication, authorization, session handling, and logging. In Horizon, every MCP request to a deployed server passes through the gateway before it reaches your code. That is where Horizon identifies the deployment, applies the server’s authentication mode, checks authorization, preserves MCP session routing, and records request metadata for logs and analytics. This matters because MCP access is not only a deployment problem. It is a policy surface. Teams need to decide who can discover a server, who can call it, who can manage it, and which tools a caller should be allowed to use. Horizon puts those decisions in the request path, so every server does not need to reimplement its own authentication, RBAC, logging, and session behavior.Authentication
Choose how callers prove identity when they connect to deployed MCP servers.
Horizon authentication is enabled by default so new hosted endpoints start
behind an access check.
Authorization
Use organization roles, server access, custom server roles, and tool-level
access to control what authenticated callers can do.
Request logs
See which client called which deployment, how the request was routed, and
whether the gateway accepted or rejected it.
Gateway
Learn the full request path from deployment lookup through access checks,
session routing, and server forwarding.
What you can build
Horizon supports three server patterns.Hosted servers
Build and run Python MCP or FastMCP servers from source code managed in a
Git repository.
External servers
Register MCP servers that run outside Horizon and manage their access through
Horizon.
Remix servers
Combine selected capabilities from multiple servers into one scoped MCP
endpoint.
| Server type | Best for | Who runs the code |
|---|---|---|
| Hosted | The fastest path when you want Horizon to package, deploy, serve, and observe your MCP code. | Horizon. |
| External | Systems that already have their own runtime. | You, outside Horizon. |
| Remix | Shaping the exact set of capabilities a team or agent should see. | The upstream servers you combine. |
How a hosted server works
Write or choose a server
Start with a Python MCP or FastMCP server. The server exposes tools,
resources, or prompts that MCP clients can call.
Link the repository
Connect the Git repository that contains the server. Horizon uses the
repository to create builds and deployment artifacts.
Deploy an artifact
A successful build becomes a deployable artifact. Deployments provide stable
URLs, preview environments, promotion, and rollback.
Core concepts
Builds
Builds turn repository source into deployable server artifacts. Build logs
explain dependency installation, entrypoint detection, inspection, and
packaging failures.
Deployments
Deployments decide which artifact serves traffic. Use them to promote,
preview, and roll back server versions.
Gateway
The gateway receives MCP traffic, identifies the deployment, enforces access,
preserves session routing, and forwards supported requests.
Compute model
The compute model explains startup, request handling, timeouts, memory,
environment variables, local state, and logs.
Authentication
Authentication determines how callers prove identity when they connect to
Horizon, the REST API, or deployed MCP servers.
Authorization
Authorization determines what authenticated callers can do at the
organization, server, and tool level.