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.
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?
hey thanks for the feedback, we do not really offer a "set" of pre made MCPs that we could show pre signup, unfortunately our platform requires you to deploy something to use it - we try to give an overview of all the features in our "Platform" section in the navbar on top
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 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?
thank you so much we have put a lot of love into our product!
pricing: we offer several credit based products that have different cost - requests, build minutes, eval runs, checklist all have different unit cost the breakdown is here https://docs.manufact.com/dashboard/billing thanks for pointing out that it should be more transparent!
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?
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
I don’t like that non-technical users has to keep context bloat in mind. That should be ”solved” on the developer end. How would they now it’s bloated if they treat MCPs like regular software? I 100% agree on designing things for humans, and you’ll get the AI-agents for free. I am surprised no one seems to have figured that out yet.
+1 !! Thanks for putting it so clearly, also CLIs and REST have their space in some applications, I think MCP is a way to organize them and distribute them better
Thanks for the comment! Vercel is a generic cloud provider, so you won’t get any of the MCP specific features (listed in the post) and development experience - monetization is still not regulated by the protocol, so people would pay for your product before using your MCP, then you can charge based on subscription or usage as usual!
One issue i saw related to scopes is the offline_access one that causes frequent reauthenticate request from the client. for example codex has this bug (https://github.com/openai/codex/issues/20503). many servers solve this with some workarounds or increasing the token life. In v2 of mcp-use coming end of the month there should be a builtin way to deal with buggy clients so the server remains connected.
MCP is something people think of as a "panacea" to all AI issues. I think people are beginning to realize it is just one, albeit important, part of a successful AI architecture.
First of all, people have been saying this for a long time. It’s nothing new, at least half a year, maybe closer to a year.
Secondly, it’s not even that important, it’s the tool calling itself that’s important. MCP servers are just a convenient way to interact with remote services when a command line utility for the same would be inconvenient.
You may want to have a look at Skybridge, a TypeScript framework designed to build MCP servers and MCP Apps, with a recent emphasis on making authentication easy.
a few thoughts for MCP:
- typescript "runs" in the browser, which is very handy to develop browser side MCP Clients
- for similar reasons it is the only real option to develop UIs for MCP Apps for instance
not particularly related to MCP: as most products rely on external APIs provided by the labs (ChatGPT wrapper as we used to call them) frontend languages become more important
To me that’s a bit like saying I started using shell scripts and stopped calling APIs - skills are playbooks, mcps are ‘documented APIs’ for the ai to call.
Not for every situation. CLI is great for coding agents (and I'd agree, far better in most cases than MCP). But it requires some execution runtime somewhere to actually run. So for app use cases where you don't want to build out your own tools for every integration, MCP can be a solid option.
Also, in my opinion, it's much easier to build a good MCP interface than it is to build a good CLI interface - and afaik there's support for MCP tools to return things like images from an MCP tool call directly to the calling LLM that is a bit tricker to do via CLI.
I've been sitting in the same camp recently. We maintain both an internal MCP and CLI for our app which our devs use locally. The CLI so far feels like a much smoother experience both in terms of setup, control and performance.
But i can see how MCP being able to plug into a remote agent that doesn't have terminal access is very useful. Seems like it's a best tool for the job conversation or am I missing some other advantage?
There is definitely some debate going on on mcp/cli/api etc, but is quite obvious that mcp is being adopted as standard for integrating third party applications to the major clients => chatgpt apps, claude connectors, mistral, cursor etc.. they all connect to external apps using mcp. Of course it's possible for you to tell claude to use some cli directly but it's much easier to connect the mcp with one click
CLI certainly is better than local MCP. But nowadays, most MCPs are remote and the comparison fall short, at the notable exception of `gh` in a coding environment. But having CLI already authenticated is not guaranted either!
MCP makes a lot, lot more sense when you think of it as as a auth standard and not a comparison with CLIs. It obviously does more than just auth, but having standardised auth (which CLIs definitely do not) is the real 'killer' feature.
Yep, that was exactly my point with the ask to elaborate.
MCPs and CLIs feel like two wholly different things. Contrasting them feels even more confusing than comparing Skills vs MCPs, which would also be wrong in my personal view. Different runtime requirements, different access patterns, different distribution, different discoverability.
I agree with @martinanld that MCPs, especially with the advent of EMA, are a completely different beast thanks to a structured way for auth and access control.
I am so tired of people repeating this. Usually, this results from conflating two uses of MCP: local, which can indeed be replaced by CLI (and you can argue which one is better), and remote, which is entirely different, and there is no way to replace it with a CLI (note that you are making an implicit assumption that a CLI tool can be used at all, which is not always the case).
Please don't repeat this. It's like saying that apples are dead and oranges are the future.
> Tell me you don't understand what you're saying without telling me you don't understand what you're saying.
Please don't cross into personal attack, regardless of how wrong someone is or you feel they are.
Your comment would be fine without that last swipe, and even better if you had gone on to say what the two purposes are. Then we could learn something from it.
On your website under "Thousands of dev-teams are building with mcp-use" you include a quote from your CTO (@enri). If thousands of teams are using the product, I would think you could omit this post.
I think you have a really neat product here, but these types of testimonials do you more harm than good; they sour my opinion of all other testimonials on your site. I shouldn't have to play detective.
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.
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.
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?
pricing: we offer several credit based products that have different cost - requests, build minutes, eval runs, checklist all have different unit cost the breakdown is here https://docs.manufact.com/dashboard/billing thanks for pointing out that it should be more transparent!
auth: we published a few blogs https://manufact.com/blog/oauth-mcp https://manufact.com/blog/authentication
+ lots of auth templates you can start from https://manufact.com/templates
TLDR Claude does it today, Chat will probably start soon.
In my experience, they also work better with dumber models than CLIs (which saves money)
Any apps you can share that are on the OpenAI apps store / Claude store that are built / hosted 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?
Do you use MCP-handler for your MCP ?
also we ship templates for you to get started https://manufact.com/templates
Secondly, it’s not even that important, it’s the tool calling itself that’s important. MCP servers are just a convenient way to interact with remote services when a command line utility for the same would be inconvenient.
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.
I'd love for people with experience to break me of this negativity towards TypeScript. Anybody?
not particularly related to MCP: as most products rely on external APIs provided by the labs (ChatGPT wrapper as we used to call them) frontend languages become more important
Yes I can’t figure out exactly what it does…
- agents have old/inaccurate knowledge and it's nice to have up to date docs: https://awslabs.github.io/mcp/servers/aws-documentation-mcp-...
- geting agents to do apple builds and stuff is much easier with: https://github.com/getsentry/XcodeBuildMCP
- also for searching stuff like pdfs/epubs it's nice to have a place that's easy/fast for an agent to go to: https://github.com/nburns/doc-search-mcp
none of these strictly requrie mcp, but it is still a useful abstraction/shared convention
But i can see how MCP being able to plug into a remote agent that doesn't have terminal access is very useful. Seems like it's a best tool for the job conversation or am I missing some other advantage?
MCPs and CLIs feel like two wholly different things. Contrasting them feels even more confusing than comparing Skills vs MCPs, which would also be wrong in my personal view. Different runtime requirements, different access patterns, different distribution, different discoverability.
I agree with @martinanld that MCPs, especially with the advent of EMA, are a completely different beast thanks to a structured way for auth and access control.
Please don't repeat this. It's like saying that apples are dead and oranges are the future.
Edited*
Please don't cross into personal attack, regardless of how wrong someone is or you feel they are.
Your comment would be fine without that last swipe, and even better if you had gone on to say what the two purposes are. Then we could learn something from it.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
I think you have a really neat product here, but these types of testimonials do you more harm than good; they sour my opinion of all other testimonials on your site. I shouldn't have to play detective.