MCPs and the future of tool development

[TomLucidor]

Right now, everyone is hopping towards MCPs like Task Master and Basic Memory, and they are getting extremely popular since they are being turned into a universal adaptor of sorts. What do you think are the core limitations of MCP compared to classical rules files? eyaltoledano/claude-task-master#375 (reply in thread)

It's kind of a response to this #91 (comment)
Basic memory is an example of this, and we can see that PKM-compatibility is pretty useful https://github.com/basicmachines-co/basic-memory
There are other designs blending planning with memories https://github.com/vanzan01/cursor-memory-bank https://github.com/GreatScottyMac/roo-code-memory-bank https://github.com/GreatScottyMac/RooFlow

[MiaoDX]

@grapeot

Hi, what do you think of it?

Even cursor official is starting to support MCPs, so it seems promising?

[grapeot]

Appreciate the suggestion—MCP is quickly becoming the common “USB-C” for tool invocation, and Cursor’s native toggle makes it almost friction-free. Below is why we still keep .cursorrules MCP-free for now:

1 | Single-point vs multi-point configuration
Cursor 1.0 already lets users list mcpServers in one top-level settings file; that single switch is propagated to every chat and every rule. Duplicating the same list inside each rule file would create two sources of truth and dilute what a rule is meant to express—pure behavioural guidance in natural language.

2 | Why Basic Memory (Memory Bank) doesn’t need rule-level MCP hooks
The original Memory-Bank server’s goal was to template project memory into .md files via MCP. But this need is now natively handled: Memory has shipped as a built-in Cursor 1.0 feature. There’s no longer a need to run an external MCP server—or to declare it in each rule—to gain that capability.
MCP and rules remain complementary but distinct: the former distributes tool logic, the latter governs behavioural scaffolding. Blurring that line adds abstraction cost with little functional upside.

3 | Orthogonal goals: democratizing AI vs distributing tools
This repo’s goal is to lower the barrier to building agentic behaviors—no SDKs, no config, just Markdown and language. MCP, conversely, shines when you’re ready to ship a tool to others, across editors and models. The ceilings differ; so do the access patterns. Merging the two weakens both.

Further reading (for those curious)

• Article: Where MCP Fits – Why we see MCP more as a deployment protocol than a dev-time UX.
• My lightning course: The MCP Myth: Do You Really Need a Unified Agentic Protocol? – Includes demos, trade-off discussions, and practical usage patterns.

[TomLucidor]

What about A2A, are they redundant, or do we really need to combo A2A+MCP for best results?
To be more precise, is applying the "USB-C" to all tools a good idea?