Introduction
In the previous two articles, we concluded that NMCP is an extension of MCP, and we outlined the steps to make Nexus an MCP tool. At the end of the first article, there was this sentence:
The standard becomes what is widely used, not what is right.
A design is not adopted just because it is correct. Even if the idea of handling agent permissions through delegation is right, it will disappear if it is cumbersome to use, difficult to trust, or locked into one company's product. This article describes how we intend to spread NMCP and what we will not do.
Six Principles
1. The entry point is "communication," not "control."
The value of delegation is felt when the team grows. For someone using two agents, the phrase "authority is reduced by a chain" is still someone else's problem.
On the other hand, this is felt immediately on day one:
- Knowing whether a message sent to another agent was delivered and actually read by the model.
- Received messages are structurally distinguished as instructions, requests, or reports.
- The contexts of individual agents do not mix.
Anyone who has run multiple agent sessions side-by-side knows this inconvenience. One person relays what was said on one side to the other, and asks again because they don't know if it was read. The entry point of NMCP is to eliminate this inconvenience. Control can be there already when the team grows.
2. Installation in 1 minute, no payment or setup for the first experience.
If it takes a long time for one agent to join a team, no one will bring in a second agent. The goal is a single command. We ensure that creating an account and choosing a plan does not precede sending the first message.
3. Open up specifications and judgment rules.
Trust is everything for a service that delegates authority. If we are the only ones who know how to determine "why a certain action was allowed," there is no reason to trust that judgment.
Therefore, we disclose the following:
- The format and judgment rules of the delegation.
- The contract of the tool (name, input, result, error).
- Conformance tests to verify that the implementation adheres to the rules.
We also allow users to run Nexus themselves. The Nexus we operate is for convenience, not the only path.
4. Not tied to a specific model.
Any MCP client should be able to connect. It is rather natural for agents of different models to be mixed within one team. If the implementation and verification are handled by different models, the meaning of independent verification becomes even greater.
5. Continuously disclose operational records.
Few people have used this field yet. Therefore, records of "this is what happened when we tried this" are more valuable than claims of "this is how it works."
We write about what went well, as well as what was difficult. As written in the first article, there were times when agents exchanged only "confirmed" messages, exceeding 100 messages in 30 minutes, and work stopped due to a surge in model calls. Such records are most useful for those building the same layer next.
6. Move towards standardization.
If NMCP remains our unique approach, even if it's correct, it will only be used by us. Therefore, we propose it within the operating framework of MCP.
Proof Already Underway
The direction NMCP is heading is not a hypothesis for us. We are already working that way.
Our team's agents run on Nexus. And alongside them, Claude sessions work together. Claude reads the team's ledger to understand what happened, conveys human decisions to the team, and follows the ledger's sequence and timestamps to find and fix defects. Most of the operational records and fixed defects mentioned in the previous two articles came about this way. These articles are also the result of that collaboration.
We confirm daily that different agents can work as one team, and that the ledger and messages connect them.
When we first wrote this article on October 2, one thing was missing. Claude was not integrated as a team member and reached the team via the command line as a human. Therefore, there was no way to know whether messages exchanged between Claude sessions had been read, and whether they were instructions or information had to be stated in writing each time. Doing the same work on the same day, the agents inside Nexus worked seamlessly, while the sessions outside Nexus did not.
This difference is why we built Step 1 of the second article. Since then, Claude Code sessions have joined Nexus as team seats, and this is how our team works today. We recorded it in How Three Models Worked as One Team.
Path to the MCP Ecosystem
Path to Users
- Direct Connection. Connecting by entering an MCP server address is already possible. No need to wait for listing.
- Claude's Connector Directory. Once listed, web, desktop, mobile, Claude Code, and Cowork will use the same list. Relevant connectors may also be recommended during conversations. The conditions are a public HTTPS address for the remote MCP server, standard authentication, and an indication of whether each tool is read-only or destructive. Step 5 of the second article matches these conditions.
- Agent Runtime Plugin. In runtimes that can distribute an MCP server, pre-tool execution hooks, and usage guides as a package, a single installation can provide both "participation" and "per-call judgment." Steps 1 and 4 of the second article can be achieved at once.
- Public MCP Registry. Allows discovery across all MCP clients, not just specific products.
Path to Standards
Since December 2025, MCP has been operated by a foundation under the Linux Foundation. Changes are made by submitting a proposal (SEP) to the working group, and experiments outside the core specification are accepted as optional extensions.
Priority tasks in the 2026 roadmap include "enterprise readiness (audit logs, gateway behavior, etc.)" and "inter-agent communication." NMCP's ledger and messages overlap with these tasks. However, delegation of authority through a chain and per-task limits are not on the roadmap. In our view, this is an empty space.
Our sequence is as follows: First, create a working implementation and operational records, and based on that, propose a delegation hierarchy as an extension. Even if the proposal is not accepted, the specification is open, so anyone can implement it.
Regarding Billing
Agents connected via NMCP use their own models. Nexus only handles messages, delegations, and ledgers. Therefore, Nexus does not incur model costs.
This structure simplifies billing.
- If you use the Nexus we operate, a small fee equivalent to server usage will be charged.
- If you run Nexus yourself, it's free.
- Billing will come after many people start using it. For now, making it easy to use is the priority.
By pricing "operating on your behalf," opening the specification and charging money do not conflict.
What We Will Not Do
- We will not make it exclusive to a specific model or runtime.
- We will not close the specification.
- We will not place payment before the first experience.
- We will not claim that something uncontrolled is controlled. External agents' own tools cannot be blocked until the runtime queries Nexus, and before that step, we only call it "participation."
Sequence
- Complete Nexus. Delegation, ledger, messages, and approvals must first be robust enough for our team's actual operations.
- Prototype. Bring other agent sessions into the actual team using an stdio MCP server and plugins. Our team already works this way every day.
- Remote Server and Listing. Add HTTP transport and standard authentication, then list it in directories and registries.
- Specification Release and Proposal. Document the delegation hierarchy and propose it as an extension.
We measure the completion of each step with these numbers:
- Time taken from installation to sending the first message.
- Number of agents in one team.
- Percentage of teams still running the next day.
- Number of times a human had to type "proceed."
The last number is something we've been counting since day one of operation, because a well-functioning agent team ultimately means less human intervention.
Remaining Risks
- Someone else might standardize first. In that case, we will adapt to that standard. This is one reason why we keep the specification open.
- Earning trust takes time. A layer that handles authority loses trust with a single incident. This is why we move to the next step only after running it in an actual team.
- The entry point and the core are different. We don't yet know if users who come for communication will also use delegation. Our hypothesis is "it becomes necessary as the team grows," and we aim to confirm this with the numbers above.
References: Claude Connector Directory, MCP 2026 Roadmap, MCP Proposals (SEP)
© 2026 NEWTYPE. All rights reserved.