[flagged]
If you need to give access to your CRM/ERP system from ChatGPT / Claude desktop for non-tech users, MCP is the way.
I build integration for DollarDeploy but it was tricky.
New MCP Roadmap
21–30 of 184 posts
Re: New MCP Roadmap
#22I am very curious how many MCP servers will actually implement all of this: "MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a st…
Such an example of overengineering, why not just use OAuth?
Oauth assumes interactivity
Re: New MCP Roadmap
#23[flagged]
I use Pi and I’m coming to the conclusion that mostly all I need is a bash tool.
Re: New MCP Roadmap
#24[flagged]
I’ll never understand the “I’ve never used it but am absolutely certain I would get zero value from it if I did” mentality.
I use MCP to accelerate CAD mould-making and for music production. I use it to avoid copying and pasting slack threads, and to let AI drive an eval system so I don’t have to manually configure things in a UI.
It’s just hard to imagine both not using it and being so sure it has no use.
Re: New MCP Roadmap
#25[flagged]
So I’ve been working on a personal finance app, and I added an MCP to it. Connected my Claude to it, mainly for testing purposes. The other day I was heading to Home Depot to buy some gardening stuff and I was asking some some questions around what I could plant at this time and still harvest before winter. It answers me, then brings up how my home improvement budget is nearing its limit for the month. I then ask it…
Is that really much different from building an API for your app though? Claude can use those just as easily.
Re: New MCP Roadmap
#26> With the 2026-07-28 release, a remote MCP server is now no different from any other HTTP workload Good. Introducing a bespoke new protocol was one of the more bone-headed things MCP did on initial release.
[dead]
Re: New MCP Roadmap
#27[flagged]
[dead]
Re: New MCP Roadmap
#28[flagged]
I'm very bullish on MCP (or at least MCP "like" implementations), as they solve a lot of problems for non-devs as they're much easier and safer to add into ChatGPT, Claude and other desktop + web apps.
They provide a set of tools and a context when to use those tools (much like a packaged version of a CLI+API and a skill) which makes them more discoverable than other options.
I've got a few folks using my open source data storage MCP - https://github.com/ExpeditedProjects/hutchdb - now and it makes a lot more sense than any other implementation for what they're doing
Re: New MCP Roadmap
#29[flagged]
Because you're a dev thinking for devs. No 60 year old is going to use Claude skills with the CLI. If my customers want their AI to interact with my product and MCP is the best way about it.
> If my customers want their AI to interact with my product and MCP is the best way about it.
Would be really interested to know how many of your customers actually use the MCP, who aren't already devs thinking like devs. I have doubts that many non-technical people are connecting AI to third-party services via MCP (or even using AI at all beyond "mundane" things like "generate an image of my cat as a clown" or "show me what my house looks like with blue paint and white trim").
Re: New MCP Roadmap
#30Earlier quoted context omitted.
So I’ve been working on a personal finance app, and I added an MCP to it. Connected my Claude to it, mainly for testing purposes. The other day I was heading to Home Depot to buy some gardening stuff and I was asking some some questions around what I could plant at this time and still harvest before winter. It answers me, then brings up how my home improvement budget is nearing its limit for the month. I then ask it…
Is that really much different from building an API for your app though? Claude can use those just as easily.
MCP is essentially just a convention for APIs that standardizes the concept of a “resource”. It spares the LLM a lot of work figuring out what the “things” are in a problem domain, and how various endpoints relate to those “things”.