Getting Started with WorkflowGen MCP Server Preview

jianan.hsu · April 17, 2026, 3:03pm

Overview

Audience: WorkflowGen administrators

Status: Preview guidance

Important: WorkflowGen MCP Server is currently planned for the WorkflowGen 10.3.0 preview release.

This post explains how to enable, configure, and test WorkflowGen MCP Server with Claude Cowork and the Codex app.

This is a practical getting-started guide for administrators who want to try the MCP Server preview before the official documentation is finalized.

What Is WorkflowGen MCP Server?

WorkflowGen MCP Server exposes WorkflowGen operations through the Model Context Protocol (MCP), so AI clients can securely interact with WorkflowGen on behalf of an authenticated WorkflowGen user.

For example, a connected MCP client can help users:

identify who they are in WorkflowGen
list their requests and actions
launch requests
complete or assign actions
add comments
manage favorites and delegations
perform process-management or administration operations when the WorkflowGen user has the required permissions

WorkflowGen MCP uses OAuth for MCP client authorization. The user signs in through the existing WorkflowGen browser authentication flow, and WorkflowGen issues MCP access tokens to the client.

Important Notes

Some details may still change before the final release. The general architecture and configuration model described here are expected to remain the same, but always check the official release notes and guides when they become available.

Requirements

Before enabling MCP OAuth, confirm the following requirements.

WorkflowGen Authentication

WorkflowGen MCP OAuth requires the main WorkflowGen site to use one of these browser authentication methods:

OpenID Connect (OIDC)
SAML

WorkflowGen MCP OAuth does not support these WorkflowGen authentication modes as browser login sources:

Integrated Windows authentication
IIS HTTP Basic authentication
WorkflowGen HTTP Basic authentication
Custom HTTP Basic authentication
WorkflowGen Applicative authentication
Form authentication
custom authentication modules

You can still install the /wfgen/mcp IIS application during an upgrade, but do not enable MCP OAuth unless WorkflowGen uses OIDC or SAML, or is being switched to OIDC or SAML as part of the deployment.

HTTPS

The MCP endpoint must be exposed over HTTPS.

For a standard WorkflowGen virtual directory deployment, the MCP endpoint is:

https://<workflowgen-url>/wfgen/mcp

For a WorkflowGen web-root deployment, the MCP endpoint is:

https://<workflowgen-url>/mcp

MCP Client Support

This guide covers:

Claude Cowork, which uses web-based OAuth redirects
Codex app, which uses native-client loopback OAuth redirects

Other MCP clients may work if they support OAuth, Dynamic Client Registration, authorization code with PKCE, and Streamable HTTP transport.

Step 1: Install Or Upgrade WorkflowGen MCP Files

Install or upgrade WorkflowGen using the normal WorkflowGen installation or upgrade package.

The MCP application files are installed under:

\wfgen\mcp

For a standard deployment, this maps to:

https://<workflowgen-url>/wfgen/mcp

If you are manually merging files during an upgrade, make sure the MCP files from the package are deployed and that deprecated Node.js app build artifacts are removed when instructed by the official upgrade guide.

The manual installation package installs a usable \wfgen\mcp\web.config file. The update package provides the MCP IIS/iisnode configuration as \wfgen\mcp\web.config.sample so an upgrade does not overwrite an existing local configuration. When enabling MCP from an update package for the first time, copy or rename web.config.sample to web.config if \wfgen\mcp\web.config does not already exist. If web.config already exists, compare and merge the sample changes instead of replacing local IIS or iisnode settings.

Step 2: Configure IIS

In IIS Manager:

Open the WorkflowGen site.
Select the wfgen/mcp folder.
Convert it to an application.
Use a .NET Framework 4 application pool.
Use Integrated pipeline mode.
Enable Anonymous authentication for the MCP child application.

The MCP application is a Node.js/iisnode child application. It must not be protected directly by the main WorkflowGen authentication module. The browser login happens through the main WorkflowGen site during the OAuth bridge flow.

If you manually merge \wfgen\web.config, make sure it contains the default MCP child-application exclusion:

<location path="mcp" inheritInChildApplications="false">
  <system.webServer>
    <modules>
      <remove name="ApplicationSecurityAuthenticationModule" />
    </modules>
  </system.webServer>
</location>

Step 3: Check Root Web.config Rewrite Rules

For standard /wfgen/mcp deployments, the root site web.config must include the MCP OAuth rewrite rules provided by the installation package.

These rules allow MCP clients to discover OAuth metadata and allow the browser bridge URL to be handled by WorkflowGen:

Add them inside:

<system.webServer>
  <rewrite>
    <rules>
      ...
    </rules>
  </rewrite>
</system.webServer>

