Birbla

Discussion summary

Manufact (YC S25) launched MCP Cloud, with many users relying on it for building MCPs. There is debate over the use of MCP versus CLI, especially for remote operations.

What the discussion says

  • Many users find MCP essential for building MCPs.
  • Some argue CLI is better for local use, but MCP is more practical for remote tasks.
  • Concerns about security and setup complexity favor MCP for remote use.
  • Debate exists on whether MCP or CLI is the future for development workflows.
“Running CLIs is impractical and expensive in many environments.”
— phpnode
“Most MCPs are remote, and the comparison with CLI falls short.”
— timq

Comments

Hacker News

Question: I have an MCP server that is working well with Auth (Google Only), running on vercel. What benefit would I get from running it on manufact?

On monetizing my MCP... How do the different MCP "Stores" handle this? Do some take a cut? Or are they agnostic? Does manufact help with monetization?

by mrtimo

The marketplace/distribution angle is interesting to me, is ChatGPT really surfacing & reccomending random MCP apps to users based on their conversations, or this still aspirational/early days? How is discoverability in these marketplaces, are users actually browsing/searching for MCP apps and using them?

by coreylane

This is great. I hadn't heard of MCP Apps — pulling an interface into the LLM could be really useful. I'll trying it.

Been finding some tasks are better inside Claude or ChatGPT chat window, like brainstorming names. I ended up building an MCP for domain lookups (https://namebrewery.com). It lets me go back and forth, branch on different preferences, and steer the LLM toward a name I like, and still available as a dot com.

The examples in your repo have given me some other ideas to try out.

by anthonyko

MCP is a protocol, that's all.

Saying MCPs are the new websites is like saying "SOAP" is the new websites, or "REST" is the new websites.

MCP is basically the AI equivalent of a REST API, it's not a product anymore than JSON is a product or XML is a product.

by saberience

Cool. The main thing I like about MCP is the authentication story, particularly the standardisation around OAuth.

Because of that, I think it is often worth wrapping an API in an MCP server. I actually had to do this recently.

I have been working on an open-source project called crmkit.ai. I was not planning to add MCP support because the project already works in a very agent-native way, where the agent reads the `setup.md` file at the root of the server and then uses `curl`.

That works well for normal agents. It kind of works in claude.ai, although you need to allowlist the domain. It does not work on chatgpt.com because the sandbox does not allow arbitrary outbound web requests. It should work fine in Codex, Claude Code, etc. because those run locally.

For ChatGPT, I was forced to write an MCP server. But because this is supposed to be an agent-first CRM, I thought that instead of exposing hundreds of small tools and polluting the context, why not expose a single tool called `request`, where the LLM writes the actual HTTP request?

That should work, right?

It does not. ChatGPT effectively forces you to unwrap the entire API into lots of small tools, because each one may need to be authorised separately.

Anyway, I ended up doing it, but needless to say, the design feels wrong. It would have been much better if the MCP server could expose a single `request` tool and keep the context tight.

The single-tool concept does work. We use crmkit internally with fully autonomous agents, and I even use it personally as a productivity tool.

The moral of the story is that MCP has great authentication but I rather not use it if I can. If I need to use it I would prefer to expose a single tool that write the raw request even-though it feels like a hack and it does not work across all chat systems.

I hope this anecdote helps.

by _pdp_

This is cool. I was skeptical of MCP's until I made one recently. They're essentially the exact same as 1) giving your agent a CLI tool or REST API and 2) pointing it there in an AGENT.md/CLAUDE.md. Agents are great at using built-for-human CLI tools and IMO they don't need anything purpose-built for agents. The key difference, which ends up being a usability win for non-technical users, is that the MCP bundles 1 and 2 - harnesses inject the MCP tool descriptions on every session after install. Of course, that's also why you need to be careful about context bloat when using/building them

by rgbrgb

I am really impressed with your demo video, particularly the analytics, logs, and test suite features.

I'm a target customer where I have a few curious customers, but I'm not fully ready to roll it out yet across the customer base. One thing that's stopping me, what does credits mean on your pricing page? And what is the pay as you go price after you hit your limit? I would need to be able to budget this before I deploy.

The second piece - we already have a CLI, which is great for terminal based agents and what we will continue to recommend. What we really want, and I think is what you are offering, is basically an easier way to deploy a 'remote connector' to use Claude lingo so that normal users with the claude/chatgpt app can just use our MCP. Can you point me to guidelines or the right place in your open source templates to understand how I would best handle auth (or the tradeoffs in each) during the initial build phase of the MCP server?

