SteelEngine MCP

SteelEngine MCP exposes the SteelEngine platform to external editors and AI clients. It can build, test, deploy, and manage workflows and workspace resources from Claude.ai, Cursor, Claude Code, Claude Desktop, VS Code, and other MCP clients.

The canonical endpoint is:

https://steelengine.com/api/mcp/steelengine

Authentication

SteelEngine MCP supports:

• OAuth for clients that support the MCP OAuth flow. The signed-in user is the policy principal.
• SteelEngine MCP API keys sent in the X-API-Key header. The key owner is the policy principal and the key's grants are an additional scope cap.

OAuth access tokens must include the mcp:tools scope. That protocol scope permits use of the MCP endpoint; it does not grant access to SteelEngine resources.

The API-key AND rule

An MCP API key never inherits more access than its owner:

owner has the required PBAC permission
AND key scope covers the workspace or workflow at the required level
= operation allowed

The read, write, and admin labels attached to API-key grants are transport-level ceilings retained for key compatibility. They are not SteelEngine roles and do not replace catalog permissions.

Claude.ai with OAuth

1. In Claude.ai, open Settings → Connectors.
2. Click Add custom connector.
3. Enter {{APP_URL}}/api/mcp/steelengine.
4. Complete sign-in and consent in the browser.

SteelEngine advertises OAuth metadata from the endpoint's WWW-Authenticate challenge and issues refresh-capable OAuth 2.1 tokens.

Generate an MCP API key

Use a key for clients that authenticate with headers:

1. Sign in to SteelEngine.
2. Open workspace Settings → API Keys.
3. Find SteelEngine MCP.
4. Create a key and choose its workspace or workflow grants when prompted.
5. Copy the key immediately; it is shown once.

The key uses the sk-steelengine-... prefix.

Client configuration

Cursor

Add .cursor/mcp.json:

{
  "mcpServers": {
    "steelengine": {
      "url": "https://steelengine.com/api/mcp/steelengine",
      "headers": {
        "X-API-Key": "YOUR_STEELENGINE_MCP_API_KEY"
      }
    }
  }
}

Claude Code

claude mcp add steelengine \
  --transport http \
  https://steelengine.com/api/mcp/steelengine \
  --header "X-API-Key: YOUR_STEELENGINE_MCP_API_KEY"

Claude Desktop

Claude Desktop requires mcp-remote:

{
  "mcpServers": {
    "steelengine": {
      "command": "bunx",
      "args": [
        "mcp-remote",
        "https://steelengine.com/api/mcp/steelengine",
        "--header",
        "X-API-Key: YOUR_STEELENGINE_MCP_API_KEY"
      ]
    }
  }
}

VS Code

Add settings.json or .vscode/settings.json:

{
  "mcp": {
    "servers": {
      "steelengine": {
        "type": "http",
        "url": "https://steelengine.com/api/mcp/steelengine",
        "headers": {
          "X-API-Key": "YOUR_STEELENGINE_MCP_API_KEY"
        }
      }
    }
  }
}

For self-hosted deployments, replace {{APP_URL}} with the deployment URL.

Permission-aware discovery

MCP tools/list is built for the authenticated principal. A domain tool can be omitted when it has no usable operations, and an operation-based tool can advertise only the operations the principal can use in at least one reachable workspace.

For a principal with several workspaces, discovery is the union of potentially usable operations. It does not mean every advertised operation is allowed in every workspace.

MCP tools/call always authorizes the selected operation again against the resolved target. A call can be denied after discovery when:

• The target workspace is outside the role assignment's scope.
• The target is outside the API key's grants.
• A role or group assignment changed after discovery.
• An explicit deny applies.
• A required product entitlement or confirmation is missing.

Server-wide PBAC authorization

Every advertised operation across all 15 steelengine_* domain tools declares one or more Permission Catalog requirements. The direct list_workspaces tool is catalog-authorized too. There is no MCP fallback that converts a role into a generic workspace read, write, or admin capability.

Call authorization resolves the real target before execution. Existing resources such as workflows, tables, knowledge bases, skills, credentials, and MCP servers are checked by resource ID. Collection actions such as creating a workflow or table are checked against the destination workspace, database, or knowledge base. Parent IDs are resolved before policy evaluation, so a database or knowledge base from another workspace cannot be smuggled through a permitted workspace.

Multi-target operations check every protected side. Workflow cloning requires source workflow read permission and destination workflow create permission. A file-backed table import or knowledge-base ingest also requires document read access. Workflow-backed jobs require workflow execution access, workflow-specific notifications require workflow read access, and MCP server creation checks every workflow added as a tool.

Catalog entitlements and ABAC predicates are preserved. Archived or deleted resources remain unavailable where the catalog declares lifecycle checks, and confirmation-sensitive actions receive the call's confirmation context.

Example: Docs permission matrix

steelengine_docs shows how operations within one tool remain independently grantable:

The key scope must also cover the workspace. Mutating operations require a key grant whose transport ceiling is high enough for the operation.

Other domains follow the same model. Examples include workflow:read versus workflow:execute, table:query versus table:update, separate app publish/delete permissions, environment metadata versus secret-value access, and independent read/manage permissions for MCP servers and skills. See the Permission Catalog Reference for the complete vocabulary.

Workspace membership uses role keys

The workspace membership operations use the PBAC role model directly:

• list_members returns each member's effective roles with direct, group, or organization-wide provenance.
• invite_member accepts roleKey and defaults to the seeded Viewer key, workspace:read.
• update_member_role requires roleKey and accepts seeded or custom role keys.
• The legacy permission: read | write | admin argument is rejected.

MCP callers cannot change their own workspace role. Membership calls still require workspace:manage_members, and last-admin and billing-account safeguards continue to apply.

Conditional tool catalog

The server's domain catalog includes the following tools, but the list returned to a particular client is conditional:

Errors

All domain tools return a structured envelope. Authorization failures use:

{
  "success": false,
  "error": {
    "code": "permission_denied",
    "message": "Forbidden",
    "details": {
      "permissionKey": "workspace:update_documents",
      "workspaceId": "workspace-id"
    }
  }
}

The permission key is included when the operation uses exact catalog authorization. Denials are audited with the tool, operation, target, and permission key when available.

Troubleshooting access

1. Confirm the client authenticated as the expected user or key owner.
2. In Organization Settings → Access → People, inspect that person's effective roles for the target workspace.
3. Confirm the role includes the operation's catalog permission.
4. Check direct, group, inherited, and organization-wide provenance.
5. For API keys, confirm the key grant includes the workspace or workflow and a sufficient transport level.
6. Refresh the client's MCP tool list after an access change.
7. Treat a call-time denial as authoritative even if the operation remains in a cached client schema.