Connect OutSystems to ChatGPT: Audit App Versions and Deployments

If you need to connect OutSystems to ChatGPT to audit application versions, orchestrate cross-environment deployments, or track infrastructure health, you need a Model Context Protocol (MCP) server. This server acts as the critical translation layer between ChatGPT's tool calls and the OutSystems LifeTime REST API.

If your team uses Claude, check out our guide on connecting OutSystems to Claude or explore our broader architectural overview on connecting OutSystems to AI Agents.

Giving a Large Language Model (LLM) read and write access to an enterprise low-code platform is a massive engineering challenge. You must navigate asynchronous deployment pipelines, handle complex environment mapping, and manage conflict resolution payloads. Every time you want to expose a new LifeTime API endpoint, building custom MCP infrastructure means writing and maintaining boilerplate JSON-RPC handlers.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for OutSystems, connect it natively to ChatGPT, and execute complex deployment workflows using natural language.

The Engineering Reality of the OutSystems API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, implementing it against the OutSystems LifeTime API is exceptionally painful due to its specific architectural quirks.

If you decide to build a custom MCP server for OutSystems, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with OutSystems:

Asynchronous State Machines for Deployments

OutSystems deployments do not happen instantly. When an LLM wants to promote an application from Development to Testing, a standard POST request does not return a completed deployment. The LifeTime API requires creating a deployment plan, checking a secondary endpoint for conflicts, explicitly executing a start command on a third endpoint, and then continually polling a status endpoint until it returns a terminal state (e.g., finished_successful). Your MCP server must expose all of these discrete steps as individual tools, and the LLM must be prompted to handle the state machine logic.

Polling for Asynchronous Binary Packaging

When requesting the source code for an OutSystems application or module, the API kicks off an asynchronous packaging job. The initial request returns a PackageKey and a status of running or queued. The client must repeatedly poll the status endpoint using this key. Only when the status changes to Done will the API return a short-lived download URL. Instructing an LLM to navigate this requires strict schema descriptions instructing it to hold state and poll.

Strict Environment Key Mapping

Unlike typical REST APIs that use human-readable environment names or simple integer IDs, OutSystems relies heavily on cryptographic string Key values. To execute a deployment, the LLM must first fetch the source environment Key and the target environment Key, then map the application Key into a specific ApplicationOperations payload array. If your MCP schemas are not perfectly defined, the LLM will hallucinate these keys and the API will reject the request.

Rate Limit Passthrough Reality

When dealing with high-frequency polling (like checking a deployment status), it is critical to understand rate limits. Factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream API returns HTTP 429, Truto passes that error to the caller. Truto normalizes upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller (or the orchestration layer driving the LLM) is responsible for retry and backoff logic. Do not expect the MCP server to magically absorb OutSystems rate limit errors.

OutSystems to ChatGPT Quickstart Guide

If you want the fastest path from a fresh Truto account to ChatGPT calling the OutSystems API, follow these steps. Deeper architecture and security details live in the sections below.

What you need:

• A Truto account with API access.
• An OutSystems LifeTime API token.
• A ChatGPT Pro, Plus, Business, Enterprise, or Education seat with Developer mode available.

Step 1: Connect OutSystems as an Integrated Account

In the Truto dashboard, open Integrated Accounts -> New Integrated Account, select OutSystems, and provide your LifeTime environment URL and API token. Truto securely stores these credentials and uses them to proxy requests from the MCP server.

Step 2: Grab your Integrated Account ID

You can copy the integrated_account_id from the account detail page in the UI or list it via the API:

curl https://api.truto.one/integrated-account \
  -H "Authorization: Bearer $TRUTO_API_TOKEN"

Step 3: Generate the OutSystems MCP Server

Truto scopes a unique MCP endpoint to this specific OutSystems environment. You can create this server using either the Truto UI or the API.

Option A: Via the Truto UI

1. Navigate to the integrated account page for your OutSystems connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (name, allowed methods like read/write, and tag filters).
5. Copy the generated MCP server URL.

Option B: Via the API Make a POST call to scope an MCP endpoint to that account. You can filter by methods and tags to constrain what ChatGPT can touch:

