Treat the tool surface as a product boundary, not a mirror of your backend. Keep the catalog small, return tools in deterministic order, and use sensible TTL values so clients can cache listings reliably. Once different tools require different scopes, per-tool authorization and routing become important operational controls, not optional refinements.
How should teams design an MCP server for external users?
An mcp server published beyond your own trust boundary should be treated like a product-facing integration surface, not a direct reflection of backend capability. The practical goal is to expose the smallest reliable tool set, keep discovery stable, and make authorization decisions at the tool boundary so external clients do not inherit broader access than the use case requires.
What should the tool catalog and discovery behaviour look like?
Start by designing the tool list as something clients can depend on operationally. A small catalog is easier to document, test, and govern, while deterministic ordering and sensible cache lifetimes reduce client churn and avoid brittle integration behaviour. The MCP authorization specification is a useful reference point for how the protocol expects servers to behave when authorization is part of the external interface, especially around OAuth 2.1 resource server handling and token-bound access decisions.
For external publication, discovery should feel stable even when the backend changes, because clients often cache listings and make routing decisions from them. That means tool names, descriptions, and response order should change deliberately, not casually, and the server should avoid exposing internal backend structure unless it is truly part of the supported contract. The Model Context Protocol: Authorization specification is a strong reference for building that boundary cleanly.
When do scopes and routing need to become per-tool controls?
Once tools have different privilege requirements, a single blanket token or shared upstream permission model stops being sufficient. At that point, each tool should be evaluated as its own authorization decision, because the client is no longer asking for access to “the server” in the abstract, it is asking for a specific action with a specific blast radius. That is also where routing becomes part of security design: requests must be steered to the correct tool implementation without accidentally broadening what a token can do.
For externally exposed MCP servers, this is the stage where token passthrough and confused-deputy behaviour become operational risks. The clean pattern is to align the tool surface with explicit authorization boundaries, then enforce them consistently at the gateway or application layer. MCP Security Guide and OWASP API Security Top 10 both help frame why broken authorization and overbroad access are the first failure modes to eliminate.
How should external publishing be governed in practice?
External MCP publication works best when security, platform, and product owners agree on what the server is allowed to be. If the goal is partner access, contractor access, or other third-party use, apply the same discipline you would use for external identities: sponsorship, time-bounded access, explicit least privilege, and clear offboarding. If the goal is broader ecosystem exposure, add a published contract for which tools exist, what each tool can do, and which scopes are required.
Practically, that means the team should define ownership for tool onboarding, review changes to the catalog as release-bound changes, and test authorization paths as part of deployment rather than as an afterthought. External MCP servers fail when teams treat the server like an internal convenience layer and then bolt on access control later. The Third-Party, B2B and Contractor Access Guide is useful for thinking about external-user governance, and the Model Context Protocol: Authorization specification provides the protocol-side model for making those decisions explicit.
Risk and Threat Considerations
Publishing an MCP server externally expands the attack surface immediately, because the server becomes a reachable tool broker rather than a private integration point. The main risks are overbroad authorization, tool confusion, and unintended access to backend capabilities that the external user was never meant to reach.
Failure mechanism: A shared catalog or shared token model lets one tool inherit permissions intended for another, or lets a client discover and invoke functions whose blast radius was never scoped for external use.
Impact: Attackers or misuse-prone clients can escalate from a low-risk integration into data exposure, unauthorized action, or backend abuse, especially when routing and authorization are not enforced at the individual tool level.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | External MCP tools need per-service authentication and scoped access control. |
| AC-6 — Least Privilege | External tool publication should minimize what each tool can do for a given user or client. | |
| Recommendation — Require service-level authentication and bind each tool route to a distinct access decision. Limit each published tool to the minimum permissions needed for its function. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Each MCP tool is a function boundary that can be overexposed if authorization is not per-tool. |
| API2 — Broken Authentication | External MCP servers depend on strong client authentication before any tool invocation. | |
| Recommendation — Enforce function-level authorization for every externally callable tool. Authenticate every external client before allowing tool discovery or execution. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | Publishing an external MCP server requires explicit identity and access governance. |
| Recommendation — Define and enforce access boundaries for external users, tools, and scopes. | ||
Practitioner Guidance
What to prioritise: Treat the first release as a security boundary exercise, not a feature-complete platform launch. Start with the smallest tool set that satisfies the external use case, then add tools only when you can explain the access boundary each one introduces.
What to verify: Confirm that tool listings are stable, that ordering does not vary across identical requests, and that each tool has an explicit authorization path. If a tool needs different privileges, verify that the server enforces that difference before the request reaches backend execution.
Common mistake: Publishing a broad server and assuming “the client will only call the right tools.” External users and external software do not reliably self-limit, so the server must enforce the limit.
Practitioner takeaway: The safest MCP publication model is one where discovery is predictable, tool scope is intentionally small, and authorization is decided per tool, not inherited from whatever backend the server happens to sit in front of.
Related resources from NHI Mgmt Group
- What do security teams need to verify before exposing an MCP server to users?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should organizations prioritize security in their MCP implementations?
- How should security teams govern MCP server authentication in production?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
