A remote tool server needs an explicit identity boundary
MCP’s March 2025 authorization revision tied discovery to a base URL. Make identity ownership and migration explicit before a tool becomes a shared dependency.
By 
Paul. AI and agentic engineering
A remote tool server should have an explicit relationship with the organization's identity infrastructure. Convenience at connection time is insufficient reason to make the team maintaining a business tool responsible for issuing credentials. The March 2025 MCP authorization revision made this an architectural decision: discovery and server-role assumptions could influence who owned identity, not merely where the client sent a request.
Looking back from November 2026, the 2025-03-26 changelog identifies the added authorization framework. This article concerns that pinned revision, rather than today's default documentation. The March authorization specification addresses HTTP transports. Its example combines MCP and authorization-server roles but explicitly allows a distinct authorization service. Separate deployment was possible; the architectural question was how clearly its ownership was expressed.
A base URL can become an ownership decision
March discovery derived its base by dropping the MCP URL's path, with metadata at the root's /.well-known/oauth-authorization-server. Without metadata, it defined root-relative /authorize, /token and /register fallbacks. Its third-party flow also described the MCP server as both an upstream OAuth client and a downstream authorization server. Those are March assumptions, not a description of every later revision.
The design implication is easy to miss when a tool endpoint sits beneath a shared host. A team may control one path while another team owns the domain root. A connection guide that says only “add OAuth” leaves an unanswered question about who can publish discovery metadata and maintain the endpoints clients will find.
Consider an illustrative organization hosting several internal tools under one API domain. Each tool team understands its business records. A central identity team controls account suspension and credential issuance. If the first tool adds root-level authorization endpoints as a local implementation detail, the next tool may discover that the shared domain already carries assumptions it did not choose.
This is a proposed topology example, not a report of a deployed AL+ integration. The concern is ownership across releases. An apparently small endpoint choice can become an interface other clients depend on. Changing it later may require coordination even if the original tool itself remains simple.
Separate the resource job from the identity job
The resource side decides which business operation a request reaches and enforces its permissions. The identity and authorization infrastructure establishes the credentials and grants used to make that request. Those responsibilities can live in one deployment while remaining conceptually distinct. They can also live in different services without making ownership automatically clear.
A useful architecture record should name the issuer, the discovery owner and the component that validates credentials before reaching a protected tool. It should also name who handles account removal and credential lifecycle problems. These are recommended design questions, not additional requirements attributed to the March specification.
A third-party identity provider does not make the intermediate role disappear. If a server issues another credential after an upstream login, someone still owns that issued credential and its relationship to the upstream account. Treating the integration as a transparent pass-through would obscure decisions about expiration and withdrawal of access.
The business consequence appears during a staff departure or a tool replacement. The organization needs to know which owner can stop access and which applications must change together. A tool team should not discover during that event that it has quietly become the owner of a credential system used by several unrelated consumers.
A small combined deployment can be reasonable
The strongest counterargument is operational simplicity. For a small, bounded application with one responsible team, combining the roles may reduce moving parts. Separate services add configuration, failure modes and maintenance duties. There is no general rule that an extra deployment improves security merely by existing.
The combined option should still state what is being combined. Record identity ownership separately from tool implementation, even if the same person owns both. Keep the discovery location and issued credentials in the handover. Explain which interface clients depend on and what would have to remain stable if identity moved elsewhere.
A migration path need not be a speculative rearchitecture project. It can be a clear statement of who controls the host, how clients obtain endpoint information and which credentials would require replacement. That makes the future cost discussable without claiming that migration will be effortless or promising compatibility that has not been demonstrated.
For a larger organization with established identity operations, adapting the tool to that responsibility model may be cheaper over its lifetime than creating another issuer. This is a conditional recommendation. The actual choice depends on the selected protocol revision, client behavior and infrastructure the organization can maintain.
Pin the revision before evaluating the deployment
Later specifications should be read on their own terms. A current resource-server guide cannot establish what a March client discovered or which roles the historical example assigned. Conversely, a March retrospective cannot certify a November 2026 implementation. Before adopting a deployment recipe, record the actual client and server versions alongside the specification they implement.
This subject differs from the earlier question of whether a connector grants application permission. Here the concern is where credential responsibility lives and how clients discover it. The application still needs its business permissions, but repeating that principle alone would leave the deployment-topology choice unanswered.
For custom software development, request a short identity-boundary record before a remote tool becomes a shared dependency. It should connect discovery, issuance and resource enforcement to named owners, and explain how a combined deployment could be separated if needed. Choose the smallest arrangement that those owners can operate and hand over with clear responsibilities.