MCP tools

Runway exposes one transport-neutral MCP registry named fabric-runway. fr mcp serves it over stdio for local coding agents. The installed Runway Databricks App serves the same registry over authenticated Streamable HTTP at /api/v1/orgs/<org>/mcp for AppKit, Agent Bricks, AI Playground, and Unity Catalog MCP Services. There are no agent-only shortcuts: a deploy request still passes through the existing action API, schema, policy, durable invocation, state machine, adapters, and audit trail.

Registered tools

What is deliberately absent

There is no tool for gate_record, promotion_finalize, promotion_execute, rollback_execute, reconciliation_dispatch, deployment_reconcile, analytics_rollup, tenant_bootstrap, tenant_provision_complete, tenant_retire_apply, or tenant_retire_complete. Those are trusted-system actions. A registered Harness agent may record a promotion endorsement when its tenant role and policy allow it, but it cannot declare the threshold satisfied or execute production. The Platform worker evaluates the distinct total/human threshold and all required evidence before finalizing and deploying.

Native Fabric Harness tools

Customers building agents with Fabric Harness can import createRunwayHarnessTools from @fabricorg/runway-cli/harness-tools. Each tool declares effect: write, governed resource metadata, and calls the same action API. Harness tool-call IDs become stable Runway idempotency keys; policy failures return to the agent loop as typed errors.

The native tool set uses the same immutable-artifact contract as fr mcp: register a Harness build first, then deploy its artifactId. It also includes reconciliation, tenant lifecycle, explicit approval-cycle reopening, and governance reads, so an agent can fetch settings.revision before submitting runway.policy_set and cannot silently clobber a concurrent human change.

Connecting an agent

Point any MCP-capable client at the command, with the connection environment set:

{
  "mcpServers": {
    "fabric-runway": {
      "command": "fr",
      "args": ["mcp"],
      "env": {
        "RUNWAY_API_URL": "https://runway.your-workspace.databricksapps.com",
        "RUNWAY_ORG": "org-acme",
        "RUNWAY_API_TOKEN": "…"
      }
    }
  }
}

Every tool call is authenticated, tenant-scoped, and audited as an agent actor — the console's audit view shows exactly which deployments an agent requested.

Hosted Streamable HTTP

For a deployed Runway App, use this tenant-specific URL:

https://<runway-app-url>/api/v1/orgs/<org>/mcp

The endpoint accepts GET, POST, and DELETE according to Streamable HTTP and uses stateless MCP sessions so an App restart does not strand transport state. Readiness is available at the adjacent /mcp/health route. Both routes require a verified Databricks App user or an explicitly configured non-production development token. Tenant membership is resolved before MCP dispatch; individual reads and mutations are then authorized again by the existing projection and action routes.

Mutation idempotency is derived from the stable action id plus canonical arguments. Secrets remain opaque command references. The MCP process never receives secret values, cannot invoke production execution/finalization actions, and returns a policy denial as an MCP tool error.

Register with Unity AI Gateway

Databricks MCP Services are Beta. Enable Unity AI Gateway and Managed MCP Servers, then:

1. Create a schema-scoped Unity Catalog HTTP connection whose URL is the tenant-specific Runway MCP endpoint. Select bearer, OAuth M2M, OAuth U2M, or Dynamic Client Registration according to the identity that is installed as a Runway tenant member.
2. In AI Gateway → MCPs → Register MCP Server, create an MCP Service from that connection.
3. Initially expose only runway_catalog, runway_artifacts, and runway_deployments. Add mutation tools only after their Runway role and Gateway service policy are reviewed.
4. Grant users USE CATALOG, USE SCHEMA, and EXECUTE on the MCP Service. Do not grant end users USE CONNECTION, because that bypasses MCP Service tool selection and Gateway policy.
5. Invoke the resulting endpoint at https://<workspace>/ai-gateway/mcp-services/<catalog>.<schema>.<service>.

After an administrator creates the credential-bearing HTTP connection, Runway can idempotently create or tighten the MCP Service and grant only EXECUTE:

pnpm databricks:mcp:register -- \
  --profile <workspace-profile> \
  --connection main.agents.fabric_runway_http \
  --service main.agents.fabric_runway \
  --include-tool runway_catalog \
  --include-tool runway_artifacts \
  --include-tool runway_deployments \
  --execute-principal data-team

The registrar refuses an empty selector list, so an unattended run cannot accidentally expose every future Runway tool. On repeat it patches the connection, comment, and selector allowlist to the requested state. It never creates or reads the HTTP connection credential and never grants USE CONNECTION.

The current Databricks registration procedure and permissions are documented in Register an external MCP server. Retain the HTTP connection, service definition, selected tools, grants, Gateway policy, Runway action invocation, and audit event together as release evidence.

Agent Bricks Supervisor

Add the registered service to a Supervisor as a uc_mcp resource using its three-part Unity Catalog name. Start with a read-only prompt that calls runway_catalog; a later deployment request must still be denied or advanced by Runway policy exactly as it would be from the console or CLI. Supervisor invocation is not evidence that a mutation bypassed Runway—the action invocation and audit record are the authoritative business evidence.

Failure behavior

• Missing or invalid App identity returns 401; a tenant mismatch returns 403.
• Unknown tenants return 404; insufficient tool-specific permission is returned as an MCP error.
• Invalid schemas fail before an action invocation is created.
• A repeated mutation with the same canonical arguments reuses its stable idempotency key.
• Gateway, connection, or UC permission failures stop before Runway tool execution.