Manufact launched a cloud platform for hosting Model Context Protocol (MCP) servers, moving the deployment boundary from agent runtime to managed infrastructure. MCP is Anthropic’s standard for connecting LLMs to external data sources. Until now, teams building agents had to self-host these context servers, handle multi-tenancy, and manage state persistence themselves. Manufact abstracts that layer.
The launch drew 108 points and 69 comments on Hacker News. The team previously built open-source MCP SDKs under the name mcp-use before pivoting to cloud hosting. The shift is significant because MCP adoption is accelerating, but deployment friction slows integration. Hosting MCP servers as a service changes where the security boundary sits and who owns state management.
Three infrastructure questions define the platform’s architecture:
- How does authentication and authorization work when multiple agents access the same MCP server instance?
- What state persistence model allows MCP servers to maintain context across agent sessions without coupling to specific LLM providers?
- How does multi-tenant MCP hosting isolate customer data while allowing shared server instances, and what are the security boundaries?
What MCP Servers Do
MCP servers expose tools and context to LLM agents. An agent calls an MCP server to read a database, fetch API data, or execute a function. The server returns structured data the agent can reason over. The protocol standardizes the interface, so agents can call any MCP server without custom integration code.
Self-hosting MCP servers means:
- Running a process that listens for agent requests
- Managing authentication tokens per agent or user
- Persisting state across sessions if the tool requires it
- Isolating data when multiple tenants share the same server instance
Manufact moves all of this to a hosted platform. You push code, and the platform handles deployment, routing, and multi-tenancy.
Why Trading and Financial Agents Need MCP Hosting
The discovery signal for this launch came from a “trading agents” query on Hacker News, reflecting developer interest in using MCP servers for financial automation. Financial agents use MCP servers to access market data feeds, execute trades, and manage portfolio state. A trading agent might call an MCP server to:
- Query real-time price data from Bloomberg or Reuters APIs
- Execute buy/sell orders through broker APIs
- Retrieve historical OHLCV data for backtesting
- Access portfolio positions and calculate risk metrics
These operations require stateful connections and strict isolation. A trading agent managing multiple client portfolios cannot leak position data between accounts. The MCP server must maintain separate state per tenant and enforce data boundaries at the request level.
Hosting this infrastructure yourself means running servers that handle API rate limits, manage WebSocket connections to market data feeds, and persist session state across agent restarts. Manufact’s platform handles the infrastructure layer, letting you focus on the trading logic inside the MCP server code. The platform’s multi-tenancy and state persistence features map directly to the requirements of agents that manage money, which is why the financial discovery signal validates the infrastructure angle: developers building trading agents need exactly this kind of hosted, isolated, stateful MCP infrastructure.
Hosting Architecture
Manufact’s platform runs MCP servers as isolated instances with shared infrastructure. The architecture splits into three layers:
Deployment layer: Git integration watches your repo. Each push triggers a build and deploys a new server instance. No Dockerfile required. The platform infers runtime dependencies from your code.
Routing layer: Agents connect to MCP servers via unique URLs. Each server gets a subdomain or custom domain. SSL is automatic. The routing layer forwards agent requests to the correct server instance based on the URL.
State and auth layer: MCP servers can be stateless or stateful. Stateless servers handle each request independently. Stateful servers persist context across agent sessions. Manufact provides a state store that survives server restarts. Authentication happens at the routing layer, not inside the server code. The platform issues API keys per tenant and validates them before forwarding requests.
Authentication and Authorization Flow
Agents authenticate to MCP servers using API keys. The platform handles validation at the routing layer, not in your server code. Here’s the flow:
- Agent sends a request to the MCP server URL with an API key in the
Authorizationheader. - Manufact’s routing layer validates the API key against its key store.
- If valid, the platform extracts the tenant ID associated with the key and forwards the request to the server instance.
- The server code receives the request with a
tenant_idfield injected by the platform. - The server processes the request, queries data scoped to the tenant, and returns a response.
Authentication is pulled out of the MCP server code entirely. You don’t write token validation logic. You trust the platform to inject the correct tenant ID. The tradeoff is that you lose control over the auth mechanism. If you need custom auth (OAuth, SAML, mTLS), you have to implement it inside the server and bypass the platform’s key validation.
For multi-agent scenarios where different agents need different permissions to the same MCP server, the platform’s API key model is coarse-grained. Each key maps to a tenant, not to specific permissions within that tenant. If your trading agent needs read-only access to market data but write access to order execution, you have to enforce that inside your server code based on the tool being called.
State Persistence Model
MCP servers often need to remember context across agent sessions. Examples:
- A database query tool that caches schema metadata
- A workflow tool that tracks multi-step tasks
- A session manager that stores user preferences
- A trading agent that maintains open order state across restarts
Manufact provides a key-value state store. Your server code writes state using the platform SDK:
import { state } from '@manufact/mcp-sdk';
// Write state scoped to the current tenant
try {
await state.set('user_preferences', { theme: 'dark', lang: 'en' });
} catch (error) {
// If state write fails, fall back to in-memory cache and warn agent
console.error('State write failed, using in-memory fallback:', error);
memoryCache.set('user_preferences', { theme: 'dark', lang: 'en' });
return { warning: 'Preferences saved to session only, not persisted' };
}
// Read state for the current tenant
const prefs = await state.get('user_preferences');The SDK automatically scopes reads and writes to the tenant identifier injected by the routing layer. State persists across server restarts and deploys. The store uses a distributed key-value database with tenant-based partitioning.
State size limits apply. Manufact enforces a per-tenant quota. If your server needs to store large datasets, you should use an external database and treat the state store as a metadata cache.
The state persistence model is provider-agnostic. Your MCP server doesn’t know or care which LLM is calling it. State is scoped to the tenant, not to the agent or LLM provider. This means a trading agent can switch from Claude to ChatGPT without losing its open order state, as long as both agents authenticate with the same tenant API key.
Multi-Tenancy and Isolation
Hosting MCP servers for multiple customers on shared infrastructure requires isolation. Manufact uses process-level isolation. Each deployed server runs in its own container. Containers share compute resources but have separate memory and file systems.
Data isolation happens at two levels:
-
Request-level isolation: The routing layer tags each incoming request with a tenant identifier. The MCP server code can read this ID and filter data accordingly. If your server queries a database, you add a
WHERE tenant_id = ?clause. -
State isolation: The state store partitions data by tenant partitioning. When a server writes state, the platform automatically scopes it to the tenant. When the server reads state, it only sees data for the current tenant.
This model works when your MCP server logic is tenant-aware. If your code doesn’t check tenant identifiers, you risk data leakage. Manufact provides SDK helpers to enforce tenant filtering, but the responsibility still sits with the developer.
For financial agents, tenant isolation is critical. A trading agent managing multiple client portfolios must never return positions or trade history for the wrong account. The platform’s tenant ID injection reduces the risk of manual auth bugs, but your server code must still validate that every database query includes the tenant filter.
Observability and Debugging
The platform includes a Cloud Inspector tool that traces MCP traffic. You can:
- View all requests sent to your server
- Replay individual requests to reproduce bugs
- See latency breakdowns for each tool call
- Filter by tenant, agent, or time range
Debugging agent-to-server interactions is hard because agents make non-deterministic tool calls. Reproducing a failure requires capturing the exact request payload and tenant state. The Inspector stores request history and lets you replay requests against the current server version or a previous deploy.
Analytics track usage, latency, and error rates per server and per tenant. You can set alerts when error rates spike or latency exceeds a threshold.
Deployment Shape
Manufact auto-deploys on every Git push. The deployment pipeline:
- Detects code changes in your repo
- Builds a container image with inferred dependencies
- Runs tests if you define them
- Deploys the new image to production
- Routes traffic to the new version
Preview environments spin up for each pull request. Every branch gets a unique URL. You can test changes before merging.
Custom domains let you host MCP servers under your own domain. You point a CNAME record at Manufact’s routing layer, and the platform handles SSL certificates via Let’s Encrypt.
Security Boundaries
The security boundary sits at the routing layer, not inside the MCP server code. Here’s how responsibilities split:
| Boundary | Responsibility | Risk |
|---|---|---|
| API key validation | Platform | If the platform’s key store is compromised, all tenants are exposed |
| Tenant ID injection | Platform | If the platform injects the wrong tenant identifier, data leakage occurs |
| Data filtering | Developer | If server code doesn’t filter by tenant, isolation breaks |
| State encryption | Platform | State store encrypts data at rest, but keys are managed by the platform |
| Network isolation | Platform | Containers share a network namespace; lateral movement is possible |
You trust the platform to enforce isolation. If you need stronger guarantees (dedicated instances, customer-managed keys, network segmentation), you have to self-host.
Failure Modes
When infrastructure moves to a hosted platform, new failure modes appear. Here are the common scenarios:
State store outage: If the state store goes down, servers that depend on state will fail. Your server code should handle state read failures gracefully and degrade to stateless operation when possible.
Routing layer failure: If the routing layer crashes, agents can’t reach your server. The platform should run multiple routing instances behind a load balancer, but a misconfigured deploy could take down all instances.
Tenant ID injection bug: If the platform injects the wrong tenant identifier, your server will return data for the wrong tenant. This is a critical bug. You should add assertions in your server code to validate that the injected tenant ID matches expected patterns.
API key leakage: If an agent leaks its API key, an attacker can impersonate that tenant. The platform should support key rotation and rate limiting, but you should monitor for unusual usage patterns.
Technical Verdict
Manufact MCP Cloud is useful for teams building agent tools that need to ship fast. The auto-deploy pipeline and built-in multi-tenancy remove common deployment headaches. The state store and auth layer are good enough for most use cases, including financial agents that manage client portfolios with strict isolation requirements.
Use it if:
- Your state requirements are under 10MB per tenant
- API key authentication is sufficient for your security model
- You need fast iteration with preview environments per pull request
- You trust platform-managed multi-tenant isolation
- You want to avoid managing container orchestration and SSL certificates
- Your MCP servers are stateless or have light state needs (session data, user preferences, cached metadata)
Avoid it if:
- Your state requirements exceed 100MB per tenant or need complex queries (use external database instead)
- You require custom authentication mechanisms (OAuth, SAML, mTLS)
- You need dedicated compute instances or network isolation for compliance
- You handle regulated financial data requiring customer-managed encryption keys
- You need to run MCP servers in a specific region, VPC, or air-gapped environment
- Your security model cannot accept platform-managed tenant ID injection
The security boundary tradeoff is real. You trust the platform to isolate tenants and validate API keys. If your MCP servers handle sensitive data, audit the platform’s isolation guarantees and consider adding your own tenant checks in server code.
The observability tools (Cloud Inspector, analytics) are valuable for debugging non-deterministic agent behavior. Replaying requests and tracing tool calls saves time when agents make unexpected tool selections.