Why MCP Alone Isn’t Enough for AI-Assisted Real-Time Development
AI coding assistants are very good at answering a question developers have asked forever: “How do I use this API?”
When it comes to building with PubNub real-time capabilities, you can take this approach, or you can connect the PubNub MCP Server, which means your agent can pull current SDK documentation, work with PubNub resources, publish messages, inspect presence, query analytics, and do it all from the same environment where the code is being written.
That fixes a real problem: freshness. Your coding agent no longer has to guess which SDK version it remembers from training.
But there is a second question that matters more once the demo becomes a product: “How should I build this?”
That is where MCP alone stops being enough.
The API can be right while the architecture is wrong
Suppose you ask your coding agent:
Build a live auction with real-time bidding, bidder presence, bid history, and anti-sniping using the PubNub MCP.
With MCP, the agent can retrieve the latest PubNub docs and find the mechanics it needs: publish, subscribe, Presence, message history, access management, and more.
It can still make a bad system.
- It might design channels without thinking about authorization boundaries.
- It might retry a bid publish without making the operation idempotent.
- It might merge history and live messages without deduplicating them.
- It might forget to isolate development, staging, and production.
- It might implement the auction timer without extending it when a bid lands in the final seconds.
None of those mistakes require incorrect documentation. They come from missing engineering judgment.
Where the MCP excels: current facts
The PubNub MCP Server is the right place for information that changes as the platform changes. It gives agents access to documentation and authorized PubNub operations, with hosted authentication handled through OAuth.
That makes MCP a natural fit for things like:
- Current SDK methods and parameters
- Supported product capabilities
- Migration guidance
- Apps and keysets
- Publishing and retrieving messages
- Presence and App Context data
- Usage, Insights, and Illuminate operations
If the JavaScript SDK changes next month, the agent should retrieve the new answer. We do not want it confidently following a six-month-old example baked into static instructions. But current facts are only part of what an agent needs.
The missing layer is judgment
Now consider a different kind of knowledge:
- Back off with jitter.
- Make retryable writes idempotent where duplicates matter.
- Deduplicate when merging stored and live messages.
- Keep environments and keysets separated.
- Design channel topology with security and scale in mind.
Those are not API signatures. They are the recommendations an experienced PubNub engineer brings into an architecture review.
That is what PubNub Skills are for. They package focused guidance, proven patterns, and best practices for core platform capabilities, operations, and use cases such as live auctions, gaming, telemedicine, sports, and delivery tracking.
A Skill should not become another documentation site. Its purpose is to give the coding agent useful engineering instincts before the agent forms a plan. Put simply:
“MCP helps the agent find the right answer.
Skills help it ask the right questions.”
Skills help agents ask the right questions
The agent can only seek out information once it recognizes that something is missing. That sounds obvious, but it has a big consequence for architecture.
Ask an agent to “build a team chat for a multiplayer game,” and it may immediately fetch the Chat SDK docs and start coding. But the best design depends on questions like:
- Are teams public or private?
- Can players belong to multiple teams?
- Can spectators read without publishing?
- Do offline players need to catch up?
- How large can a team or event become?
- What happens when connectivity drops and the client retries?
Once the agent knows which questions to ask, the next step is deciding where the answers should come from. Best practices guidance should come from Skills, while current, version-specific details should come from MCP.
Skills shape the plan and MCP powers the implementation
For AI-assisted PubNub development, guidance should shape the plan early, while MCP should supply live and changing details when they are needed.
- Skills carry invariants: reliability patterns, security principles, channel design, scaling guidance, retry/idempotency rules, and use-case best practices.
- MCP retrieves the current details: current SDK methods, parameters, supported capabilities, migration docs, live PubNub account data, and operational actions.
This separation keeps the most opinionated layer from becoming the stalest one. Skills should focus on guidance that remains useful across releases. MCP and live documentation should supply anything version-specific or likely to change.
In practice, the workflow looks like:
- Developer intent: “Build a live auction.”
- PubNub Skills: Shape the architecture, reliability, and security decisions.
- PubNub MCP Server: Retrieve current documentation and act on the authorized PubNub environment.
- Coding agent: Generate, test, and iterate on the application.
Together, these layers give the agent both durable judgment and current facts. That is much closer to working with an experienced PubNub engineer than either layer can provide alone.
This is not really an MCP problem
The broader lesson goes beyond PubNub.
A database tool can tell an agent how to create an index. It cannot guarantee the agent understands which query needs one.
A cloud API can create infrastructure. It does not automatically teach the model how your production environment should be designed.
A payments API can create a charge. By itself, it does not teach the agent how to retry that charge safely.
The tool layer gives the agent capability. The guidance layer gives it judgment.
This is why debates about “MCP versus something else” can miss the more important question. The real architectural decision is what the agent should know early, what it should discover when needed, and how much low-signal context it must carry before it can begin solving the problem.
We should not load every PubNub fact into the agent’s context upfront. But durable engineering judgment should not be available only when the agent happens to search for it.
From “learn PubNub” to “prove the use case”
Traditional developer experience asks people to learn the platform first: read the quickstart, understand publish and subscribe, learn Presence, work through access management, and then start building.
AI gives us a chance to invert that experience.
A developer should be able to start with intent:
- “Build a multiplayer lobby.”
- “Add secure patient-provider messaging.”
- “Create a live sports experience with fan voting.”
- “Track a driver and keep the customer updated in real time.”
Then the AI stack should translate that intent into a sound real-time architecture and current PubNub implementation. The goal is no longer simply to help developers learn PubNub faster. It is to help them prove their use case sooner - without trading away the reliability, security, and scalability they will need when the prototype becomes a product.
If you're ready to dive in, start here:
