Tines 3B speaks the Model Context Protocol (MCP), so you can connect an external AI client like Claude Code and let it work in your Tines 3B workspace. Once connected, your client can explore your spaces and workflows, trigger runs, ask Tines 3B to build for you, and, with the right sign-in, author and publish workflows directly. This guide explains how the connection works and how to set it up.
Note: Before you start, make sure you have:
Your Tines 3B workspace URL. This is the address you use to sign in, for example
https://acme.3b.dev.An MCP-capable client. Any client that supports remote MCP servers over Streamable HTTP, such as Claude Code.
A way to authenticate. Either an interactive OAuth sign-in or a bearer token from a service account. We cover the difference below.
Tines 3B exposes a single MCP endpoint at your workspace URL with /mcp added to the end. If you sign in at https://acme.3b.dev, your endpoint is:
https://acme.3b.dev/mcp
The endpoint is specific to your workspace, so use your own address rather than the example. This is the URL you'll give your MCP client.
Choose how to authenticate
Tines 3B accepts two kinds of credentials on the MCP endpoint, and the choice decides what your client can do.
OAuth (full access). Your client sends you to Tines 3B in a browser to sign in and approve access, then receives a token. This is the only credential that can use the tools that build and publish workflows, so it's the right choice if you want your client to author steps directly.
Bearer token (read and ask). A token from a service account, sent as a bearer token. It can read, trigger runs, and ask Tines 3B to build for you, but it can't call the direct build and publish tools. This suits automation and headless use.
Whichever you pick, MCP never grants more than the credential already has.
Set up OAuth
Most clients handle OAuth for you. Point the client at your MCP endpoint, and when it first connects, Tines 3B responds with a sign-in challenge. Your client opens a browser window where you sign in to Tines 3B and approve access. After that, the client stores the token and reconnects on its own.
Set up a service account token
If you'd rather use a static token, create a service account and generate a credential for it:
Go to settings, then members, and open the service accounts area.
Create a service account, or open an existing one.
Generate a credential. A key acts as the service account until you revoke it, and a temporary credential expires on its own after the window you choose.
Copy the credential when it's shown. You won't be able to see it again.
Then give the service account access to the spaces and connectors it should reach, the same way you grant access to a person.
Note: Service account is the only supported way to get a token.
Connect your client
The exact fields vary by client, but the shape is the same:
Add a new MCP server in your client.
Set the server URL to your
/mcpendpoint.Choose your authentication. For OAuth, the client walks you through the browser sign-in. For a bearer token, paste the service account credential.
Save, then let the client list the available tools to confirm the connection.
What your client can do
Once connected, Tines 3B advertises a set of tools scoped to what your credential can reach. They fall into three groups:
Explore. List spaces and workflows, read a workflow's steps, inspect runs and executions, and read skills and connectors. Available to any credential.
Run and ask. Trigger a workflow run, create a workflow, and send messages to Tines 3B editor so it builds for you. Available to any credential.
Build and publish. Write and edit step files, run a step, run shell commands, connect a step to a connector, save a checkpoint, and push a workflow live. These require OAuth.
If your client calls a build or publish tool with a bearer token, Tines 3B refuses it and explains that the tool needs an OAuth connection.
How permissions work
MCP adds no new privilege. Every tool runs against the same access rules as the matching action in the app and the public API, so your client can only ever do what your credential could already do.
Access follows the identity. With OAuth, the client acts as you, so it sees the spaces you can read and edits the workflows you can edit. With a service account token, it acts as that service account and its granted access.
Sensitive actions stay gated. Publishing a workflow, for example, needs the same push-live permission it needs in the app.
Actions are audited. Tools that change something are recorded in your audit log, tagged as coming from MCP, so you can see what a connected client did.
Because access is governed by roles and grants, the cleanest way to control what a client can do is to scope the credential you connect with: connect as a user with the right access, or grant a purpose-built service account exactly the spaces and connectors it needs.