# Model Context Protocol (MCP)

> Architecture, tool specifications, and integration design for Model Context Protocol in Glow.

[Model Context Protocol (MCP)](https://modelcontextprotocol.io) is an open standard developed by Anthropic that provides a unified, structured protocol for AI assistants, coding agents, and IDEs to interact with external automation tools and systems.

> **Developer Preview:** Model Context Protocol (MCP) integration is currently
> available for workspace developers and engineering preview accounts. This
> guide details the architecture, tool specifications, and integration models.

Glow supports MCP across two complementary architectures:

  - [Glow as an MCP Server](#server-architecture--protocol-flow): Connect external AI assistants (Cursor, Claude Desktop, Zed, Claude Code) to discover, inspect, and trigger automations directly from your IDE.

  - [Glow as an MCP Client](#glow-as-an-mcp-client): Equip visual [AI Agent](/build/ai-features/ai-agent) steps with external tool servers (Postgres MCP, GitHub MCP, custom internal APIs).

---

## Server Architecture & Protocol Flow

When an authorized AI client connects to Glow's MCP server, the protocol negotiates capabilities and establishes a secure JSON-RPC channel. The gateway authenticates every tool invocation against workspace policies before dispatching it to the execution engine:

```mermaid
sequenceDiagram
    autonumber
    actor Developer as Developer / AI Agent
    participant Client as IDE / Client (Cursor / Claude)
    participant Gateway as Glow MCP Gateway
    participant Engine as Workflow Execution Engine

    Developer->>Client: "Run Lead Triage for ada@example.com"
    Client->>Gateway: execute_workflow(workflowId, payload)
    Gateway->>Gateway: Verify Token & Workspace Scopes
    Gateway->>Engine: Admit & Queue Execution
    Engine-->>Gateway: Execution Started (executionId)
    Gateway-->>Client: Return Status: in_progress
    Client->>Gateway: get_execution_status(executionId)
    Gateway-->>Client: Status: pass (Step Outputs)
    Client-->>Developer: Present Formatted Run Summary
```

---

## Access & Permission Model

MCP access is governed by scoped developer tokens with explicit capability boundaries:

| Permission Scope | Granted Operations                                                                    | Security Policy                                      |
| :--------------- | :------------------------------------------------------------------------------------ | :--------------------------------------------------- |
| `mcp:read`       | Read-only discovery: `list_workflows`, `get_workflow_schema`, `get_execution_status`. | Cannot trigger executions or modify workspace state. |
| `mcp:execute`    | Execution capabilities: `execute_workflow`, `test_step`.                              | Strictly limited to the authenticated workspace.     |

> **Security Guarantees:** - **Scoped Bearer token authentication** with
> cryptographic verification. - **Tenant isolation:** Access strictly limited to
> your authorized workspace. - **Audit visibility:** Sandboxed executions tagged
> with an `MCP test` badge. - **Zero credential leakage:** Real secrets and
> OAuth tokens are never exposed in tool schemas.

---

## Example Developer Interactions

When connected to an MCP server, an AI assistant interprets natural language instructions and executes structured tool calls:

```text
"Show me all active workflows in my workspace."
→ Calls list_workflows(status="live")
```

```text
"What inputs does the 'Support Ticket Triage' workflow require?"
→ Calls get_workflow_schema(workflowId="flow_84920481")
```

```text
"Run the 'Lead Enrichment' workflow for customer alex@company.com."
→ Calls execute_workflow(workflowId="flow_84920481", payload={ customer_email: "alex@company.com" })
```

```text
"Test step 2 (HTTP Request) in isolation with mock input { ticket_id: 104 }."
→ Calls test_step(workflowId="flow_84920481", stepNumber=2, mockedInputs={ ... })
```

---

## MCP Server: Tool Reference

The Glow MCP server exposes five primary tools organized by operational function:

| Tool                                              | Scope         | Purpose                                                             |
| :------------------------------------------------ | :------------ | :------------------------------------------------------------------ |
| [`list_workflows`](#1-list_workflows)             | `mcp:read`    | Discover available workflows, trigger types, and status.            |
| [`get_workflow_schema`](#2-get_workflow_schema)   | `mcp:read`    | Inspect trigger parameter schemas, variables, and step layout.      |
| [`execute_workflow`](#3-execute_workflow)         | `mcp:execute` | Trigger a workflow execution with custom JSON payload.              |
| [`get_execution_status`](#4-get_execution_status) | `mcp:read`    | Poll live run progress, duration, and step-level outputs.           |
| [`test_step`](#5-test_step-isolated-sandbox-test) | `mcp:execute` | Run a single action step in a sandbox with mock predecessor inputs. |

---

### 1. `list_workflows`

Returns a list of workflows available in the authenticated workspace.

**Parameters**

| Parameter | Type      | Required | Default | Description                                             |
| :-------- | :-------- | :------- | :------ | :------------------------------------------------------ |
| `status`  | `string`  | No       | `"all"` | Filter by status: `"live"`, `"draft"`, or `"all"`.      |
| `search`  | `string`  | No       | `null`  | Keyword filter matching workflow name or description.   |
| `limit`   | `integer` | No       | `50`    | Maximum number of workflow summaries to return (1–100). |

  
    ```json
    {
      "name": "list_workflows",
      "arguments": {
        "status": "live",
        "search": "Support"
      }
    }
    ```
  
  
    ```json
    {
      "workflows": [
        {
          "id": "flow_84920481",
          "name": "AI Support Ticket Triage",
          "status": "live",
          "triggerType": "webhook",
          "stepCount": 4,
          "updatedAt": "2026-09-05T14:22:10Z"
        }
      ],
      "totalCount": 1
    }
    ```
  

---

### 2. `get_workflow_schema`

Fetches the complete structural schema for a workflow, including required trigger parameters, mapped variables, and step sequences.

**Parameters**

| Parameter    | Type     | Required | Description                                                   |
| :----------- | :------- | :------- | :------------------------------------------------------------ |
| `workflowId` | `string` | **Yes**  | The unique identifier of the workflow (e.g. `flow_84920481`). |

  
    ```json
    {
      "name": "get_workflow_schema",
      "arguments": {
        "workflowId": "flow_84920481"
      }
    }
    ```
  
  
    ```json
    {
      "workflowId": "flow_84920481",
      "name": "AI Support Ticket Triage",
      "status": "live",
      "trigger": {
        "stepNumber": 1,
        "type": "webhook",
        "expectedPayload": {
          "type": "object",
          "properties": {
            "customer_email": { "type": "string" },
            "ticket_subject": { "type": "string" },
            "ticket_body": { "type": "string" }
          },
          "required": ["customer_email", "ticket_body"]
        }
      },
      "steps": [
        { "stepNumber": 2, "type": "ai_prompt", "name": "Classify Urgency" },
        { "stepNumber": 3, "type": "switch", "name": "Route Priority" },
        { "stepNumber": 4, "type": "slack_send_message", "name": "Notify Team" }
      ]
    }
    ```
  

---

### 3. `execute_workflow`

Triggers a workflow run with a supplied JSON payload and returns an execution tracking ID.

**Parameters**

| Parameter       | Type     | Required | Default  | Description                                          |
| :-------------- | :------- | :------- | :------- | :--------------------------------------------------- |
| `workflowId`    | `string` | **Yes**  | —        | Target workflow ID.                                  |
| `payload`       | `object` | **Yes**  | —        | JSON data dictionary passed to the trigger step.     |
| `correlationId` | `string` | No       | `null`   | Optional tracking identifier for log correlation.    |
| `mode`          | `string` | No       | `"live"` | Run mode: `"live"` (published version) or `"draft"`. |

  
    ```json
    {
      "name": "execute_workflow",
      "arguments": {
        "workflowId": "flow_84920481",
        "payload": {
          "customer_email": "alex@company.com",
          "ticket_subject": "Payment API returned 504",
          "ticket_body": "Transactions timed out during checkout."
        },
        "correlationId": "ticket-4812"
      }
    }
    ```
  
  
    ```json
    {
      "executionId": "exec_9a8f234b01e",
      "status": "in_progress",
      "startedAt": "2026-09-07T10:15:30Z",
      "correlationId": "ticket-4812"
    }
    ```
  

---

### 4. `get_execution_status`

Queries the execution state and individual step outputs of an active or finished run.

**Parameters**

| Parameter            | Type      | Required | Default | Description                                        |
| :------------------- | :-------- | :------- | :------ | :------------------------------------------------- |
| `executionId`        | `string`  | **Yes**  | —       | Execution ID returned from `execute_workflow`.     |
| `includeStepOutputs` | `boolean` | No       | `true`  | When `true`, includes step-level `result` objects. |

  
    ```json
    {
      "name": "get_execution_status",
      "arguments": {
        "executionId": "exec_9a8f234b01e"
      }
    }
    ```
  
  
    ```json
    {
      "executionId": "exec_9a8f234b01e",
      "status": "pass",
      "startedAt": "2026-09-07T10:15:30Z",
      "completedAt": "2026-09-07T10:15:33Z",
      "durationMs": 3120,
      "steps": [
        {
          "stepNumber": 1,
          "name": "Webhook Trigger",
          "status": "pass",
          "result": { "customer_email": "alex@company.com" }
        },
        {
          "stepNumber": 2,
          "name": "Classify Urgency",
          "status": "pass",
          "result": { "category": "critical", "urgency": "high" }
        },
        {
          "stepNumber": 4,
          "name": "Notify Team",
          "status": "pass",
          "result": { "channel": "#ops-urgent", "ts": "1725704133.01" }
        }
      ]
    }
    ```
  

---

### 5. `test_step` (Isolated Sandbox Test)

Executes a single step in complete isolation, using real workspace credentials and optional mock data representing predecessor steps.

```mermaid
flowchart LR
    M[Mock Inputs] --> S[Step Sandbox] --> R[Output to MCP]
    S -.->|Downstream Blocked| X[Skip Rest]
```

**Parameters**

| Parameter      | Type      | Required | Description                                                         |
| :------------- | :-------- | :------- | :------------------------------------------------------------------ |
| `workflowId`   | `string`  | **Yes**  | ID of the workflow containing the step.                             |
| `stepNumber`   | `integer` | **Yes**  | Step number to execute (e.g. `2`).                                  |
| `mockedInputs` | `object`  | No       | Dictionary mapping predecessor step numbers to mock output objects. |

**Key Sandbox Capabilities**

- **No cascade execution:** Steps wired after the test target are not run.
- **Authentic authentication:** The step uses configured workspace integrations and secrets securely.
- **Audit tracking:** Test executions are logged in **Activity** and tagged with an `MCP test` badge.

  
    ```json
    {
      "name": "test_step",
      "arguments": {
        "workflowId": "flow_84920481",
        "stepNumber": 2,
        "mockedInputs": {
          "1": {
            "ticket_subject": "504 Gateway Timeout during checkout",
            "ticket_body": "Payment endpoint stopped responding."
          }
        }
      }
    }
    ```
  
  
    ```json
    {
      "stepNumber": 2,
      "status": "pass",
      "durationMs": 840,
      "result": {
        "category": "billing_critical",
        "urgency": "high",
        "suggested_action": "alert_finops"
      }
    }
    ```
  

---

## Glow as an MCP Client

In addition to serving tools to external AI clients, Glow automations can consume external MCP tool servers to empower visual [AI Agent](/build/ai-features/ai-agent) steps:

```mermaid
flowchart LR
    A["1. Analyze Goal"] --> B["2. Invoke MCP Tool<br/>(e.g. query_db)"] --> C["3. External Server<br/>Returns Records"] --> D["4. Synthesize Answer<br/>on Canvas"]
```

1. **External Server Registration:** Connect remote MCP servers in workspace settings with remote endpoint URLs and authentication headers.
2. **Agent Tool Assignment:** Toggle external tool servers on inside the AI Agent step's **Tools** panel.
3. **Autonomous Reasoning:** During workflow runs, the agent discovers and invokes external tools dynamically to fulfill user goals.

## What's Next?

- 👉 **[REST API & Webhooks →](/manage/workspace-settings/developer-settings)**: Standard REST endpoints for programmatic workflow execution.
- **[AI Agent Step](/build/ai-features/ai-agent)**: Build multi-turn autonomous reasoning workflows on the visual canvas.
- **[Secrets and Variables](/manage/workspace-settings/secrets-and-variables)**: Secure management for API keys and credentials.