Platform Architecture

Understanding the structure of MCP Functions is essential for organizing your tools effectively and managing your team's access. This page explains how everything fits together in a clear, logical hierarchy.

Why a Hierarchical Structure?

MCP Functions uses a hierarchical structure to organize resources logically. This structure serves several important purposes:

• Logical organization - Related tools are grouped together, making them easy to find and manage

• Access control - You can grant different team members access to different parts of your organization

• Environment separation - Keep development, staging, and production tools separate

• Scalability - As your organization grows, this structure helps you manage hundreds or thousands of tools

• Clear ownership - It's clear which team or project each resource belongs to

Think of it like a filing system: you have folders (organizations) that contain drawers (workspaces), which contain folders (MCP servers), which contain documents (tools). This organization makes everything easy to find and manage.

The Four-Level Hierarchy

The platform uses a four-level hierarchy that flows from the top down. Each level serves a specific purpose and contains the level below it:

1. Organization The top-level container that represents your company, team, or project. This is where you manage team members, billing, and organization-wide settings. All of your resources exist within an organization. Contains: Team members (with roles), workspaces, billing information, usage statistics ↓ 2. Workspace An isolated environment within your organization where you group related projects and tools. Workspaces help you separate different projects, environments (like development and production), or teams. Each workspace has its own API keys, secrets, and MCP servers. Contains: MCP servers, API keys, encrypted secrets, workspace-specific team members ↓ 3. MCP Server A container that groups related tools together and exposes them via the MCP protocol. An MCP server is what AI assistants connect to when they want to use your tools. Think of it as a "toolbox" that contains multiple related tools. Contains: Multiple tools that work together to solve a particular problem or serve a specific purpose ↓ 4. Tool An individual function that performs a specific task. Tools are the building blocks - they're what actually do the work when an AI assistant needs to perform an action. Each tool has code that executes in a secure sandbox environment. Contains: Code, parameters, description, and execution logic

Visual Representation

Here's how the hierarchy looks in a tree structure:

Organization (Acme Corporation) ├── Members (roles: owner, admin, member) ├── Workspaces │ ├── "Customer Support Tools" workspace │ │ ├── Members (workspace-specific access) │ │ ├── API Keys (for authentication) │ │ ├── Secrets (encrypted configuration) │ │ └── MCP Servers │ │ └── "Customer Data Tools" server │ │ └── Tools (sandboxed code) │ │ ├── "Get Customer by Email" │ │ ├── "Update Customer Status" │ │ └── "Create Support Ticket" │ └── "Sales Automation" workspace │ └── ... (similar structure) └── Billing & Settings

Understanding Data Model Relationships

The relationships between different parts of the platform follow clear patterns. Understanding these relationships helps you plan how to organize your resources:

One-to-Many Relationships

• Organization → Workspaces - Each organization can have multiple workspaces. This allows you to separate different projects, teams, or environments within the same organization. For example, you might have workspaces for "Development", "Staging", and "Production".

• Workspace → MCP Servers - Each workspace can contain multiple MCP servers. This lets you organize tools by function. For example, within a "Customer Support Tools" workspace, you might have separate MCP servers for "Customer Data Tools", "Ticket Management Tools", and "Analytics Tools".

• MCP Server → Tools - Each MCP server can contain multiple tools. These tools work together to provide related functionality. For example, a "Customer Data Tools" MCP server might contain tools for looking up customers, updating customer records, and creating customer notes.

Many-to-Many Relationships

• Members ↔ Organizations - Team members can belong to organizations. A person can be a member of multiple organizations (though this is less common). Within an organization, each member has a role (Owner, Admin, or Member) that determines their permissions.

• Members ↔ Workspaces - Team members can have access to specific workspaces. This allows fine-grained access control. For example, you might give your development team access to a "Development" workspace, but not to the "Production" workspace.

Scoped Resources

• API Keys - These are workspace-scoped, meaning each API key belongs to a specific workspace. When you create an API key, it's associated with a workspace and can only be used to authenticate requests to MCP servers within that workspace.

• Secrets - These are also workspace-scoped. Secrets stored in a workspace are available to all tools within that workspace, but not to tools in other workspaces. This provides isolation and security.

How the Permission System Works

Permissions in MCP Functions follow a hierarchical model where permissions flow from the top down. Understanding this flow is crucial for managing access correctly:

Permission Inheritance

Permissions work in layers:

• Organization-level permissions - These are the highest level. Organization owners have full control over everything in the organization. Organization admins can manage most resources but typically can't manage billing or delete the organization.

• Workspace-level permissions - Workspace members inherit permissions from their organization role, but can also have workspace-specific permissions. For example, someone might be a Member at the organization level but have Admin access to a specific workspace.

• Resource-level access - Access to individual MCP servers and tools is controlled at the workspace level. If you have access to a workspace, you can see and use the MCP servers and tools within it (subject to your role's permissions).

Role-Based Access Control

The platform uses three main roles:

• Owner - Has full access to all resources in the organization. Can manage billing, delete the organization, and perform any action. There's typically at least one owner per organization.

• Admin - Can manage resources and members but typically can't manage billing or delete the organization. Great for team leads who need to manage resources but shouldn't have full owner access.

• Member - Can create and use resources but can't manage team members or organization settings. Perfect for team members who just need to use and create tools.

Workspace Isolation

One of the key security features is workspace isolation:

• Resources in one workspace cannot access resources in another workspace

• API keys from one workspace cannot be used to access MCP servers in another workspace

• Secrets stored in one workspace are not accessible to tools in other workspaces

• Team members can have different permissions for different workspaces

This isolation means you can safely have development and production workspaces in the same organization without worrying about accidental cross-contamination.

Best Practices for Organization

Here are some recommendations for organizing your resources effectively:

Organizations

• Create one organization per company or major project

• Use organizations to separate completely different business units or clients

• Keep billing and team management at the organization level

Workspaces

• Create separate workspaces for different environments (development, staging, production)

• Use workspaces to separate different projects or teams

• Create workspaces for different clients if you're building tools for multiple companies

• Use workspace-specific access control to limit who can see what

MCP Servers

• Group related tools together in the same MCP server

• Create separate MCP servers for different functional areas (e.g., "Customer Data", "Order Management", "Analytics")

• Keep MCP servers focused - if a server has too many unrelated tools, consider splitting it

Tools

• Keep tools focused on a single, well-defined task

• Use clear, descriptive names that explain what the tool does

• Write good descriptions so AI assistants understand when to use each tool

Real-World Example

Let's say you're building tools for a customer support team. Here's how you might organize everything:

Organization: "Acme Corporation"

• Workspace 1: "Customer Support - Production"

• **MCP Server:** "Customer Data Tools"

• Tool: "Get Customer by Email" - Tool: "Update Customer Status" - Tool: "Get Customer Order History"

- **MCP Server:** "Ticket Management Tools"

• Tool: "Create Support Ticket" - Tool: "Update Ticket Status" - Tool: "Get Ticket Details"

- **Workspace 2:** "Customer Support - Development"

• Similar structure but for testing new tools before deploying to production

This structure makes it clear what each resource does, who has access to it, and how everything relates to each other. As your needs grow, you can add more workspaces, MCP servers, and tools while maintaining this clear organization.