{"slug": "mcp-scopes-are-trust-boundaries-not-settings", "title": "MCP Scopes Are Trust Boundaries, Not Settings", "summary": "A developer warns that MCP scopes in APC/APX are trust boundaries, not settings, and misusing them leads to conflicts and fragile onboarding. The three scopes—runtime, shared, and global—each serve distinct purposes: runtime for secrets, shared for portable project config, and global for machine-wide tools. The developer advises picking one scope per server to maintain clarity and portability.", "body_md": "The easiest way to misuse MCP in APC/APX is to treat scope like UI decoration. It is not. Scope decides where the trust boundary lives.\n\nAPX exposes three MCP scopes in its UI: runtime, shared, and global. The names are simple, but they describe different ownership rules:\n\n`~/.apx/projects/<id>/mcps.json`\n\n`.apc/mcps.json`\n\n`~/.apx/mcps.json`\n\nThat split is the point. Each scope answers a different question.\n\nRuntime scope is for MCP config that depends on the machine or the current operator. If a server needs headers, tokens, or any credential that should not travel in git, runtime is the right home.\n\nThis scope should not carry project meaning. It is not portable by design. That is a feature, not a flaw. If the config is safe to lose with a machine reset, runtime is enough.\n\nShared scope is the one APC can carry.\n\nIf an MCP server belongs to the repo and does not need secrets, it should live in `.apc/mcps.json`\n\n. That makes the choice visible in code review, clone-safe, and tool-neutral. Another runtime can read the same project contract without rebuilding it from memory.\n\nThis is the scope that keeps APC useful. The repo says, \"we expect this tool here.\" It does not say, \"this laptop happened to be configured once.\"\n\nGlobal scope is useful, but easy to overuse. It is for helpers that make sense across many repos on one machine. Think of a local utility server or a universal tool you want available everywhere.\n\nThe risk is subtle: once something becomes global, it can hide missing project context. A repo may appear to work because your machine has a default, while the repo itself carries no portable intent. That makes onboarding fragile.\n\nOne more detail matters: scope and transport are different decisions. Transport says how the server connects, such as `stdio`\n\nor `HTTP`\n\n. Scope says who owns the configuration and where it lives.\n\nMix those up and the model gets fuzzy fast. Keep them separate and the system stays legible.\n\nA quick test usually works:\n\nIf you need to think longer than that, the answer is probably shared versus runtime. Ask one more question: \"Would I want this exact choice to survive a clone?\" If yes, keep it in APC. If no, keep it in APX.\n\nThe worst pattern is putting the same MCP server in all three places.\n\nThen you get conflicts, hidden precedence, and mystery behavior. APX already hints at that in the UI by showing conflicts. That warning matters. It means the machine can merge views, but you still need a clear source of truth.\n\nPick one scope. Keep one owner. Let the others stay empty unless they truly add value.\n\nMCP scopes are not preferences. They are boundaries.\n\nRuntime protects secrets. Shared preserves project meaning. Global serves machine convenience. When you map each MCP to the right scope, APC stays portable and APX stays predictable.", "url": "https://wpnews.pro/news/mcp-scopes-are-trust-boundaries-not-settings", "canonical_source": "https://dev.to/agentprojectcontext/mcp-scopes-are-trust-boundaries-not-settings-2i18", "published_at": "2026-06-17 12:03:51+00:00", "updated_at": "2026-06-17 12:21:39.849127+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["APC", "APX", "MCP"], "alternates": {"html": "https://wpnews.pro/news/mcp-scopes-are-trust-boundaries-not-settings", "markdown": "https://wpnews.pro/news/mcp-scopes-are-trust-boundaries-not-settings.md", "text": "https://wpnews.pro/news/mcp-scopes-are-trust-boundaries-not-settings.txt", "jsonld": "https://wpnews.pro/news/mcp-scopes-are-trust-boundaries-not-settings.jsonld"}}