<rule name="Rewrite to wfgen OAuth auth bridge" stopProcessing="true">
  <match url="^wfgen/oauth-auth-bridge$" />
  <action type="Rewrite" url="/wfgen/show.aspx?qry=OAUTH_AUTH_BRIDGE" appendQueryString="true" />
</rule>
<rule name="Rewrite root OAuth protected-resource metadata for MCP" stopProcessing="true">
  <match url="^\.well-known/oauth-protected-resource/wfgen/mcp$" />
  <action type="Redirect" url="/wfgen/mcp/.well-known/oauth-protected-resource" redirectType="Temporary" />
</rule>
<rule name="Rewrite root OAuth authorization-server metadata for MCP" stopProcessing="true">
  <match url="^\.well-known/oauth-authorization-server/wfgen/mcp$" />
  <action type="Redirect" url="/wfgen/mcp/.well-known/oauth-authorization-server" redirectType="Temporary" />
</rule>

For web-root deployments where the MCP endpoint is /mcp, use the corresponding /mcp rules from the package.

Most installations should not need to edit these rules manually. If WorkflowGen is installed under a custom virtual path, adjust the root rewrite rules to match the actual MCP endpoint path.

Step 4: Configure MCP OAuth

Open the WorkflowGen Administration Module and configure the OAuth Server section first:

Administration > Configuration > Integration > OAuth Server

Recommended values:

Enable OAuth server: Enabled
OAuth server key encryption key: Generate a new value
OAuth server bridge token signing secret: Generate a new value
OAuth server access token lifetime: 3600
OAuth server authorization code lifetime: 600
OAuth server refresh token lifetime: 7776000

Then configure the MCP Server section:

Administration > Configuration > Integration > MCP Server

Recommended values:

MCP resource URI: Empty
MCP allowed scopes: mcp:read mcp:write mcp:process_admin mcp:admin
MCP diagnostic log level: INFO

Leaving the MCP resource URI empty is recommended for most deployments. WorkflowGen derives it from:

ApplicationUrl + "/mcp"

For example, if ApplicationUrl is:

https://<workflowgen-url>/wfgen

Then the MCP resource URI is:

https://<workflowgen-url>/wfgen/mcp

If you explicitly set McpResourceUri, it must be:

an absolute HTTPS URL
without a query string
without a fragment
ending with /mcp

Example:

<add key="McpResourceUri" value="https://<workflowgen-url>/wfgen/mcp" />

Step 5: Check Advanced Web.config-Only Setting For Codex

The Codex app and similar native MCP clients use a local loopback OAuth callback, such as:

http://127.0.0.1:52940/callback

To support Codex, keep this setting enabled in \wfgen\web.config:

<add key="OAuthServerAllowLocalhostRedirects" value="true" />

Important:

false means HTTPS-only redirect URIs.
true does not allow arbitrary HTTP redirects.
true only allows loopback HTTP callbacks for localhost, 127.0.0.1, and [::1].

Set this to false only if your organization wants to reject all HTTP redirect URIs and support HTTPS callback clients only.

Step 6: Verify MCP Health And OAuth Metadata

Open the MCP health endpoint:

https://<workflowgen-url>/wfgen/mcp/health

Expected result:

{
  "status": "ok",
  "app": "workflowgen-mcp"
}

The response may include additional fields depending on the build.

Then verify the OAuth protected-resource metadata:

https://<workflowgen-url>/wfgen/mcp/.well-known/oauth-protected-resource

Expected result:

{
  "resource": "https://<workflowgen-url>/wfgen/mcp",
  "authorization_servers": [
    "https://<workflowgen-url>/wfgen/mcp"
  ],
  "bearer_methods_supported": [
    "header"
  ],
  "scopes_supported": [
    "mcp:read",
    "mcp:write",
    "mcp:process_admin",
    "mcp:admin"
  ]
}

If your MCP client uses root-level OAuth discovery, these URLs should also work:

https://<workflowgen-url>/.well-known/oauth-protected-resource/wfgen/mcp
https://<workflowgen-url>/.well-known/oauth-authorization-server/wfgen/mcp

Step 7: Connect From Claude Cowork

In Claude Cowork:

Open the connector settings.
Add a custom MCP connector.
Enter the MCP server URL:
```
https://<workflowgen-url>/wfgen/mcp
```
Click Connect.
A browser window opens.
Sign in to WorkflowGen through your OIDC or SAML login page.
Authorize the MCP connection.
Claude Cowork should show the connector as connected.

Try this prompt:

Who am I in WorkflowGen, and what can I do here?

Expected behavior:

Claude should identify the authenticated WorkflowGen user.
Claude should summarize the user profile and available MCP capabilities.
The available tools depend on the WorkflowGen user type and the configured MCP scopes.

Changing granted scopes later

The scopes granted to a connector are fixed for that OAuth authorization.

