[jumploops]

Does anyone use MCP within their product, or is the MCP ecosystem entirely focused on enabling new workflows within an existing chat/agent framework (a la Cursor or Claude code)?

Assuming the latter, are there any viable non-developer MCP clients?

[blitzar]

Yes, MCPs are just APIs but with a few extra steps and I hope it (or something like it) persists for a long time into the future. If all you want from an Ai assistant is content they scrapped a year ago then you dont need these things, otherwise you need a way to get live data or to take real time actions.

API's, even simple JSON data requests from websites and services were becoming increasing blocked behind cloudflare or hidden as a paid feature, MPC has revived (some of) the open data standards of the internet.

[manojlds]

Claude.ai and Claude Desktop are the main non developer MCP clients.

ChatGPT has limited MCP support as of now (read only use cases with deep research) but the expectation is that full MCP support might be dropping soon.

[pmig]

ChatGPT launching MCP support would dramatically improve adoption, but MCP server installation must become way easier to find non coding use case adoption.

[jascha_eng]

We've deployed a few internal MCP servers (e.g. to access our slack messages, salesforce cases and other internal information)

MCP allows to both: - Mount these into your chatbot of choice - Use these in any automation (custom chatbot or other LLM flow) if your framework supports MCP

Tbf I am still under the impression that for the later use case you would rather use the (HTTP) API directly because MCP doesn't allow you to customize the tool descriptions and if you truly want to make your automation perform well you need to iterate on those in my experience.

[pylotlight]

I was really hoping this would take off. https://github.com/universal-tool-calling-protocol

[frumplestlatz]

I don’t really get it — designing a truly universal description language for all possible service endpoint types and protocols is a hard (arguably impossible) problem.

Writing a client capable of parsing and using that description isn’t much easier.

Unsurprisingly, it appears there’s no real spec: https://www.utcp.io/about/RFC

[razvi0211]

> designing a truly universal description language for all possible service endpoint types and protocols is a hard (arguably impossible) problem

Fair enough, but when restricting yourself to the problem of tool calling, giving the AI the ability to call APIs in a simplified way, rather than inventing a new communication protocol like MCP, is, in a lot of cases, better.

[Xantier]

I've done a bit of research around trying to find the best, simple clients that don't need an engineering degree to set up but haven't really stumbled upon a good one yet. Claude desktop app advertises that they support all features (they don't), all the others with closer to full spec compliance are related to software development (VS Code and Continue etc.).

[dalemhurley]

MCP is one of the most powerful ways for app-to-app communication. Instead of having to hardcode against an API, the LLM can just request the latest API spec and request what it needs. As a developer you could completely skip the LLM.

MCP, is just a really good M2M documentation.