# Creating an MCP Server

An MCP server makes saved superglue tools available to MCP-compatible clients such as Claude Code, Cursor, Codex, and Langdock. It controls which tools a client can discover, who the client acts as, and which credential sets tool runs use.

**Tip:** Ask the superglue agent to create or edit a custom MCP server at any time. For example: **“Create
  an OAuth MCP server named Sales Assistant with the get-customer and create-invoice tools.”**

## Default or custom MCP server

**Default: All Tools**
The default MCP server is always available at `/mcp`. It has no manually configured tool list,
    so it exposes every active saved tool the connecting identity can access through RBAC. It is
    read-only and does not support server-level credential pinning.

    Use it for personal setup, exploration, or a client that genuinely needs broad access.

**Custom: Selected Tools**
A custom MCP server has a named endpoint and an explicit tool list. It can use OAuth or the
    creator's API key and can pin credential sets for individual systems.

    Use one for shared assistants, production agents, and any integration that should expose a
    small, purpose-specific surface.

**Note:** “All Tools” does not bypass RBAC. It means there is no additional server-level allowlist; each
  connection still sees only the tools permitted for its authenticated identity.

## Create a custom MCP server

1. **Ask the agent or open MCP Servers**

   Describe the audience, the task, and the tools the server should expose. The agent can create the server directly, or you can select **MCP Servers** in the app and create one manually.

2. **Select the tools**

   Add only the saved tools the MCP client needs. This list limits what the server can expose but does not grant users access to those tools.

3. **Choose an authentication mode**

   Use OAuth for users with individual superglue accounts. Use a creator API key for a trusted headless or internal client that must act as the server creator.

4. **Choose credential behavior**

   Leave a system unpinned to use each connecting identity's default accessible credential set, or pin a specific shared credential set for consistent execution.

5. **Save and export**

   Use **Export** to download the exact configuration for your MCP client. When you change a server's tools or credential pins later, reconnect the client to start a new MCP session with the updated configuration.

The agent can also add or remove tools, switch authentication mode, rename the endpoint, or change credential pins later. Members can edit servers they created; admins can edit any server in the organization.

## Choose authentication by use case

**OAuth (recommended)**
**Use for:** team-wide assistants and clients used by multiple people.

    Each person signs in with their own superglue account. Tool visibility, system access, and
    credential access are evaluated for that person. Unpinned systems use their default accessible
    credential set.

    OAuth servers also expose an `authenticate` helper tool that can send a user to superglue when a
    required system credential is missing.

**Creator API key**
**Use for:** trusted headless automation, private backend clients, or users who do not have
    superglue accounts.

    The client sends an active API key assigned to the server creator. Every client using that key
    acts as the creator and receives the creator's RBAC, system, and credential access.

    These servers do not advertise MCP OAuth and do not expose the `authenticate` helper tool. Keep
    the key server-side and rotate or revoke it like any other privileged secret.

**Note:** The authentication-mode selector applies to custom servers. The default server has no stored mode:
  it accepts a valid superglue bearer identity and advertises OAuth discovery to unauthenticated MCP
  clients.

## RBAC determines the effective tool set

An MCP server configuration is not an authorization grant. Define RBAC rules for the people or service identity that will connect before sharing the endpoint.

<ThreeColumnCards>
**1. Server scope**
The default server starts with all active tools. A custom server starts with only its selected
    tool IDs.

**2. Tool access**
Discovery filters that set using the authenticated identity's current tool grants. A selected
    tool without an effective grant is not exposed.

**3. Execution access**
Every run checks the tool again and verifies access to each system and credential set the tool
    needs. Passing discovery does not bypass these execution checks.

</ThreeColumnCards>

The resulting access model is:

```text
Default server tools = RBAC-allowed active tools
Custom server tools  = selected tools ∩ RBAC-allowed active tools
Successful run       = visible tool + required system access + accessible credentials
```

For OAuth, the authenticated identity is the person who signed in. For creator API key authentication, it is the server creator. Sharing a creator API key therefore shares the creator's effective access with every holder of that key.

**Caution:** Adding a tool to a custom server does not grant access to it. Grant the intended users access to
  the tool and its required systems through RBAC. Grant access to a pinned credential set as well
  when the server uses one.

## Pin credentials for consistent execution

Custom MCP servers can store a `pinnedCredentials` map from each system ID to the credential-set ID that should be used when a tool on that server runs:

```json
{
  "salesforce": "credentials-salesforce-service-account",
  "stripe": "credentials-stripe-billing"
}
```

At execution time, superglue resolves credentials independently for every system used by the tool:

1. **Use a pin when the system is listed**

   The runtime selects that exact credential set for every tool on this MCP server that uses the system.

2. **Use the connecting identity's credentials when it is not listed**

   The runtime prefers the identity's explicitly selected default credential set. If there is no explicit default, it uses the longest-held accessible set.

3. **Enforce access in both cases**

   The authenticated identity must be able to access the required system and the selected credential set. An inaccessible or mismatched pin fails the run; a pin never bypasses RBAC.

Pin a credential when all users should act through the same shared service account. Leave it unpinned when actions should use each person's own account. You can mix both behaviors on one server by pinning only selected systems.

Pins reference stored credential sets; they do not copy secret values into the MCP configuration. Updating a secret inside the same credential set automatically affects later runs. The default **All Tools** server has no stored configuration and therefore cannot define server-level pins.

## Connect an MCP client

Use the endpoint shown by **Export** in the MCP Servers view:

| Server  | Endpoint pattern                                     |
| ------- | ---------------------------------------------------- |
| Default | `https://YOUR_API_ENDPOINT/mcp`                      |
| Custom  | `https://YOUR_API_ENDPOINT/mcp/{orgId}/{serverName}` |

For self-hosted deployments, replace `YOUR_API_ENDPOINT` with that instance's public API endpoint.

OAuth-capable clients need only the server URL. The client discovers the authorization flow and prompts the user to sign in:

```json
{
  "mcpServers": {
    "sales-assistant": {
      "type": "http",
      "url": "https://YOUR_API_ENDPOINT/mcp/ORG_ID/sales-assistant"
    }
  }
}
```

  Add the creator's API key as a bearer token. Do not commit the expanded configuration to source control:

```json
{
  "mcpServers": {
    "sales-assistant": {
      "type": "http",
      "url": "https://YOUR_API_ENDPOINT/mcp/ORG_ID/sales-assistant",
      "headers": {
        "Authorization": "Bearer YOUR_SUPERGLUE_API_KEY"
      }
    }
  }
}
```

  MCP-triggered executions create normal superglue runs. They appear in run history and follow the same access checks as runs started from the app or API.