If a user first grants only mcp:read and later wants to add mcp:write, mcp:process_admin, or mcp:admin, the MCP client must start a new OAuth authorization flow so WorkflowGen can issue a new token with the broader granted scope.

In practice:

use the MCP client’s Authenticate, Reconnect, or Reauthorize action if it starts a fresh browser authorization flow
if the client does not prompt for authorization again, remove the connector and add it again

WorkflowGen user role alone does not widen an already-issued token. For example, a WorkflowGen administrator who granted only mcp:read still receives 403 insufficient_scope for write or admin tool calls until the connector is re-authorized with the additional scopes.

Step 8: Connect From Codex App

In the Codex app:

Open Settings.
Go to MCP servers.
Add a custom MCP server.
Select Streamable HTTP.
Enter a server name, for example:
```
workflowgen
```
Enter the MCP server URL:
```
https://<workflowgen-url>/wfgen/mcp
```
Save.
Click Authenticate.
A browser window opens.
Sign in to WorkflowGen through your OIDC or SAML login page.

The browser may show a local callback page such as:

http://127.0.0.1:<port>/callback?code=...&state=...

The callback page should say authentication is complete.
Return to Codex and test the MCP server.

Try this prompt:

Who am I in WorkflowGen?

Expected behavior:

Codex should identify the authenticated WorkflowGen user.
If the user is an administrator, Codex should have access to all allowed MCP tool categories.

Step 9: Understand Which Tools Users See

WorkflowGen MCP tool visibility depends on three layers.

First, the deployment-level scope ceiling is configured by:

<add key="McpAllowedScopes" value="mcp:read mcp:write mcp:process_admin mcp:admin" />

Second, the current connector only sees tools within the scopes it actually granted during OAuth authorization.

Third, WorkflowGen filters visible tools based on the authenticated user profile.

Basic user: Runtime read/write tools
Process manager or folder manager: Runtime read/write tools plus process-management tools
WorkflowGen administrator: All currently granted MCP tools that are also allowed by the deployment

With the default full scope ceiling:

Basic user: 26 tools
Process manager / folder manager: 36 tools
Administrator: 62 tools

These counts are useful for smoke testing but may change as the MCP feature evolves.

Final authorization is still enforced by WorkflowGen business logic in the Service Facade. Seeing a tool does not bypass WorkflowGen permissions.

Step 10: Suggested Demo Prompts

Use these prompts to validate the connection.

Who am I in WorkflowGen, and what can I do here?

List my current WorkflowGen actions and summarize what needs my attention.

Show me the processes I can launch, then help me start a simple approval request.

For an administrator:

Summarize my WorkflowGen administrator capabilities through this MCP connection.

For a process manager:

What process-management operations can I perform here?

Troubleshooting

The MCP connector cannot reach the server

Check:

the MCP URL is correct, for example https://<workflowgen-url>/wfgen/mcp
the /wfgen/mcp IIS child application exists
Anonymous authentication is enabled on the MCP child application
HTTPS is available from the client machine
firewall or IP allow-list rules permit the MCP client to reach the server

The health endpoint works, but OAuth discovery returns 404

Check:

root web.config contains the MCP .well-known rewrite rules
the rules match your deployment path, such as /wfgen/mcp or /mcp
the IIS URL Rewrite module is installed

Claude Cowork opens a browser but shows a blank page

Check:

the WorkflowGen site is reachable from Claude’s service
firewall or IP filtering is not blocking Claude
root .well-known MCP OAuth discovery URLs work
the browser bridge URL is rewritten to show.aspx?qry=OAUTH_AUTH_BRIDGE

Codex authentication does not start

Check:

OAuthServerAllowLocalhostRedirects=true
the Codex server URL is https://<workflowgen-url>/wfgen/mcp
Codex is configured as Streamable HTTP
no bearer token is manually configured unless you intentionally use one

Codex does not show the Authenticate button after reconnecting

If Codex was already connected to the same MCP server, it may reuse a cached OAuth client, refresh token, or previous authorization state even after uninstalling and adding the MCP server again.

Try:

restart the Codex app
remove the MCP server, then add it again
use a different MCP server name temporarily
if available, clear the Codex MCP or OAuth cached state for that server

On the WorkflowGen side, check the MCP logs to confirm whether Codex is calling the OAuth endpoints. If there are no new OAuth authorize or token requests, Codex is likely still using local cached credentials.

Codex shows a localhost callback error

Check that OAuthServerAllowLocalhostRedirects=true.

This setting allows only loopback HTTP callbacks:

http://localhost:<port>/...
http://127.0.0.1:<port>/...
http://[::1]:<port>/...

It does not allow non-loopback HTTP callbacks.

The user sees fewer tools than expected

Check:

the user’s WorkflowGen profile
whether the user is a WorkflowGen administrator
whether the user is a process folder manager
McpAllowedScopes
whether the MCP client has reconnected after a scope/configuration change

