Power your agent
คำสั่งของผู้เผยแพร่เอง ไม่ใช่เอนด์พอยต์ของ PlugMCP
Host a copy with our keys and logs.
npx -y @formio/[email protected]Claude Code ไม่มีลิงก์ติดตั้งสำหรับคำสั่งแบบโลคัล ให้คัดลอกคำสั่งด้านล่างแล้วรันในเทอร์มินัล
PROJECT=<value> PROJECT_KEY=<secret> ADMIN_KEY=<secret> LICENSE_KEY=<secret> UAG_LICENSE=<secret> JWT_SECRET=<secret> PORT=<value> PROJECT_TTL=<value> TEMPLATE_SYNC=<value> JWT_EXPIRE_TIME=<value> PORTAL_SECRET=<secret> MONGO=<secret> MONGO_CONFIG=<value> UAG_DATABASE=<value> TASK_RUN_RETENTION_DAYS=<value> BASE_URL=<value> MCP_OAUTH=<value> TRUST_PROXY=<value> LOGIN_FORM=<value> CORS=<value> DEBUG=<value> claude mcp add formio-uag -- npx -y @formio/uag@2.0.0รันในเทอร์มินัล
{ "mcpServers": { "formio-uag": { "command": "npx", "args": [ "-y", "@formio/[email protected]" ], "env": { "PROJECT": "<value>", "PROJECT_KEY": "<secret>", "ADMIN_KEY": "<secret>", "LICENSE_KEY": "<secret>", "UAG_LICENSE": "<secret>", "JWT_SECRET": "<secret>", "PORT": "<value>", "PROJECT_TTL": "<value>", "TEMPLATE_SYNC": "<value>", "JWT_EXPIRE_TIME": "<value>", "PORTAL_SECRET": "<secret>", "MONGO": "<secret>", "MONGO_CONFIG": "<value>", "UAG_DATABASE": "<value>", "TASK_RUN_RETENTION_DAYS": "<value>", "BASE_URL": "<value>", "MCP_OAUTH": "<value>", "TRUST_PROXY": "<value>", "LOGIN_FORM": "<value>", "CORS": "<value>", "DEBUG": "<value>" } } }}claude_desktop_config.json
URL แบบรีโมตหรือคำสั่งบนเครื่องของคุณ? การติดตั้งสองแบบต่างกันอย่างไร
รันบน PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
เปิดจากผู้เผยแพร่
The Universal Agent Gateway (UAG) leverages the Model Context Protocol (MCP) to enable in-process agentic automation using Form.io. It provides to an AI Agent the same thing that our JavaScript Renderer provides to a human; an interpretation of the Form JSON schema into an understandable format. In the case of UAG, it transforms the Form JSON model into an AI readible markdown format so that the Agent can easily understand the purpose and structure of the data that needs to be collected.
The Form.io Universal AI Agent Gateway (UAG) — an MCP server for agentic form automation with AI agents
There are two primary scenarios that the UAG enables:
For a working example of this flow, please try out the Conversation Form Example.
For more information on Agentic workflows, checkout the dedicated Agentic Workflows section. For a working example of this flow, please try out the Agentic Workflow Example.
One of the many benefits that the UAG has to offer is the ability to inject Dynamic Context into an AI processing cycle. This is achieved from the dynamic nature of the Form JSON schemas that can easily be modified and deployed to any environment without the need to update your application or re-train the agents within the process. Because of this, dynamic context changes can be injected seamlessly into an existing running process which will automatically update the behaviors of the Agents utilizing the UAG.
There are three working examples in this repo, each spinning up a Form.io server alongside the UAG with Docker Compose. Pick the one that matches what you are building.
There is also a Flow Viewer — a small proxy that shows every leg of an agentic run live, which is the fastest way to see what an agent is actually doing.
This file is the main reference: what the UAG is, how to configure a form for it, how to deploy it, and how to troubleshoot it. The rest of the documentation lives next to the code it describes.
One of the more powerful features of the UAG is the agent_provide_data tool. This tool provides the ability to instruct a generically trained agent how to analyze existing submission data, and then produce its own data by following a configurable Criteria. This behavior historically could only be achieved using a specifically trained agent, which does not provide any benefits of dynamic configurability that the Form.io platform offers. This tool is able to achieve this goal by providing a generally trained agent with the necessary "context" it needs to accurately produce its own data as part of an automated workflow. This feature is particularly helpful if you wish to utilize the UAG within an Agentic Workflow, where the AI Agent is capable of understanding structured data, and then contribute its own data by following the configured Criteria "context" provided by the UAG.
For example, let's suppose you wish to automate the backend administration behind a College Application Process. In this example, a potential student submits an application that consists of many different fields of data, such as Academics, Extra curricular activities, Honors, Volunteer work, as well as possibly written Essays. Historically, these applications would be reviewed by an administrator in order to assess the candidates qualifications for acceptance. With the agent_provide_data tool, it is now possible to automate this process as the following diagram illustrates.
To achieve this feat, the agent_provide_data tool utilizes the following information, which is then fed to the Generally trained agent to produce its own submission data.
agent_provide_data process.To configure a form to use the agent_provide_data tool, you must first designate a section of your form that will be read and used by the AI Agent. This is similar to what you would see in a form that says "For Office Use Only", but instead of a Human contributing to the values of this section, it will be an automated AI Agent. There are two types of fields that can be added to a form to configure it for use by the agent_provide_data tool: Criteria and Agent Fields
A complete setup is four steps, and all four are required:
uag (described below) — without this the UAG will not register the form at all.For a working reference containing all four, see the Agentic Workflow example.
uagThe UAG only registers forms that carry the uag tag. Any form without it is invisible to every agent and to every tool, including get_forms. In the Form Builder this is set under Form Settings → Tags; in a form's JSON it looks like this:
"tags": ["uag"]
This is worth checking first whenever an agent insists that a form does not exist, because a missing tag produces no error anywhere — the form simply is not there as far as the agent is concerned. Note also that newly tagged forms are picked up on the next project cache expiry, so allow up to PROJECT_TTL seconds (see Project Cache and TTL).
The first thing that needs to be configured is a special Content Component that instructs the AI Agent how to interpret the data. For example, here is a Criteria content block that was written to instruct an AI Agent on how to assess the submission of a College Application Essay.
The goal of this content is to be written as you would write an instruction manual for a new employee who needs to learn how to analyze and understand the submission data that is provided. It is also used to instruct the AI Agent on how to populate the form values that are configured for that criteria. Once this criteria is written, It will then need to be "flagged" as a UAG field by adding a property called uag and the value of that property is to be thought of as the persona of the Agent. This provides the ability to have more than one agent assume different roles as it analyzes the submission data to provide their own values. In addition, the "criteria" content will also need to be provided a uagField property with the value equal to criteria. Below is what a properly configured uag criteria content component looks like.
Once you have added this Criteria Content Component to your form, the next object is to add the fields you wish for the Agent to populate. These are called the Agent Fields.
Anywhere in your form, you can drag and drop fields that can be flagged as Agent fields. Using the example above, imagine your form has a "For Office Use Only" section (maybe a Panel). Within this panel, the first thing you see is a Content Component with instructions on how the following fields should be filled out. This is the Criteria we just described. The next thing that follows are the fields that the Agent needs to populate. Any field that with a property of uag set to the same value as the Criteria content component will be used as the Agent fields.
For example, lets suppose that we have created a form for College Application essays. Below the Criteria may be some fields that the Agent needs to "score" the essays according to the provided Criteria. This may look like the following...
In order to "flag" each of these fields as Agent Fields, you simply need to add the uag property with the same persona flag that was giving to the Criteria content.
Nested Components
It is also possible to "flag" a collection of fields with the uag property. This can be done by wrapping all of these fields within a Nested Component (such as Panel, Container, Fieldset, etc), and then all the fields within this nested component will be added to the context of that agent with that persona.
It is also possible to achieve multiple personas per-form. This is very helpful if there are several isolated evaluations that need to occur within a process. For example, if we look at the flow chart diagram shown above, we can see a College Application Form. The first agentic evaluation occurs when the form is submitted by the applicant, where their application is assessed to be accepted or not. From that point, IF the applicant is accepted, a completely different evaluation needs to occur to award Financial Aid or even Scholarships to the applicant. These would require completely different criteria to assess the submission data differently from one another.
To achieve this, you simply need to "flag" the components uag property value differently with the persona that applies for that field. For the example above, you would add a Content component to assess if the applicant should be accepted, and then provide the following uag property to that content. uag="application". Any fields that need to be filled out by the AI Agent for application approval would also be flagged with the property uag="application". Then, in a different section of the form, you would create a separate Content component with the criteria for the financial admin AI Agent. This content would be flagged with the property uag="finance". Any fields that the finance admin AI Agent need to fill out would also be flagged with uag="finance". This provides a truly flexible and dynamic AI engagement where multiple generically trained agents can be "taught" dynamically how to read and interpret data that is only relevant to that part of the agentic process.
Agent fields do not have to sit next to their criteria, either. A status field in one panel can be flagged uag="application" while the field beside it is flagged uag="finance", which is how a single workflow field can be owned by whichever persona is responsible for that stage.
Multiple personas on a form are only useful if something triggers the later ones. Because each persona writes to the submission, the natural trigger for the second persona is the first persona's write.
This is configured with a second Webhook action that fires on update rather than create, narrowed by a condition on a field that the first persona sets:
{
"name": "webhook", "handler": ["after"], "method": ["update"], "priority": 0,
"condition": {
"conjunction": "all",
"conditions": [
{ "component": "status", "operator": "isEqual", "value": "scholarshipEvaluation" }
]
},
"settings": {
"method": "post",
"url": "http://formio-uag-claude:3300/agent/claude/agent_provide_data",
"headers": [{ "header": "x-token", "value": "<your project API key>" }],
"transform": "payload = {formName: 'application', submissionId: payload.submission._id, persona: 'finance'};",
"block": false
}
}
In the college application workflow, the admissions persona sets status to scholarshipEvaluation only for applicants on the scholarship track, so only those submissions wake the finance persona. Applicants who were simply accepted or declined never trigger it.
Avoid loops. The second persona also writes to the submission, which fires the same
updatewebhook again. Make sure each persona's own write cannot re-match the condition that triggered it — in the example above the finance persona setsstatustoscholarshipGranted, which no longer satisfies the condition, so the workflow terminates. A condition that stays true after the persona runs will loop indefinitely and consume API credits until you stop the container.
A complete, runnable version of this two-persona workflow is in the Agentic Workflow example.
In order to aid in the "agentification" of the UAG, we have also provided some "integrations" that can be used to directly communicate with the Generically trained AI Agents to utilize the UAG to accomplish automated AI Agent behaviors. This involves providing a single API endpoint that is capable of triggering the AI Agent process along with the connections to your deployed UAG. These API endpoints can then be triggered using a simple Webhook action within a form to start an Agentic process as the result of a Form submission. Here is a diagram of how specific integrations can be used to achieve a single API call to accomplish an agentic task.
Each integration runs its own MCP client and connects out to the UAG, so the UAG does not need to be publicly accessible for these to work — it only needs to be reachable from the integration, such as over a private Docker network or on localhost.
These integrations can be found within the integrations folder. The following integrations are provided to enable automated Agentic workflows.
Please click on one of these integration links to read how they work.
Integrations are versioned independently of the UAG. They share no code with it — each one runs its own MCP client and talks to the UAG over MCP/HTTP — so an integration release does not imply a UAG release, and vice versa. Matching version numbers between the two would be misleading rather than helpful.
Use this matrix to pick a compatible pair. Each row records the UAG range an integration version is known to work against:
Both artifacts are published on every release where their own version changed:
@formio/uag, @formio/uag-claudeformio/uag, formio/uag-claudeWhen adding a row: bump the integration's own package.json version. CI publishes it to npm and Docker Hub on the next release tag, and skips it automatically when that version is already published — so a core-only release does not rebuild an unchanged integration.
The examples/ compose files reference formio/uag and formio/uag-claude without a tag, so they always pull the current release and cannot drift out of date. If you need a reproducible stack, pin both images to a compatible pair from the matrix above.
The UAG can be thought of as consisting of many layers of functionality. Each layer is broadly either serving to fetch dynamic context, or submit deterministic data structures. The following layers are leveraged within the UAG:
Here is a diagram to understand how all of these layers are organized to make up the UAG.
The following tools provided by the UAG can be described as follows:
While the UAG can be used as a stand-alone system to enable the interaction between AI agents and dynamic JSON forms, the true power of this platform will be realized when developers extend the capabilities of this platform to solve industry specific use cases through the use of Custom Modules and Tools. It is possible for a developer to create a Module that introduces a number of custom tools, actions, and pre-defined resources and forms to achieve interactions with industry specific technologies. They are able to achieve this custom integration capabilities through the use of the following mechanisms:
Form.io aims to enable developers to build and contribute their own custom modules to the broader community through GitHub and NPM.
Once a custom module is developed, anyone can install that module (via NPM) and then easily use your module in the following way...
This is just an example.
import { UAGServer } from '@formio/uag';
import { ExampleUAG } from '@example/uag';
import Express from 'express';
try {
(async function () {
const server = new UAGServer();
server.use(ExampleUAG);
const app = Express();
app.use(await server.router());
const port = process.env.PORT || 3200;
app.listen(port, () => {
console.log(`Form.io UAG server running on port ${port}`);
console.log(`Visit http://localhost:${port} to access the application`);
});
})();
} catch (error) {
console.error('Failed to start server:', error);
process.exit(1);
}
To get started in building your own custom module, go to the help documentation at Modules Readme.
The following sections describe the process of creating a running instance of UAG, connecting it to the Form.io Platform, and configuring an AI agent to use it.
This documentation focuses on using UAG with Form.io Open Source. For documentation on using UAG with Form.io Enterprise, refer to https://help.form.io/uag.
Before deploying, it is worth deciding which side opens the connection to the UAG's /mcp endpoint, because that single decision determines whether the UAG needs to be publicly accessible.
With a local MCP client, your application connects out to the UAG, calls the tools itself, and passes the results on to whichever model it is using. Nothing dials back in, so the UAG can stay entirely inside your network. This is how the Claude Integration works, and it is the recommended model for server-to-server and webhook-triggered automation — including running the whole stack on a developer machine.
If you are using the published Claude integration image, this requires
formio/uag-claude:1.3.0or newer. Earlier images handed the MCP server URL to the Anthropic API as a remote connector, meaning the API dialed into your UAG and a public URL was mandatory. An older image pointed at a private address fails with a400from the Anthropic API readingConnection error while communicating with MCP server, which looks like a UAG fault but is not one.
With a remote MCP client, the agent lives outside your network and connects in, so /mcp and the .well-known OAuth discovery endpoints must be publicly reachable over HTTPS, and BASE_URL must be that public URL. See Domain and URL Configuration.
Both models can be used against the same UAG deployment at the same time.
A remote agent authenticates through the browser-based OAuth (PKCE) flow. A local client has no browser, so it exchanges a server-side key for an access token using the client_credentials grant against {{ BASE_URL }}/auth/token, then sends that token as a Bearer token on its /mcp requests.
The client_id must be prefixed with the project name — which is formio-oss for Open Source deployments:
POST /auth/token
Content-Type: application/json
{
"grant_type": "client_credentials",
"client_id": "formio-oss-x-admin-key",
"client_secret": "{{ ADMIN_KEY }}"
}
For Enterprise, use the project name from your project endpoint together with the project API key — for example "client_id": "myproject-x-token" with "client_secret": "{{ PROJECT_KEY }}".
The response contains an access_token, which is passed to the UAG as Authorization: Bearer {{ access_token }}. Tokens expire according to JWT_EXPIRE_TIME, so long-running clients should cache the token and refresh it before it expires. See integrations/claude/auth.js for a working implementation.
There are currently two run-time environments that work with the UAG:
Running the UAG in Docker enables a wide range of deployment options into common hosting environments such as AWS and Azure. Additionally, it allows for the use of common orchestration runtimes such as Kubernetes and Docker Compose. The container that you will run the UAG is as follows:
formio/uag
This container can be run in two ways:
docker run command.The recommended way to launch the UAG is through Docker Compose. This enables you to orchestrate several of the containers to run within a single instance to provide a more seamless and simple way of managing your deployments. Here is a simple example of how to run both the Form.io UAG + Form.io OSS server on the same instance.
docker-compose.yml
services:
mongo:
image: mongo
restart: always
volumes:
- ./data/db:/data/db
environment:
- MONGO_INITDB_ROOT_USERNAME
- MONGO_INITDB_ROOT_PASSWORD
formio:
image: formio/formio:rc
restart: always
links:
- mongo
depends_on:
- mongo
environment:
PORT: 3000
DEBUG: formio.*
NODE_CONFIG: '{"mongo": "mongodb://mongo:27017/formio-oss", "jwt": {"secret": "CHANGEME"}, "mongoSecret": "CHANGEME"}'
ROOT_EMAIL: [email protected]
ROOT_PASSWORD: CHANGEME
ADMIN_KEY: CHANGEME
ports:
- "3000:3000"
formio-uag:
image: formio/uag
restart: always
links:
- formio
depends_on:
- formio
environment:
PORT: 3200
DEBUG: formio.*
PROJECT: http://formio:3000
ADMIN_KEY: CHANGEME
JWT_SECRET: CHANGEME
JWT_EXPIRE_TIME: 525600
LOGIN_FORM: http://localhost:3000/user/login
# The address clients reach the UAG at — this is the UAG's own port,
# not the Form.io server's. See the BASE_URL section below.
BASE_URL: http://localhost:3200
ports:
- "3200:3200"
This can be run by typing the following...
docker compose up -d
Here are some examples of running the UAG using the docker run command.
UAG pointed to an Open Source server
docker run -d \
-e "PROJECT=https://forms.mysite.com" \
-e "ADMIN_KEY=CHANGEME" \
-e "JWT_SECRET=CHANGEME" \
-e "BASE_URL=https://forms.mysite.com" \
-e "LOGIN_FORM=https://forms.mysite.com/user/login" \
-e "PORT=3200" \
--restart unless-stopped \
--network formio \
--name formio-uag \
-p 3200:3200 \
formio/uag
UAG pointed to a Form.io Enterprise Server
docker run -d \
-e "PROJECT=https://forms.mysite.com/myproject" \
-e "PROJECT_KEY=CHANGEME" \
-e "UAG_LICENSE=YOUR-LICENSE" \
-e "JWT_SECRET=CHANGEME" \
-e "PORTAL_SECRET=CHANGEME" \
-e "BASE_URL=https://forms.mysite.com" \
-e "LOGIN_FORM=https://forms.mysite.com/myproject/user/login" \
-e "PORT=3200" \
--restart unless-stopped \
--network formio \
--name formio-uag \
-p 3200:3200 \
formio/uag
Once it is running, you can then navigate to the following to access both the OSS Deployment + UAG Server
In both the Node.js runtime environment as well as Docker, the way to control the UAG is through the use of Environment Variables and Modules.
This module can be configured in many ways. One of those ways is through the use of Environment Variables, which are documented as follows.
By default, the UAG uses a TTL to "fetch" any of the project assets and register them and cache them into the UAG. What this means is that if you make any changes to your underlying project forms and resources (either directly or through a deployment), you need to wait a maximum of the TTL setting (in seconds) to see any updates that have been made. For example, if the TTL is set to 900 (or 15 minutes), and you make a change to any forms and resources, you must wait at most 15 minutes to see any of these changes take effect into the UAG. It should be noted that when a "refresh" occurs, an API call to the "export" method is called on the underlying project endpoint. This is a processor intensive API call, so it is not recommended to set the TTL to any value less than 60. A value of 0 is interpreted as "No TTL", which means the only way to refresh the project forms and resources, a UAG reboot is necessary.
Here is a table explaining how this parameter can be used.
This cache is the reason a form edit does not appear to take effect immediately. Anything that changes what the agent knows — adding the uag tag, rewriting a Criteria content component, adding or removing Agent Fields — only reaches the agent after the next expiry. When you are actively iterating on criteria, restarting the UAG re-registers the project immediately instead of waiting:
docker restart formio-uag
There are 3 different "domain" environment variables that matter, and it is important to understand how to configure them depending on your use case. Whether any of them need to be public depends on how agents connect — see How Agents Connect.
If a remote agent connects into your UAG, these must be configured correctly and publicly, or the agent will not be able to authenticate. If you only use a local MCP client, all three can point at private or localhost addresses.
The PROJECT environment variable is used to establish a connection from the UAG server to the project endpoint (for Enterprise) or OSS base url. This does NOT need to be a public DNS entry, but rather a URL that connects the UAG container to the Server container. The following examples illustrate how this would be configured.
If you are using a local connection, such as within a Docker Compose file, you can configure the PROJECT environment variable to point directly to the local url as follows.
docker-compose.yml
services:
formio:
image: formio/formio:rc
restart: always
environment:
PORT: 3000
ADMIN_KEY: CHANGEME
formio-uag:
image: formio/uag
restart: always
links:
- formio
depends_on:
- formio
environment:
PROJECT: http://formio:3000
ADMIN_KEY: CHANGEME
In this example, we have Docker Compose launching the OSS Form.io container with the ADMIN_KEY set for this deployment, the UAG is connected using http://formio:3000 which is the local Docker network name (provided using the "links" property in the docker compose file).
If you are using the Enterprise Form.io server within a local environment to the UAG, then you will need to ensure that the UAG connects to an independent project using the PROJECT_KEY as follows.
docker-compose.yml
services:
formio-enterprise:
image: formio/formio-enterprise
restart: always
environment:
PORT: 3000
formio-uag:
image: formio/uag
restart: always
links:
- formio-enterprise
depends_on:
- formio-enterprise
environment:
PROJECT: http://formio-enterprise:3000/myproject
PROJECT_KEY: CHANGEME
If your project does not reside on the same network as the UAG, you can provide the domain name as the PROJECT as follows.
docker-compose.yml: Connected to Enterprise (formio/formio-enterprise)
services:
formio-uag:
image: formio/uag
restart: always
environment:
PROJECT: https://forms.mydomain.com/myproject
PROJECT_KEY: CHANGEME
docker-compose.yml: Connected to Open Source (formio/formio)
services:
formio-uag:
image: formio/uag
restart: always
environment:
PROJECT: https://forms.mydomain.com
ADMIN_KEY: CHANGEME
The BASE_URL tells the UAG what URL it is reachable at. This value is published within the .well-known definitions for the OIDC (PKCE) authentication, and is used for the authentication callbacks.
BASE_URL is always required, including for local clients. The UAG's authentication provider is only enabled when it is set, so if you omit it, /mcp returns a 401 for every request and the /auth/token and /.well-known/* endpoints do not exist at all (404). A 404 on /auth/token is the clearest signal that BASE_URL is missing.
What it needs to be set to depends on how agents connect:
BASE_URL: https://forms.mysite.com.BASE_URL: http://localhost:3200 or BASE_URL: http://formio-uag:3200 within a Docker network.If a remote agent cannot authenticate, a mismatched BASE_URL is the most common cause: the agent reads this value from the discovery document and will follow it, so if it points somewhere the agent cannot reach, authentication fails even though the UAG itself is running correctly.
This is the URL to the Login form of your Project or OSS deployment. It provides the form that is loaded when a user navigates to {{ BASE_URL }}/auth/authorize. If you navigate to this URL, and the page says that you cannot load the form, then this is because your LOGIN_FORM environment variable is not pointing to the correct form JSON endpoint of your project.
This is only used by the browser-based login flow, so it needs to be reachable by the browser performing that login. A local MCP client authenticating with the client_credentials grant never loads this page.
For example:
LOGIN_FORM: https://forms.mysite.com/myproject/user/loginLOGIN_FORM: https://forms.mysite.com/user/loginWith the Node.js environment, you can import the UAG within a locally running Node.js and Express.js environment. This works by first importing the UAG module and "use"ing it within an Express.js application. First, you will install the UAG inside of your Node.js Express application like the following.
npm install --save @formio/uag
or
yarn add @formio/uag
You can then mount the UAG within your Express application, as seen in the following example:
import 'dotenv/config';
import Express from 'express';
import { UAGServer } from '@formio/uag';
try {
(async function () {
const server = new UAGServer();
const app = Express();
app.use(await server.router());
const port = process.env.PORT || 3200;
app.listen(port, () => {
console.log(`Form.io UAG server running on port ${port}`);
console.log(`Visit http://localhost:${port} to access the application`);
});
})();
} catch (error) {
console.error('Failed to start server:', error);
process.exit(1);
}
There is also a way to extend the functionality of the UAG through the use of modules, which is documented in the Modules Readme
When using the UAG with the Form.io Enterprise Server, you unlock several benefits with regards to managing the Forms and Resources within the UAG. Some of the features that you gain with our Enterprise Server include:
In order to run the UAG against an Enterprise Server, you need to provide a few Environment variables that are different from the OSS runtime of this module. The following environment variables are required to run against an Enterprise Project.
Once you have these environment variables in place, you should be able to run the UAG pointed to your Enterprise Project.
Most UAG problems are configuration, not code, and they tend to surface far from their cause — a missing tag looks like a missing form, and a missing BASE_URL looks like a permissions error. The table below maps the symptoms you are likely to see back to what actually produces them.
If none of these apply, run one of the examples to confirm the environment itself is sound, then compare its configuration against yours.
The Form.io Universal AI Agent Gateway (UAG) — an MCP server for agentic form automation with AI agents
{ "mcpServers": { "formio-uag": { "command": "npx", "args": [ "-y", "@formio/[email protected]" ], "env": { "PROJECT": "<value>", "PROJECT_KEY": "<secret>", "ADMIN_KEY": "<secret>", "LICENSE_KEY": "<secret>", "UAG_LICENSE": "<secret>", "JWT_SECRET": "<secret>", "PORT": "<value>", "PROJECT_TTL": "<value>", "TEMPLATE_SYNC": "<value>", "JWT_EXPIRE_TIME": "<value>", "PORTAL_SECRET": "<secret>", "MONGO": "<secret>", "MONGO_CONFIG": "<value>", "UAG_DATABASE": "<value>", "TASK_RUN_RETENTION_DAYS": "<value>", "BASE_URL": "<value>", "MCP_OAUTH": "<value>", "TRUST_PROXY": "<value>", "LOGIN_FORM": "<value>", "CORS": "<value>", "DEBUG": "<value>" } } }}เครื่องมือ
ยังไม่มีรายการเครื่องมือ เซิร์ฟเวอร์แบบรีโมตจะได้รายการหลังการตรวจสอบสถานะครั้งแรก
FAQ
คัดลอกคอนฟิก stdio สำหรับ Cursor, Claude Desktop, Claude Code หรือ VS Code ได้ในหน้านี้ คอนฟิกนี้ใช้การติดตั้งของผู้เผยแพร่ ไม่ใช่พร็อกซีของ PlugMCP
ผู้เผยแพร่ระบุตัวแปรสภาพแวดล้อมเหล่านี้: PROJECT, PROJECT_KEY, ADMIN_KEY, LICENSE_KEY, UAG_LICENSE, JWT_SECRET, PORT, PROJECT_TTL, TEMPLATE_SYNC, JWT_EXPIRE_TIME, PORTAL_SECRET, MONGO, MONGO_CONFIG, UAG_DATABASE, TASK_RUN_RETENTION_DAYS, BASE_URL, MCP_OAUTH, TRUST_PROXY, LOGIN_FORM, CORS, DEBUG
Uag ทำงานแบบโลคัลผ่าน stdio
ตรวจสอบล่าสุดเมื่อ 2026-11-13 The Form.io Universal AI Agent Gateway (UAG) — an MCP server for agentic form automation with AI agents