MCP vs NMCP, Which is Superior?

Introduction

There are questions that don't need to be asked when using only one agent. When multiple agents start delegating tasks to each other, those questions become everything.

On whose behalf, and to what extent, can this agent act?

To answer this question, we built Nexus, and the method of layering it on top of MCP is called NMCP (Nexus + MCP). Therefore, a frequently asked question is "Which is superior, MCP or NMCP?"

To state the conclusion first, the two do not compete. NMCP is an extension of MCP. However, the process of reaching that conclusion is important, so we will describe what each method does and does not do, in order.

What MCP Does

MCP (Model Context Protocol) is an open standard for how applications using models connect to external tools and data. As of the 2026-07-28 revision, it can be summarized as follows:

• Host, client, and server communicate with JSON-RPC 2.0 messages.
• The server provides tools (functions executed by the model), resources (context and data), and prompts (structured messages).
• The client can accept requests (elicitation) from the server asking the user for additional information.
• Features like long-running tasks are attached as optional extensions.

Thanks to this standard, once a tool is created as an MCP server, it can be used by any client. MCP has played a significant role in the current expansion of the agent ecosystem.

What MCP Does Not Do

The MCP specification is explicit about permissions.

• Authentication is optional and a matter of the transport layer. For HTTP transport, it follows OAuth 2.1, and for stdio transport, it retrieves credentials from the environment.
• Authentication deals with "what scope this client can access on this MCP server."
• Obtaining user consent before executing a tool is the responsibility of the host application.
• And the specification states: "MCP itself cannot enforce these security principles at the protocol level." Therefore, it recommends that implementers create consent and authorization flows.

This is not a flaw but a choice of scope. MCP standardized connections, and left decisions after connection to each implementation.

The problem arises when there are multiple agents. MCP does not provide answers to the following questions:

1. Delegation: When Agent A delegates a task to Agent B, can it only transfer a portion of its authority? What if B delegates to C?
2. Per-call judgment: Is being connected to the server the same as being allowed to call this tool for this specific task?
3. Limits: How many model tokens and how much execution time can be used for this task? Who increases it?
4. Accountability: Can we later see "who did what, with whose authority" in sequence?
5. Inter-agent communication: Is a message sent by another agent an instruction, a request, or a report?

What NMCP Adds

At the heart of Nexus is a delegation. A delegation is a record that states "who delegated what task, with what scope, policy, and limits, to whom," signed and sealed by the server.

• Permissions decrease down the chain. Delegation forms a chain, and every link in the chain must allow any action. A subordinate agent can only add restrictions and cannot increase permissions.
• Judgment is made per call. Each time a tool is called, Nexus responds with allow, ask, or deny, based on the delegation. The server, not the model, enforces this. Even if the model misunderstands the delegation, the server will deny it.
• Only humans can broaden permissions. Actions not covered by the delegation request approval from a human. A human can grant permission once, for the duration of that session, and can revoke it at any time.
• Limits are attached to the delegation. Model tokens, execution time, number of sub-sessions. If these run out, the task waits for human approval instead of failing.
• Everything is recorded in the ledger. Turns, tool calls, approvals, and messages are recorded with sequence numbers per session.
• Secrets are handled by name only. The model writes secret://NAME, and the value is injected only at the moment the command is executed. Only the name remains in the ledger.
• Relationships are attached to inter-agent messages. Is it an instruction from the delegator, a request from a colleague, a report from the delegate, and which task of the recipient is it related to? The sender knows if it was delivered and if the model actually read it.

Side-by-Side Comparison

In Practice

We formed a team of four or five agents and operated for a day. The administrator role received and distributed human decisions, the implementation lead built, and the verification lead independently confirmed. Humans only made decisions.

Two things stood out:

• Context was not mixed. Each agent had its own conversation and its own ledger, and received others' work only through messages marked with relationships and tasks. The ledger consistently showed agents distinguishing between "report from the person in charge" and "what I confirmed directly."
• It was easy to fix. Several defects emerged that day, most of which were found by following the sequence numbers and timestamps in the ledger, rather than by guesswork. What was not seen because it wasn't in the ledger, such as where "the model did not respond" and "the human canceled" could not be distinguished, became the next task.

We also note what was hard. There was a time when agents exchanged over 100 "confirmed" messages in 30 minutes. If model calls were concentrated, they failed, and that failure stopped the task. Such problems arose at a layer completely absent in MCP, and anyone creating a delegation layer will experience them.

So, Which is Superior?

In situations where multiple agents work on behalf of a human, NMCP is superior. This is because it includes everything MCP does and answers the five questions that MCP does not. We believe that as the number of agents increases, handling permissions in a delegated format will become a necessity, not an option.

However, "superior" does not mean "replaces."

• MCP is an open standard, validated by many users. NMCP has only been run by our team so far.
• There are already countless MCP servers. There is no reason to abandon those tools and create new ones.
• A standard becomes what is widely used, not necessarily what is "right."

Therefore, our conclusion is extension. NMCP is not an alternative to MCP, but a delegation layer built on top of MCP. Specifically, it does three things:

1. It exposes Nexus tools as MCP servers, allowing any MCP client to work under a delegation.
2. When an agent uses a tool from an external MCP server, each call goes through the judgment of the delegation.
3. It documents the format and judgment rules of the delegation as an open specification.

This way, all tools in the MCP ecosystem can be used as is, while adding "on whose behalf, and to what extent" which is not present in MCP.

The next article will describe step-by-step how to make Nexus an MCP tool (point 1 above).

---

The MCP description in this article is based on the 2026-07-28 revised specification.

Note: MCP Specification, MCP Authentication

© 2026 NEWTYPE. All rights reserved.