Most Model Context Protocol (MCP) servers you can connect to today are organised around a single resource: the GitHub server is built around repositories, the Slack server around channel messaging, the PostgreSQL server around your database. That's just how the ecosystem developed — one service, one server. And whether you're connecting existing servers or building your own, that pattern tends to carry forward without much thought.
For simple setups, that's fine. But as workflows grow more complex — or AI agents start doing real work in them — the structure of your servers starts to matter more than you'd expect. This post makes the case for a different approach: organise your servers around who uses them and what they need to do, not just what data they expose.
Before diving in: an MCP server is what gives an AI agent access to a specific tool or data source — your database, your GitHub repositories, your Slack workspace. Resource-based organisation means each server is built around one service. It's the most common pattern in the ecosystem today, and for a lot of setups it works fine. This post is about when it doesn't — and what to do instead.
TL;DR: Resource-based vs workflow-scoped MCP servers
- Resource-based breaks down when the resource boundary doesn't match the consumer boundary — connection overhead, access control gaps, and automated agent risk all compound from the same root cause.
- Workflow-scoped servers flip the question: organise around who uses the server and what they need, not what data it exposes. This is the principle of least privilege at the server level.
- We recommend workflow-scoped for internal setups. For external or customer-facing ones, it depends on how customers use the tools.
- MCP Express makes this practical: mix tools from any integration on one server, filter to only the tools you need, and apply RBAC within the server.
The Default Pattern — and Why It Feels Right
In practice, when you need a new integration, you find the server you need, connect it, and move on. The resource-based structure is inherited from the ecosystem, not designed by you. For a solo developer running a focused workflow, that's fine — the overhead is low, the setup is fast, and each server does exactly one thing.
The temptation is to carry that same pattern forward when you start composing multiple servers together. You already have a GitHub MCP server and a PostgreSQL MCP server — it feels natural to add a Sentry server, a Slack server, and keep building outward the same way. The problem isn't that this is wrong; it's that it starts making structural decisions you didn't consciously choose.
The resource-based structure in your setup is likely inherited from the ecosystem — not a decision you made. Most available MCP servers are built around a single service, so connecting them is the path of least resistance.
Where Resource-Based Starts to Break Down
The core problem is that resource-based organisation draws a boundary around the resource — but the boundary that actually matters is around the consumer. When those two don't line up, the same structural issue shows up in different shapes:
- In a team setting — a support agent, a backend developer, and a data analyst all end up on the same database MCP server. They need fundamentally different things from it, but the server doesn't distinguish between them. Everyone gets the same tools, and access control becomes something you patch in afterwards.
- Across multiple clients — a single PostgreSQL server covering several clients' databases creates a resource boundary that cuts right across your client boundaries. The server doesn't know the difference between client A and client B, so anyone connecting has potential visibility across all of it.
- With automated agents — an agent running on a trigger reasons over every tool available to it. Load it onto a broad resource-based server and its behaviour becomes harder to predict, harder to debug, and easier to exploit if something goes wrong.
There's also a practical overhead problem: when an agent needs to work across multiple resources, resource-based organisation means connecting it to multiple separate servers — each with its own configuration and auth flow. For a single focused task that touches three or four resources, that overhead compounds quickly — and it's entirely structural, not a reflection of how complex the task actually is.
In each case the fix is the same: draw the server boundary around the consumer, not the resource.
The Workflow-Scoped Alternative
Workflow-scoped organisation flips the design question. Instead of asking "what does this server expose?" you ask "who uses this server, and what do they actually need?"
A support server might include: Jira read access, Slack, and read-only access to customer records. Nothing else — no write operations, no deployment hooks, no analytics tables the support team has no business touching.
A developer server might include: GitHub, CI/CD pipeline tools, database write access to specific tables, and deployment tooling. Full access for the job, scoped to what the job requires.
Each server is purpose-built. Access control is structural — it's in the design, not layered on top. You can't accidentally give the support team write access to the database, because the support server doesn't have it. This is the principle of least privilege applied at the server level: every consumer gets exactly what they need for their work, and nothing more.
Roles within a server — Workflow-scoped servers don't mean one-size-fits-all within a server. MCP Express's Role-Based Access Control (RBAC) lets you define roles inside a single server — a developer server can have a senior dev role with broader permissions and a junior dev role with read-only access to production. Same server, different access levels, no extra infrastructure.
Resource-Based MCP vs. Workflow-Scoped MCP ServersThe Honest Trade-off
Resource-based is the natural outcome of running an existing MCP server as-is. If you're connecting a community-maintained PostgreSQL MCP server, it comes scoped to your database. That's fine.
Workflow-scoped requires upfront thinking: who are the consumers of this server, what tools do they need, and what should they never have access to? For internal teams — a support team, a dev team, a data team — the boundaries are clear and the structure maps naturally to how people already work.
If you're offering MCP as a service to other businesses, the answer is less clear-cut. The right pattern depends entirely on what your service does and how your target customers work. A database solution provider, for example, might find that resource-based organisation maps exactly to how their customers think about the product. There's no universal answer there — it depends on the service.
Resource-based is what happens by default. Workflow-scoped is a design decision. The difference is whether your server structure reflects how work actually gets done — or just what tools happen to exist.
The Per-Project Variant
The same principle applies outside team contexts. For anyone managing work across multiple separate projects, workflow-scoped organisation maps cleanly to a per-project server model: each project gets its own server with only the tools relevant to that project — its database, its CMS, its repository.
This keeps context clean. When you're working on a project, the AI has exactly the tools it needs for that project — nothing bleed-over from another. It also keeps access clean: collaborators or external contributors connect to one server that has exactly what they need, with no visibility into other projects. No multiple connections to manage, no confusion about which server does what.
Role-Based Access Control (RBAC) within that server can then go further — restricting what a contractor sees versus what a core team member can do, without spinning up a separate server for every permission level.
The Automated Agent Safety Case
That same principle of least privilege applies even more forcefully when automated agents are the consumers. A human using a broad-access server can exercise judgment — they can see a tool exists and decide not to use it. An automated agent running on a trigger can't do that. It reasons over everything available to it, and what you give it shapes what it does.
There's also the blast radius problem. If an agent misbehaves — whether through a bug, an edge case, or a prompt injection attack — a workflow-scoped server limits how much damage it can do. A resource-based server with broad access is a much larger blast radius. The tools you expose are the tools that can be misused.
This extends naturally to agent-specific roles — a "reporting agent" server, a "triage agent" server — designed not around a human job function but around an AI task boundary. Same principle, different consumer.
What This Looks Like in MCP Express
MCP Express makes workflow-scoped organisation practical rather than theoretical. A few things that matter here:
First, you can mix tools from any combination of integrations on a single server — official integrations (PostgreSQL, GitHub, Slack, Jira, and others) alongside custom upstream MCP servers. A support server can pull from Jira, Slack, and a read-only database view without any of them needing to be on separate servers. And when you add an official integration, you're not forced to expose its full toolset — you can select only the tools that are safe and relevant for that server's purpose, leaving the rest out entirely. The Feature Deep Dive on integrations covers this in detail.
Second, RBAC works at the server level. You define roles, assign tool permissions per role, and the access control is structural rather than managed separately. The Feature Deep Dive on Role-Based Access Control covers the mechanics.
The combination of the two is what makes workflow-scoped servers practical: you can compose exactly the toolset a workflow needs from across your stack, then apply granular access control within that server. Each server is purpose-built and independently auditable.
Putting It All Together
Organising internally around workflow-scoped servers was a deliberate decision for us — and one we'd make again. In practice, we run a marketing server and a support server. Within the marketing server, we define roles like contributor and editor, each with the tools relevant to their part of the workflow. The right tools in the right place, with access that mirrors how the work actually gets done. For external setups, the right pattern depends on what your solution is. But if you're thinking about your internal setup, workflow-scoped is worth designing for from the start.
If you're working through how to structure your own setup — whether that's mapping workflows, deciding what belongs on a server, or figuring out where RBAC fits in — we're happy to think through it with you. Drop us a line at hello@mcp-express.com.
Try MCP Express free →
Further Resources
- Documentation — Every supported integration, configuration option, and code example in one place.
- Contact Us — Questions before signing up, or want to talk through your setup? Drop us an email.
- Open a Support Ticket — Already inside the app and something's not working? Open a ticket directly from your dashboard.