curl -X POST https://api.truto.one/integrated-account/$INTEGRATED_ACCOUNT_ID/mcp \
  -H "Authorization: Bearer $TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "OutSystems for ChatGPT",
    "config": {
      "methods": ["read", "write", "custom"],
      "tags": ["applications", "deployments", "environments"]
    }
  }'

The response contains a url field (e.g., https://api.truto.one/mcp/<token>). That single URL carries routing and authentication - treat it like a secret.

Step 4: Connect the MCP Server to ChatGPT

You can register this server with your LLM client using either the UI or a configuration file.

Option A: Via the ChatGPT UI

1. In ChatGPT, navigate to Settings -> Apps -> Advanced settings.
2. Enable Developer mode.
3. Under MCP servers / Custom connectors, click to add a new server.
4. Give it a name (e.g., "OutSystems Prod").
5. Paste the Truto MCP URL into the Server URL field and save.

Option B: Via Manual Config File If you are running a local MCP proxy or using a framework that accepts standard MCP configuration files, you can define it using Server-Sent Events (SSE):

{
  "mcpServers": {
    "outsystems_prod": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/YOUR_SECURE_TOKEN"
      ]
    }
  }
}

ChatGPT will immediately connect, perform the MCP initialization handshake, and list the available OutSystems tools.

OutSystems Hero Tools

Truto automatically generates strictly typed tools based on the OutSystems LifeTime REST API documentation. Here are the highest-leverage tools available for your AI agents.

list_all_out_systems_environments

Discovers the topological layout of your OutSystems infrastructure. It returns the cryptographic Key, Name, Order, and server details for every registered environment.

Contextual usage: Always call this first when starting a deployment workflow. The LLM needs the exact source and target Key strings to execute cross-environment tasks.

"List all the environments in our OutSystems infrastructure and extract the exact Key values for the 'Development' and 'Production' environments."

list_all_out_systems_applications

Retrieves a complete inventory of all applications existing in the infrastructure. Returns details including Key, Name, Kind, IsSystem, and the AppStatusInEnvs which shows the exact version running in each environment.

Contextual usage: Use this to audit which version of an application is currently deployed in Production versus Testing.

"Check the current versions of the 'Customer Portal' application. Tell me if the version in Development is ahead of the version in Production."

create_a_out_systems_deployment

Initiates a new deployment plan in LifeTime between a source and a target environment. This does not actually execute the deployment - it stages it and detects conflicts.

Contextual usage: Requires passing the SourceEnvironmentKey, TargetEnvironmentKey, and a complex ApplicationOperations array dictating which applications to deploy or redeploy.

"Stage a deployment to move the 'Billing Service' app from the Staging environment to Production. Let me know if the staging plan succeeds and provide the resulting deployment ID."

get_single_out_systems_deployment_by_id

Retrieves the details of an existing deployment plan by its ID. Crucially, this returns the ApplicationConflicts array.

Contextual usage: Always call this after creating a deployment to ensure OutSystems hasn't detected breaking dependency conflicts before instructing the agent to execute.

"Look up deployment ID 'abc-123' and verify there are no dependency conflicts blocking the release."

out_systems_deployments_execute

Executes a command against a staged deployment plan. Accepts commands like start, continue, or abort.

Contextual usage: This is an asynchronous execution trigger. It returns an empty 202 Accepted response. The agent must subsequently poll the status endpoint to know when it finishes.

"Start the execution for deployment ID 'abc-123'. Once started, you must check the status until it completes."

create_a_out_systems_application_source_code

Requests source code access for a specific application in a specific environment. This kicks off an asynchronous packaging job on the OutSystems server.

Contextual usage: The API will immediately return a PackageKey and a status of running. The LLM must hold this key and use the get_single_out_systems_application_source_code_status_by_id tool to poll until it finishes.

"Request the source code package for the 'HR Onboarding' app from the Production environment and give me the tracking package key."

To see the complete schema definitions and the full inventory of OutSystems tools, visit the OutSystems integration page.

Workflows in Action

When you connect OutSystems to ChatGPT via Truto, you unlock autonomous workflows that string multiple tools together to handle complex, asynchronous IT operations.

Scenario 1: Automated Application Deployment and Promotion

Persona: Release Manager or DevOps Engineer

Deploying in OutSystems requires fetching cryptographic keys, building a deployment map, checking conflicts, executing, and polling. An AI agent can handle this entire state machine.

