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
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.
Click Create System user.
Note: If MCP is the only system user type available, the button is labeled Create MCP client.
Select MCP Client/App and click Continue.
Select Machine-to-machine system user.
Enter a descriptive Name, such as Weekly marketing report.
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.
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.
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 |
Copy the Client ID, Token URL, Audience, Server URL and Grant type into your automation's settings.
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.
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.
Set up the automation to request a token from the Token URL using the client ID, client secret, audience and
client_credentialsgrant. Don't include anorganizationorscopeparameter. 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.
Read
access_tokenandexpires_infrom the response. Theexpires_invalue is the token's lifetime in seconds, measured from when it was issued.
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-Idheader with later requests. Requesting a token doesn't start an MCP session.
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.
