Skip to main content

Connect Funnel MCP with a machine-to-machine system user

Set up an automation to use Funnel MCP without a person signing in, with the workspace access and permissions you choose.

Use a machine-to-machine system user to connect an automation to Funnel MCP without a person signing in. For example, a scheduled job in GitHub Actions can read marketing data each week to prepare a report.

​

Before you begin

  • You have the Owner role in your Funnel subscription.

  • Your subscription includes machine-to-machine MCP system users.

  • You know which workspaces the automation needs and whether it only needs to read data or also make changes.

  • Your MCP client can get its own access tokens with a client ID and secret (the OAuth 2.0 client credentials grant). If it can't, your developer can get the tokens and give them to it. A client that can only sign in through a browser won't work.

​

You don't need to write code to set up the system user in Funnel. A developer might need to help connect it to your automation.

​

Choose the right connection type

A system user is an account for your automation instead of a person. You choose which workspaces it can use and what it can do in them. It has its own client ID and secret, so you don't need to store a teammate's username and password or personal tokens.

​

Choose Machine-to-machine system user for an automation that runs on its own. The automation uses a client ID and client secret to request temporary access tokens. No one needs to sign in, and there's no callback URL or refresh token to set up.

​

The Another client that asks for a Client ID and Client Secret option is for connecting an app that users sign in to with OAuth client registration. It isn't the machine-to-machine option, even though both use a client ID and secret.

​

Choose permissions for your plan

The workspace permissions available to a system user depend on your subscription plan, in the same way as for people who use Funnel.

Plan

Available workspace permissions

What to choose

Starter

Editor access only

The system user has Editor access. Read-only workspace access isn't available on this plan.

Business

Viewer or Editor

Choose Viewer for reporting that only reads data. Choose Editor only if the automation needs to make changes.

Enterprise

Workspace Viewer, Workspace Administrator and editor roles for specific parts of Funnel

Choose Workspace Viewer for read-only reporting. Add only the editor roles the automation needs, such as Organize Editor for custom fields or Export Editor for exports.

On the Starter plan, the system user can always make changes, even if your automation only reads data. To limit it to reading data, you need a plan that includes a Viewer role.

​

These are workspace permissions. Keep the Member subscription role when the automation only needs access to selected workspaces. Don't choose Owner or Administrator only so the automation can edit a workspace. These roles can also access every workspace and manage users across your subscription.

​

Set up the connection

Setup has three parts: create the system user, copy its connection details and connect your automation.

​

Step 1: Create the system user

  1. In Funnel, go to your profile menu and select Subscription overview. In the Subscription Management navigation, select Users, then go to the System users tab.

    ​

  2. Click Create System user.

    ​

    Note: If MCP is the only system user type available, the button is labeled Create MCP client.

    ​

  3. Select MCP Client/App and click Continue.

    ​

  4. Select Machine-to-machine system user.

    ​

  5. Enter a descriptive Name, such as Weekly marketing report.

    ​

  6. Under Subscription role, leave Member selected to give the automation access to the workspaces you select. Under Select Workspace(s), choose at least one workspace.

    ​

  7. Choose the workspace permissions available on your plan:

    ​

    • Business plan: Under Choose permission, select Viewer or Editor.

    • Enterprise plan: Use Assigned role(s) and Available role(s) to choose specific roles.

    • Starter plan: The system user gets Editor access, so there's nothing to choose.

    ​

  8. Click Create System user.

​

The roles you choose here apply to all the workspaces you selected. On Business and Enterprise plans, you can give one workspace different permissions after creation under System user access.

​

Step 2: Copy the connection details

On the system user's page, the System user details pane shows its client ID, client secret and the Connect a machine client instructions.

Detail

What it means

Client ID

Identifies your automation when it requests a token.

Client secret

Works like a password. Your automation uses it to request tokens. Keep it private.

Token URL

The address your automation sends its token request to.

Audience

Tells Funnel which service the token is for. Copy it exactly.

Server URL

The address your MCP client connects to after it has a token.

Grant type

Use client_credentials. This tells Funnel the automation is connecting as itself, not as a person.

  1. Copy the Client ID, Token URL, Audience, Server URL and Grant type into your automation's settings.

    ​

  2. Copy the Client secret into your automation's secret store. For GitHub Actions, use an Actions secret rather than putting the value in a workflow file.

    ​

  3. Share the setup instructions with the developer connecting your automation. Don't share the secret in email, chat or a support ticket.

​

Use the URLs and audience shown in your own Funnel subscription. Don't copy them from another subscription or an example.

​

Step 3: Connect your automation

To connect your automation, request a temporary access token and use that token to connect to Funnel MCP. Your automation uses the client secret only to request the token. It never sends the secret to the MCP server.

​

  1. Set up the automation to request a token from the Token URL using the client ID, client secret, audience and client_credentials grant. Don't include an organization or scope parameter. For an example request, see the code after these steps.

    ​

    Note: The response contains a sensitive access token. Store it securely. Don't print it in job logs or turn on shell tracing around credentials or token requests.

    ​

  2. Read access_token and expires_in from the response. The expires_in value is the token's lifetime in seconds, measured from when it was issued.

    ​

  3. Set up the MCP client to connect to the Server URL, sending the access token in the HTTP header Authorization: Bearer <access_token>.

    ​

    Use an MCP client library to handle the MCP connection sequence and sessions. If you implement HTTP requests yourself, initialize the connection first and send the returned Mcp-Session-Id header with later requests. Requesting a token doesn't start an MCP session.

    ​

  4. Test the connection with list_workspaces. Check that the expected workspaces appear before running the rest of your automation.

​

For the token request, the system user's page includes a ready-to-copy request with its connection values. This example for developers uses environment variables instead. Fill them in from your settings and secret store. Don't paste the secret into the script.

​

The example turns off shell tracing and saves the response in a variable instead of printing it. It then reads the token and its lifetime with jq. Pass FUNNEL_MCP_ACCESS_TOKEN to your MCP client without writing it to the job log.

set +x
token_response="$(curl --fail --silent --show-error \
  --request POST \
  --url "$FUNNEL_MCP_TOKEN_URL" \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=client_credentials \
  --data-urlencode client_id="$FUNNEL_MCP_CLIENT_ID" \
  --data-urlencode client_secret="$FUNNEL_MCP_CLIENT_SECRET" \
  --data-urlencode audience="$FUNNEL_MCP_AUDIENCE")"FUNNEL_MCP_ACCESS_TOKEN="$(jq -r '.access_token' <<< "$token_response")"
FUNNEL_MCP_TOKEN_EXPIRES_IN="$(jq -r '.expires_in' <<< "$token_response")"
unset token_response

In GitHub Actions, run echo "::add-mask::$FUNNEL_MCP_ACCESS_TOKEN" before any step that might print the token. The runner then hides the value in the job log.

​

Reuse a token while it's valid. For a long-running job, request a new token a few minutes before it expires and update the client to use it. A weekly job can request a new token at the start of each run. You don't need to keep a refresh token between runs.

​

For workspace queries, the client should call the Funnel MCP tools in order: load_workspace, then get_workspace_context, before searching fields or querying data.

​

What to expect

Your automation now connects as the system user rather than as you. What it can do depends on its permissions. Some tools still need someone to approve or sign in, even with an editor role, so test the tools your job needs before scheduling it.

​

When the automation's needs change, manage the system user's access and credentials.

Did this answer your question?