"Promote the 'Inventory Manager' application from Development to Staging. Stage the deployment, check for any dependency conflicts, and if it is clean, execute the deployment and wait for it to finish."

Tool execution sequence:

1. list_all_out_systems_environments - The agent retrieves the Key values for 'Development' and 'Staging'.
2. list_all_out_systems_applications - The agent finds the application Key for 'Inventory Manager'.
3. create_a_out_systems_deployment - Stages the release using the three keys.
4. get_single_out_systems_deployment_by_id - Checks the ApplicationConflicts array. (Assuming empty, it proceeds).
5. out_systems_deployments_execute - Sends the start command.
6. get_single_out_systems_deployment_status_by_id - The agent polls this endpoint in a loop, handling the running state until it returns finished_successful.

Result: The user gets a final confirmation message stating the deployment succeeded, along with the execution logs from the final status check.

sequenceDiagram
    participant User as User
    participant Agent as ChatGPT
    participant Truto as Truto MCP Server
    participant API as OutSystems API

    User->>Agent: "Promote Inventory Manager..."
    Agent->>Truto: list_all_out_systems_environments
    Truto->>API: GET /environments
    API-->>Agent: Dev Key, Staging Key
    Agent->>Truto: list_all_out_systems_applications
    Truto->>API: GET /applications
    API-->>Agent: App Key
    Agent->>Truto: create_a_out_systems_deployment
    Truto->>API: POST /deployments
    API-->>Agent: Deployment ID
    Agent->>Truto: out_systems_deployments_execute
    Truto->>API: POST /deployments/{id}/start
    API-->>Agent: 202 Accepted
    
    loop Poll Status
        Agent->>Truto: get_single_out_systems_deployment_status_by_id
        Truto->>API: GET /deployments/{id}/status
        API-->>Agent: running / finished_successful
    end
    Agent-->>User: "Deployment finished successfully."

Scenario 2: Source Code Escrow and Export

Persona: Security Auditor or Infrastructure Admin

Extracting source code from OutSystems requires navigating another async packaging process.

"I need the source code for the 'Finance Dashboard' app from the Production environment. Request the package, wait for it to build, and give me the download URL."

Tool execution sequence:

1. list_all_out_systems_environments - Finds the 'Production' environment Key.
2. list_all_out_systems_applications - Finds the 'Finance Dashboard' application Key.
3. create_a_out_systems_application_source_code - Submits the request and receives a PackageKey.
4. get_single_out_systems_application_source_code_status_by_id - Polls the status endpoint until the state transitions from running to Done.
5. get_single_out_systems_application_source_code_by_id - Fetches the finalized package containing the short-lived url and expires timestamp.

Result: The user receives a direct download link to the compiled source code package, bypassing the need to sit in the OutSystems UI waiting for the build bar to complete.

Security and Access Control

Exposing your core low-code infrastructure to an LLM requires strict boundary controls. Truto MCP servers provide robust security mechanisms at the generation layer:

• Method Filtering: If you only want ChatGPT to audit infrastructure without changing it, configure the server with methods: ["read"]. Tools like create_a_out_systems_deployment are instantly stripped from the schema and cannot be hallucinated into existence by the model.
• Tag Filtering: Restrict access to specific functional domains. Setting tags: ["applications", "environments"] ensures ChatGPT can't accidentally touch database mappings or user roles.
• Double Authentication (require_api_token_auth): For enterprise environments, you can force the MCP client to pass a Truto API token in addition to the cryptographically secure URL token. If the URL leaks, the server remains locked.
• Time-to-Live (expires_at): Generate ephemeral servers for temporary audit workflows. Setting an ISO datetime ensures the server self-destructs (cleaning up KV storage and DB records automatically) when the contractor or agent is done.

Moving Past Boilerplate

Integrating ChatGPT with OutSystems shouldn't require your engineering team to build a bespoke integration layer just to manage state machines and poll deployment endpoints. By auto-generating tools from documentation, managing the OAuth/token lifecycle, and providing a standardized MCP protocol interface, you can focus on building intelligent agent behaviors rather than maintaining API plumbing.

If you are ready to give your AI agents secure, strictly defined access to OutSystems, book a demo and see how fast you can spin up a production-ready MCP server.