/outsystems

name: outsystems
description: "OutSystems Developer Cloud (ODC) over MCP. Edit apps, publish, deploy, search tenant elements, manage external libraries. Load this skill before calling any tool from the OutSystems ODC MCP server, including read-only calls such as listing apps. Use for ANY OutSystems task on ODC. Not for OutSystems 11 (O11) modules open in Service Studio. When the Service Studio (O11) MCP server is also connected and the request names neither ODC nor O11, ask the user which platform before calling any OutSystems tool."

OutSystems - Remote MCP

You are connected to OutSystems Developer Cloud (ODC) over the MCP HTTP transport. OutSystems is a cloud-native low-code platform where apps are built from OML (OutSystems Model Language), a binary format describing entities, screens, actions, and logic. Every tool call carries the harness's validated OAuth bearer; tenant + user identity are derived from the JWT, not from arguments.

**Once authenticated and the server's tools are visible**, read the live `tools/list` before your first non-auth OutSystems operation. This skill names domains, not tools — names, parameters, and defaults can change server-side, and the server is the source of truth. (Authenticating is the one exception: drive the auth flow first, as described below.)

**Platform check, only when both OutSystems MCP servers are connected.** This server is for OutSystems Developer Cloud (ODC). When tools from the Service Studio MCP server (O11, named `servicestudio` in the O11 setup) are also visible in this session, you MUST decide the platform before your first call to this server, read-only calls such as listing apps included. With both servers connected, **you can't know which platform a request is for unless it names one, so never guess**:

• The request names ODC, an ODC app or the tenant: go ahead on ODC.
• The request names O11, an O11 module or the module open in Service Studio: don't use this server.
• The request names neither, as in "my app": you MUST ask the user "Is this for ODC, or for the O11 module open in Service Studio?" and wait for the answer before calling any tool.

Once you know the platform for certain, because the request named it, the user answered, or earlier turns in this conversation settled it, don't ask again for later requests; ask again only when a request points to the other platform.

When only this server is connected, skip this check and go ahead as usual.

First use / setup

If the `outsystems` MCP tools aren't visible in your toolset, or a call returns `tenant not configured` / connection errors, the MCP server has no tenant to talk to yet. On Claude Code the plugin declares the server itself and builds its URL from the `tenant_hostname` plugin option; on Claude Desktop's Chat tab the server comes from `claude_desktop_config.json`. A rejection naming `tenant_not_allowed` is a different condition and usually not a setup fault, so check the configured host first: `claude mcp list` on Claude Code (the plugin's server is listed as `plugin:outsystems:outsystems`, a registration from an older recipe as `outsystems`; `claude mcp get outsystems` reads only the latter), or the `mcpServers.outsystems` entry in `claude_desktop_config.json` on Claude Desktop (same file the Desktop setup steps below write to; if you cannot read files in this host, ask the user to open that file and paste only the `outsystems` entry, telling them the file's other entries belong to other MCP servers and may hold private values, so they should not be pasted), see Rules. Otherwise, do this once per machine. Pick the branch by what this host gives you: if you can run shell commands and the `claude` CLI exists, use the Claude Code recipe below; otherwise use the Claude Desktop recipe.

For Claude Code Users (CLI)

1. **Ask the user for their OutSystems tenant hostname.** Format: `<tenant>.outsystems.dev` (e.g. `mycompany.outsystems.dev`, `mytenant.outsystems.dev`). The tenant slug is whatever the user chose; do not assume a fixed `<short>-<region>-<index>` pattern. Prompt verbatim: > "Which OutSystems tenant should I connect to? It's the host portion of your OutSystems URL, typically something like `mycompany.outsystems.dev`." 2. **Normalize, then validate.** Accept whatever the user gives you (URL, hostname, hostname-with-path). Strip the scheme (`http(s)://`), any leading `www.`, trailing slash, and any path or query — keep only the host. The result must match `^[A-Za-z0-9]([A-Za-z0-9.-]*[A-Za-z0-9])?$` — if it doesn't, ask again; do not proceed with a value that fails the check. 3. **Construct the MCP URL**: `https://<TENANT>/mcp`. 4. **Set the tenant on the plugin.** If you cannot run shell commands here, you are not in Claude Code — use the Claude Desktop recipe below instead. If `claude plugin list` shows no `outsystems`, the plugin is absent and you are reading this skill some other way: register the server directly with `claude mcp add -s user --transport http outsystems <URL>` instead of the command below. Otherwise, first check whether a tenant is already in use: run `claude mcp list` and look for a `plugin:outsystems:outsystems` line (or a plain `outsystems` line left by an older registration, which hides the plugin's line when both point at one tenant); the hostname in that URL is the tenant currently in use, and no such line means none is stored yet. If one is in use and it differs from `<TENANT>`, restate "change the plugin's tenant from X to Y" and wait for explicit confirmation, because the command below overwrites the stored value and keeps no record of the old one. Then run:

   claude plugin install outsystems@outsystems --config tenant_hostname=<TENANT>

Pass the bare hostname from step 2, not `<URL>`: `--config` does not validate the value, and a scheme or path in it yields a server URL that cannot resolve. On an already-installed plugin the command answers `already installed` and nothing else; the option is