MCP Servers
This functionality is available since version 2026 R1 Patch 6.
Overview
MCP servers provide a way to expose tools that allow external AI applications to interact with the WEBCON platform in a controlled and configurable manner.
They implement the Model Context Protocol (MCP) server as defined in the specification.
In WEBCON, there are two types of MCP servers: general MCP server and application-specific MCP server.
The general MCP server is a single, shared server that exposes standard, built-in tools.
Application-specific MCP servers are assosiated with applications. Each MCP server runs independently and is tailored to the APIs of the application it is created from.
MCP servers are not enabled by default and must be started explicitly by an administrator.
Tools exposed by the general MCP server
This section lists the built-in tools provided by the general MCP server and summarizes what each tool returns or allows you to do.
Get current user's profile
Returns current user's profile:
- name
- BPS ID (user's unique id)
Get my tasks
This tool returns the current user's tasks. It allows filtering by new and CC tasks, and sorting by modification and creation date. It is similar to My tasks functionality on the Portal.
Get element data
This tool allows to retrieve details of a given workflow instance, including:
- form type, step and workflow names,
- names and values of its form fields (excluding data rows, tables, reports, widgets and HTML fields),
- list of attachments,
- comments,
- currently assigned person
- date of modification.
Get attachment
This tool can retrieve the content of an attachment. Depending on the capabilities of the external AI application, the content can be downloaded, displayed or used for analysis and summarization by an LLM.
Get related elements
This tool returns instances related to a given workflow instance. This is the same data as presented in related instances view available in form info panel.
Get search results
This tool returns workflow instances matching the provided search criteria. It should be used together with the output from Get all search filters.
Apart from accepting keywords, it allows ordering results by relevance (rank), creation date, or modification date. Optionally, a date filter can be added to specify a time range.
The tool also returns a search query URL. With this URL external AI application can suggest continuing and expanding the search in the Portal
Get all search filters
This tool returns avaiable search filters for given keywords. The keywords should be generated by the external AI application based on the user message and search intent.
Output of that tool should be used as part of the input to Get search results tool.
Tools exposed by the application-specific MCP server
The application-specific MCP server exposes tools derived directly from the API Definitions specific with a given application1, and does not include any other tools automatically. To be included as a tool, an API Definition must be active and support OAuth2 authentication.
MCP tools mapping rules
The following rules apply to all MCP tools generated from API Definitions, regardless of their specific type.
- The MCP tool name is derived from the API Definition name (
{name}) and running mode:- Get data from the data source:
DataSource_{name} - Execute automation:
Automation_{name} - Actions on a workflow instance:
ActionOnWorkflow_{name}_{suffix}, where suffix depends on API Definition configuration:- get element instance data =
get - save element instance =
save - Start new workflow =
createNew - Move to next step =
{Url suffix}
- get element instance data =
- Get data from the data source:
- The MCP tool description is taken directly from the API Definition documentation.
- The input schema is generated from the API Definition input parameters, and may be extended with additional technical parameters required by REST API mapping (e.g. instance ID).
- The output schema is generated directly from the API Definition response.
API Definitions with running modes Get data from the data source and Execute automation are mapped to a single MCP tool each. Actions on a workflow instance is mapped to multiple tools (described in next chapter).
For important details about how data visibility works for tools generated from Get data from the data source, see Authentication and authorization.
| Running mode | MCP Tool Mapping | Operational Scope |
|---|---|---|
| Get data from the data source | 1 MCP tool | Read-only |
| Execute automation | 1 MCP tool | Configuration-dependent (automation definition) |
| Actions on a workflow instance | 1-N MCP tools | Configuration-dependent (API Definition) |
Tools for Actions on a workflow instance
For API Definitions of type Actions on a workflow instance, one or more MCP tools may be created, depending on the selected options supported:
- Get element instance data - one MCP tool
- Save element instance - one MCP tool
- Start new workflow - one MCP tool
- Move to next step - multiple MCP tools, one for each URL suffix defined
Note that each MCP tool will have the same description. It is recommended to add a short description of each selected option in the API Definition documentation.
Authentication and authorization
MCP servers use the OAuth2 authorization flow for authentication.
All MCP tool operations are executed in the context of the currently logged-in user. Access to tools and execution of operations are restricted according to the user's assigned roles and privileges.
This ensures that MCP server interactions respect the same security model and permission boundaries as direct platform usage.
Access restrictions
If an API Definition has an access restriction rule, that rule is also respected during MCP tool execution. A tool may be visible in the MCP client, but its execution can still be blocked for the current user. If the rule does not return POSITIVE, TRUE, or 1, the MCP tool call is rejected with the HTTP 403 status.
When additional control is required, the access restriction rule can be used to limit tool usage to selected users or groups. For example, the CURRENT USER IS ONE OF business rule can be used to allow or deny access depending on whether the logged-in user belongs to a specified group.
Even if a tool is visible in MCP client, the current user may still be unable to execute it. In that case, the call will be rejected if the API Definition access restriction rule is not met.
Data returned by data source tools
For tools generated from API Definitions in Get data from the data source mode, the data returned by the tool depends on the configured data source.
When the source uses WEBCON internal mechanisms such as Internal BPS Views, platform privileges are respected.
For other source types, such as SQL, REST, or fixed lists, the tool returns data according to the data source configuration. In these cases, results are not automatically limited by the logged-in user's WEBCON privileges.
Configuration and setup
This section outlines the prerequisites and administrative steps required to enable MCP servers, start server instances, and obtain the information needed to configure external MCP clients.
Starting the MCP server
An application-specific MCP server instance can be started from the application settings. The general MCP server can also be started there.
The same location is used to restart or stop the MCP server when needed. The application-specific MCP server must be restarted after adding new API Definitions or changing names, descriptions or input/output parameters of the existing ones.
MCP servers are not automatically started after Portal restart.
Detailed MCP server specification
Each MCP server exposes a detailed technical specification at <WEBCON portal url>/api/mcp/server/{server_id}/docs. Exact links are available on the MCP server administration page in Designer Studio.
This endpoint provides a Swagger / OpenAPI specification describing the MCP server. The specification includes detailed information about available operations, input and output schemas, supported connection methods, and required MCP client configuration settings.
This document is intended as the authoritative source for integrating external MCP clients with a specific MCP server.
Registering API application
To enable MCP server access for external applications, an API application must be registered in the WEBCON platform administration panel.
The API application of type user context and authentication type Authorization code must be configured.
Detailed instructions for registering an API application are available in the documentation
The required OAuth2 scopes will be listed in MCP Server specification after it's started.
Configuring external MCP clients
External tools acting as MCP clients must be configured to connect to a specific MCP server instance.
MCP servers support HTTP (Streamable HTTP) transport in accordance with the MCP specification.
Examples of applications supporting MCP include:
The details of the configuration of individual clients are outside the scope of this documentation — refer to the documentation of the respective MCP client.
For OAuth2 authentication to work correctly, administrators must add the redirect URL of the MCP client application to the list of registered redirect URLs in the API application configuration.
Only redirect URLs explicitly registered in the API application will be accepted during the OAuth2 authorization flow.