If you change scopes or reconnect behavior, disconnect and reconnect the MCP client.

OAuth fails after changing secrets

Be careful with these values:

OAuthServerKeyEncryptionKey
OAuthServerBridgeTokenSigningSecret

Changing OAuthServerBridgeTokenSigningSecret invalidates in-flight browser bridge handoff tokens.

Changing OAuthServerKeyEncryptionKey after OAuth server signing-key data exists can make existing encrypted OAuth server data unreadable unless the signing keys and tokens are intentionally rotated or reset.

Where To Check Logs

Check:

WorkflowGen logs
IIS logs
MCP iisnode logs
browser developer tools network tab

For troubleshooting, temporarily set:

<add key="McpDiagnosticLogLevel" value="DEBUG" />

Return it to INFO or a less verbose level after troubleshooting.

Security Notes

WorkflowGen MCP uses OAuth bearer tokens for MCP client access.

Keep these points in mind:

Use HTTPS for the public MCP endpoint.
Keep OAuthServerKeyEncryptionKey and OAuthServerBridgeTokenSigningSecret secret.
Do not copy production secrets to non-production environments.
Use McpAllowedScopes to reduce the maximum tool categories exposed by the MCP server.
WorkflowGen business permissions are still enforced by the WorkflowGen Service Facade.
OAuthServerAllowLocalhostRedirects=true supports native MCP clients but only permits loopback HTTP callbacks.

For a read-only MCP deployment, set:

<add key="McpAllowedScopes" value="mcp:read" />

Summary

For most deployments:

Confirm WorkflowGen uses OIDC or SAML.
Install or upgrade the MCP files.
Convert /wfgen/mcp to an IIS child application.
Enable the OAuth server from the Configuration Panel.
Generate the OAuth server key encryption key and bridge token signing secret.
Keep McpAllowedScopes at the default full scope ceiling unless you want a restricted deployment.
Keep OAuthServerAllowLocalhostRedirects=true if you want Codex or similar native MCP clients.
Test with Claude Cowork.
Test with Codex.
Review visible tools with basic, process manager, and administrator users.

When the official WorkflowGen guides are published, use them as the authoritative reference.

Topic	Replies	Views
WorkflowGen v10.3.0 Preview Release Notes & Downloads	32	April 27, 2026
About the Administration category Administration	1019	November 16, 2016
About the Authentication category Authentication	865	November 16, 2016
About the Web API category Web API	803	November 16, 2016
WorkflowGen Plus 1.3.1 Release Notes & Downloads	587	October 16, 2018

Getting Started with WorkflowGen MCP Server Preview

Overview

What Is WorkflowGen MCP Server?

Important Notes

Requirements

WorkflowGen Authentication

HTTPS

MCP Client Support

Step 1: Install Or Upgrade WorkflowGen MCP Files

Step 2: Configure IIS

Step 3: Check Root Web.config Rewrite Rules

Step 4: Configure MCP OAuth

Step 5: Check Advanced Web.config-Only Setting For Codex

Step 6: Verify MCP Health And OAuth Metadata

Step 7: Connect From Claude Cowork

Changing granted scopes later

Step 8: Connect From Codex App

Step 9: Understand Which Tools Users See

Step 10: Suggested Demo Prompts

Troubleshooting

The MCP connector cannot reach the server

The health endpoint works, but OAuth discovery returns 404

Claude Cowork opens a browser but shows a blank page

Codex authentication does not start

Codex does not show the Authenticate button after reconnecting

Codex shows a localhost callback error

The user sees fewer tools than expected

OAuth fails after changing secrets

Where To Check Logs

Security Notes

Summary

Product

Resources

Company

Connect

Getting Started with WorkflowGen MCP Server Preview

Overview

What Is WorkflowGen MCP Server?

Important Notes

Requirements

WorkflowGen Authentication

HTTPS

MCP Client Support

Step 1: Install Or Upgrade WorkflowGen MCP Files

Step 2: Configure IIS

Step 3: Check Root Web.config Rewrite Rules

Step 4: Configure MCP OAuth

Step 5: Check Advanced Web.config-Only Setting For Codex

Step 6: Verify MCP Health And OAuth Metadata

Step 7: Connect From Claude Cowork

Changing granted scopes later

Step 8: Connect From Codex App

Step 9: Understand Which Tools Users See

Step 10: Suggested Demo Prompts

Troubleshooting

The MCP connector cannot reach the server

The health endpoint works, but OAuth discovery returns 404

Claude Cowork opens a browser but shows a blank page

Codex authentication does not start

Codex does not show the Authenticate button after reconnecting

Codex shows a localhost callback error

The user sees fewer tools than expected

OAuth fails after changing secrets

Where To Check Logs

Security Notes

Summary

Related topics

Product

Resources

Company

Connect