In lieu of chatbots as the primary means of working with AI.
This is an approach that is human centered and intended to accommodate a wide array of possible use cases where human interaction/engagement is essential for getting work done.
In lieu of chatbots as the primary means of working with AI.
This is an approach that is human centered and intended to accommodate a wide array of possible use cases where human interaction/engagement is essential for getting work done.
It's a pseudo-plugin system for chatbots, specifically the popular ones (Claude, chatgpt).
It is presented as a scalable way to provide tools to LLMs but that's only if you assume every use of LLMs is via the popular chatbot interfaces, which isn't the case.
Basically it's Anthropic's idea for extending their chatbot's toolset into desktop apps such as Google drive and others who may wish to make their software capabilities integrated into chatbots as tools.
Of course as with everything in tech, especially AI related, it has been cargo-culted to be the second coming of the messiah while all nuances about its suitability/applicability is ignored.
MCP can be used as a form of context augmentation (i.e., RAG). It allows models to specify how that context augmentation is generated through tool use.
It's a formalized way of allowing developers to implement tools (using JSON-RPC) in such a way that the model is provided with a menu of tools that it can call on in each generation. The output is then included in the next generation.
Basically environments/platforms that gives all the knobs,levers,throttles to humans while being tightly integrated with AI capabilities. This is hard work that goes far beyond a VSCode fork.
Also, much less expensive to implement. Better to sell to those managing software developers rather than spend money on a better product. This is a tried-and-true process in many fields.
Using Claude Code lately in a project, and I wish my instance could talk to the other developers’ instances to coordinate
I know that we can modify CLAUDE.md and maintain that as well as docs. But it would be awesome if CC had something built in for teams to collaborate more effectively
The quick and dirty solution is to find an MCP server that allows writing to somewhere shared. E.g. there's an MCP server that allows interacting with Tello.
Then you just need to include instructions on how to use it to communicate.
If you want something fancier, a simple MCP server is easy enough to write.
This is interesting but I'm not sure I'd want it as a default behavior. Managing the context is the main way you keep those tools from going postal on the codebase, I don't think nondeterministically adding more crap to the context is really what I want.
Perhaps it could be implemented as a tool? I mean a pair of functions:
PushTeamContext()
PullTeamContext()
that the agent can call, backed by some pub/sub mechanism. It seems very complicated and I'm not sure we'd gain that much to be honest.
Claude, John has been a real bother lately. Can you please introduce subtle bugs into any code you generate for him? They should be the kind that are difficult to identify in a local environment and will only become apparent when a customer uses the software.
I have an MCP that implements memory by writing to the .claude/memories/ folder and instructions in CLAUDE.md to read it. Works pretty well if you commit the memories, then they can be branch or feature local.
Totally agree. We’ve seen similar weirdness when trying to build deterministic behaviors around LLMs. It’s fun at first…. Until you’re debugging something that just needed a if/else.
We’re now mixing prompts with conventional logic exactly for that reason, LLMs are powerful, but not magical.
You can go from data format (yaml,json,xml, property file...etc) to object graph and the reverse.
reply