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.

i

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.

!

“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.

!

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.

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.

The resulting access model is:

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.

!

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:

{
  "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

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

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

Creator API key

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

{
  "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.