by msencenb

Having to sign up to browse available MCPs stopped me dead in my tracks and made me close the tab. I won't be the only one. Perhaps consider allowing people to browse more of the site before you try to force a signup on them?

by Brainspackle

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Question: I have an MCP server that is working well with Auth (Google Only), running on vercel. What benefit would I get from running it on manufact?

    On monetizing my MCP... How do the different MCP "Stores" handle this? Do some take a cut? Or are they agnostic? Does manufact help with monetization?

    by mrtimo
  • The marketplace/distribution angle is interesting to me, is ChatGPT really surfacing & reccomending random MCP apps to users based on their conversations, or this still aspirational/early days? How is discoverability in these marketplaces, are users actually browsing/searching for MCP apps and using them?
    by coreylane
  • This is great. I hadn't heard of MCP Apps — pulling an interface into the LLM could be really useful. I'll trying it.

    Been finding some tasks are better inside Claude or ChatGPT chat window, like brainstorming names. I ended up building an MCP for domain lookups (https://namebrewery.com). It lets me go back and forth, branch on different preferences, and steer the LLM toward a name I like, and still available as a dot com.

    The examples in your repo have given me some other ideas to try out.

    by anthonyko
  • MCP is a protocol, that's all.

    Saying MCPs are the new websites is like saying "SOAP" is the new websites, or "REST" is the new websites.

    MCP is basically the AI equivalent of a REST API, it's not a product anymore than JSON is a product or XML is a product.

    by saberience
  • Cool. The main thing I like about MCP is the authentication story, particularly the standardisation around OAuth.

    Because of that, I think it is often worth wrapping an API in an MCP server. I actually had to do this recently.

    I have been working on an open-source project called crmkit.ai. I was not planning to add MCP support because the project already works in a very agent-native way, where the agent reads the `setup.md` file at the root of the server and then uses `curl`.

    That works well for normal agents. It kind of works in claude.ai, although you need to allowlist the domain. It does not work on chatgpt.com because the sandbox does not allow arbitrary outbound web requests. It should work fine in Codex, Claude Code, etc. because those run locally.

    For ChatGPT, I was forced to write an MCP server. But because this is supposed to be an agent-first CRM, I thought that instead of exposing hundreds of small tools and polluting the context, why not expose a single tool called `request`, where the LLM writes the actual HTTP request?

    That should work, right?

    It does not. ChatGPT effectively forces you to unwrap the entire API into lots of small tools, because each one may need to be authorised separately.

    Anyway, I ended up doing it, but needless to say, the design feels wrong. It would have been much better if the MCP server could expose a single `request` tool and keep the context tight.

    The single-tool concept does work. We use crmkit internally with fully autonomous agents, and I even use it personally as a productivity tool.

    The moral of the story is that MCP has great authentication but I rather not use it if I can. If I need to use it I would prefer to expose a single tool that write the raw request even-though it feels like a hack and it does not work across all chat systems.

    I hope this anecdote helps.

    by _pdp_
  • This is cool. I was skeptical of MCP's until I made one recently. They're essentially the exact same as 1) giving your agent a CLI tool or REST API and 2) pointing it there in an AGENT.md/CLAUDE.md. Agents are great at using built-for-human CLI tools and IMO they don't need anything purpose-built for agents. The key difference, which ends up being a usability win for non-technical users, is that the MCP bundles 1 and 2 - harnesses inject the MCP tool descriptions on every session after install. Of course, that's also why you need to be careful about context bloat when using/building them
    by rgbrgb
  • I am really impressed with your demo video, particularly the analytics, logs, and test suite features.

    I'm a target customer where I have a few curious customers, but I'm not fully ready to roll it out yet across the customer base. One thing that's stopping me, what does credits mean on your pricing page? And what is the pay as you go price after you hit your limit? I would need to be able to budget this before I deploy.

    The second piece - we already have a CLI, which is great for terminal based agents and what we will continue to recommend. What we really want, and I think is what you are offering, is basically an easier way to deploy a 'remote connector' to use Claude lingo so that normal users with the claude/chatgpt app can just use our MCP. Can you point me to guidelines or the right place in your open source templates to understand how I would best handle auth (or the tradeoffs in each) during the initial build phase of the MCP server?

    by msencenb
  • Having to sign up to browse available MCPs stopped me dead in my tracks and made me close the tab. I won't be the only one. Perhaps consider allowing people to browse more of the site before you try to force a signup on them?
    by Brainspackle