Areas & Namespaces

Organizing MCPs within organizations using areas, creating areas, assigning MCPs, and namespace isolation.

4 min read

Areas (also called namespaces) are organizational subdivisions within an Enterprise organization. They allow large teams to segment their MCP servers, members, and permissions into logical groups – such as teams, projects, business units, or environments.

Why Use Areas?

Without areas, every member of an organization can see all MCPs registered under that organization. In a company with hundreds of MCPs across dozens of teams, this quickly becomes unmanageable. Areas solve this by providing:

Clean separation of concerns: Each team only sees the MCPs relevant to their work.
Delegated ownership: Team leads manage their own areas without needing organization-wide admin access.
Better discoverability: Fewer, more relevant MCPs per view.
Granular permissions: Users can have different roles in different areas.

Example Structure

Organization: Acme Corp
+-- Area: Frontend Team
|   +-- Lead: Alice (OWNER)
|   +-- Member: Dave
|   +-- MCPs: ui-components, design-system (20 MCPs)
+-- Area: Backend Team
|   +-- Lead: Bob (OWNER)
|   +-- Member: Eve
|   +-- MCPs: api-gateway, auth-service (50 MCPs)
+-- Area: DevOps
    +-- Lead: Carol (OWNER)
    +-- Member: Frank
    +-- MCPs: k8s-tools, monitoring (30 MCPs)

Common Use Cases

Pattern	Example	Description
Team-based	Frontend, Backend, Mobile, DevOps	Organize by engineering team
Project-based	Project Alpha, Project Beta	Organize by client or internal project
Geographic	North America, EMEA, APAC	Organize by region
Environment-based	Development, Staging, Production	Separate MCPs by deployment environment

Creating Areas

To create an area, you must be an organization Owner or Admin (requiring org:edit permission). Areas are available only for Enterprise organizations.

POST /api/v1/orgs/{orgId}/areas

{
  "name": "Frontend Team",
  "slug": "frontend",
  "description": "UI components and design system MCPs"
}

Each area requires:

Name: A descriptive, human-readable name.
Slug: A URL-safe identifier that must be unique within the organization. Slugs are lowercase with hyphens only, and they cannot be changed after creation.
Description: An optional explanation of the area’s purpose.

Area Roles

Areas maintain their own role hierarchy, independent of organization-level roles. An organization Member can be an area Owner, and an organization Admin can be an area Viewer. Organization Owners always have implicit access to all areas.

Action	Owner	Admin	Member	Viewer
View area details and MCPs	Yes	Yes	Yes	Yes
Use area MCPs	Yes	Yes	Yes	No
Add/remove MCPs from area	Yes	Yes	No	No
Add/remove area members	Yes	Yes	No	No
Change member roles	Yes	Yes	No	No
Update area details	Yes	No	No	No
Delete area	Yes	No	No	No

Adding Members to an Area

Members must first belong to the organization before they can be added to an area:

POST /api/v1/orgs/{orgId}/areas/{areaId}/members

{
  "user_id": "user-uuid",
  "role": "MEMBER"
}

Updating a Member’s Area Role

Area Owners and Admins can change a member’s role within the area:

PATCH /api/v1/orgs/{orgId}/areas/{areaId}/members/{userId}/role

{
  "role": "ADMIN"
}

Assigning MCPs to Areas

An MCP can belong to one area at a time. Assigning an MCP to an area makes it primarily visible to area members and helps organize large collections.

During MCP Creation

When registering a new MCP, include the area_id field:

{
  "name": "ui-components",
  "repo_url": "https://github.com/acme/ui-components",
  "area_id": "area-uuid"
}

Reassigning an Existing MCP

Update the MCP to change its area assignment, or set area_id to null to remove it from any area.

Listing MCPs in an Area

Filter the MCP listing by area:

GET /api/v1/mcps?area_id={areaId}

Namespace Isolation

Areas provide logical namespace isolation within the organization. Each area acts as a scoped view:

MCP visibility: Members of an area see the MCPs assigned to that area when browsing. Organization-level users (Admin and Owner) retain access to all MCPs across all areas.
Permission boundaries: Area roles determine what actions a user can take on MCPs within that area, independently of their organization role.
Audit context: Actions performed within an area are logged with the area context for traceability.

Deleting an Area

Only area Owners and organization Admins/Owners can delete an area:

DELETE /api/v1/orgs/{orgId}/areas/{areaId}

When an area is deleted:

All area member assignments are removed.
MCPs previously assigned to the area have their area_id set to null (the MCPs themselves are not deleted).
The area and its configuration are permanently removed.

Best Practices

Start broad, subdivide later: Begin with a few high-level areas (e.g., by team) and split into more specific areas only when needed.
Use descriptive names and slugs: Choose names like “Frontend Engineering Team” with slugs like frontend, not “Team A” with ta.
Assign clear ownership: Each area should have one primary Owner (team lead) and one or two Admins as backup.
Regular cleanup: Periodically review area members (remove inactive users), assigned MCPs (remove deprecated ones), and consider merging underutilized areas.
Consistent naming conventions: Use a naming scheme across your areas – by team (frontend, backend), by project (project-alpha, project-beta), or by region (na, emea).

Current Limitations

No nested areas: Areas are flat; there are no sub-areas.
Single area assignment: An MCP can belong to only one area at a time.
Organization-level policies only: Governance policies apply at the organization level, not per area.
Predefined roles only: Area roles (Owner, Admin, Member, Viewer) are fixed and cannot be customized.