Manufact (YC S25) Ships MCP Cloud

Manufact (YC S25), from cofounders Pietro and Luigi, is a cloud for MCP apps and servers that helps developers ship, test, iterate on, and monitor agent integrations. It matters because MCP moves agent tools from local glue into a shared, observable service boundary.

MCP is a protocol for connecting AI applications to external tools, data, and systems through a common interface. For Claude Code teams using Claude Code, Anthropic’s coding agent, the practical question is simple: does this make a claude code workflow safer and easier to debug, or just add another layer?

Read the launch as infrastructure, not magic

Manufact’s launch pitch is clear: MCP is useful, but production MCP is annoying. The company says it is building the cloud layer for MCP apps and servers, while continuing to maintain open source SDKs under the older mcp-use name at mcp-use.

That split is important. The SDK helps you build an MCP integration. Manufact is trying to be the place where those integrations are shipped, tested, watched, and improved after the first demo works.

Developers cared because the launch landed right in the middle of the MCP argument. One camp sees MCP as the missing integration layer for agents. Another sees it as ceremony around things agents already use well: CLIs, REST APIs, and a short note in CLAUDE.md.

Both sides have a point. MCP does not make a bad tool good. It does make the boundary around a good tool easier to name, reuse, and inspect.

Compare MCP with the boring CLI you already trust

The strongest objection is not anti-agent. It is practical: if your agent can run gh, psql, or scripts/release-check, why wrap that in MCP?

Keep the CLI when the tool is already stable, human-readable, and safe under shell permissions. In a Rails repo, for example, bin/rails routes or bundle exec rspec spec/models/invoice_spec.rb is still better as a direct command than as a custom integration.

Reach for MCP when discovery, auth, logging, and narrower tool contracts matter more than raw convenience. A hosted MCP server that exposes search_customer_tickets and read_ticket is easier to reason about than giving an agent broad access to a helpdesk API token and hoping the prompt holds.

The trap is treating MCP as a replacement for product judgment. If nobody can say which actions are allowed, which are read-only, and who reviews the output, hosting the server will not fix the design.

Fit it into a Claude Code workflow without widening permissions

Start with one read-only MCP path in Claude Code. Not “connect the whole company.” One path.

A good first example is an issue-search integration. Let Claude search open GitHub issues, read a selected issue, and summarize likely affected files. Do not let it close issues, edit labels, trigger CI, or post comments on day one.

That keeps the value obvious. Claude can pull project context without asking a human to paste links, while the permission boundary stays boring enough to review.

A small repo note is enough:

# MCP integration boundary

Claude may use the issue-search MCP server for:
- listing matching issues
- reading issue bodies and comments
- summarizing references to files or errors

Claude must not use MCP tools to:
- create, edit, close, or label issues
- post comments
- trigger workflows
- export private issue data outside this repo

Pair that with a hook boundary where mutating tool names are blocked or require review before execution. If you already keep conventions in the related training topic, this is the same idea at the integration edge: durable rules belong near the repo, while task-specific instructions stay in the chat.

For a tighter boundary pattern, compare this with Bound Claude Code Agent Teams, then keep the Manufact experiment smaller than your ambition.

Try it safely with one read-only integration

Use this as a local decision table before wiring a hosted MCP server into daily work.

Copy this mini-checklist into the first pull request that adds the integration:

• Pick one workflow where the agent currently asks for pasted context.
• Expose only list, search, or read style MCP tools.
• Add a short permission note beside existing repo conventions.
• Run one task twice: once with the old CLI or paste flow, once with MCP.
• Review the diff, tool calls, and logs before adding any write action.
• Delete the integration if the agent output is not clearer, faster, or easier to audit.

The last step matters. A hosted MCP server should earn its place by making the work more inspectable, not by feeling more modern.

Common questions

• How does this change my Claude Code workflow?

  It changes where context comes from and how tool access is bounded. Instead of pasting issue text, docs, or API output into Claude Code, you can expose a narrow MCP tool that Claude calls directly. The useful first boundary is read-only: search, list, read, summarize, then stop.

• Is MCP better than a CLI for coding agents?

  Not always. A CLI is often better when it is already safe, scriptable, and obvious to review in a terminal log. MCP starts to win when you need a shared tool contract, managed auth, structured discovery, and monitoring around the same integration across repeated agent sessions.

• Does Manufact replace mcp-use?

  No. Based on the launch description, Manufact is the cloud product, while mcp-use remains the open source SDK work connected to the same team. A simple way to think about it: use SDKs to build the integration, and use the cloud when running, testing, and observing it becomes the problem.

• Should the first MCP server be read-only?

  Yes. Read-only is the safest first test because it proves whether the integration improves context without risking production state. A good first server exposes three verbs at most: list, search, and read. Add write tools only after reviewing real sessions and failure cases.

• What should go in CLAUDE.md for this?

  Keep CLAUDE.md short and durable. Put the integration boundary there, not a full operating manual: which MCP server is allowed, which actions are forbidden, and what evidence Claude should show before using the result in a code change. Long task instructions belong in the prompt or a slash command.

Best ways to use this research

• Best for: deciding whether an MCP cloud is useful for one real integration, not making a blanket architecture choice.
• Best first artifact: a read-only permission note plus one observed Claude Code session where the agent uses the MCP tool.
• Best comparison angle: MCP versus CLI, judged by auditability, auth scope, repeatability, and review friction.
• Best warning sign: the integration needs broad write tokens before it has proved value with read-only tools.

Further reading

• Claude Code — getting started
• Claude Code — skills
• Claude Code — hooks
• Claude Code — permissions
• Model Context Protocol — specification

Start with the smallest useful server

Try one read-only Manufact MCP integration against a workflow where Claude already needs pasted context. If the tool calls are easier to review than the old flow, keep going; if not, the boring CLI won this round.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.