/outsystems

name: outsystems
description: "OutSystems over MCP. Edit apps, publish, deploy, search tenant elements, manage external libraries. Use for ANY OutSystems task."

OutSystems - Remote MCP

You are connected to OutSystems 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.)

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 hasn't been registered against the user's tenant. A rejection naming `tenant_not_allowed` is a different condition and usually not a setup fault, so check the configured host with `claude mcp get outsystems` on Claude Code, or by reading 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 may hold other MCP servers' credentials in their `args`/`env` and 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 `claude mcp add` 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 (`https://`, `http://`), 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. **Register the server.** If you cannot run shell commands here, you are not in Claude Code — use the Claude Desktop recipe below instead. Otherwise run:

   claude mcp add -s user --transport http outsystems <URL>

Do NOT pass `--client-id` or `--callback-port`. The server supports OAuth Dynamic Client Registration, so the host registers its own client on an ephemeral loopback port. 5. **Authenticate.** Proceed to the "Authenticating" section below. The agent drives auth via tool calls; the user does NOT click anything in `/mcp`. 6. **Retry the user's original request** once authentication completes.

For Claude Desktop Users (Manual Config)

If `mcpServers.outsystems` already exists in the config file (step 5 below) and its URL matches the tenant you mean, skip steps 1-3 and step 5's config write — the tenant-collection and config-write steps have nothing to add. Still work through step 4 (confirm Node.js/npx is available) and confirm with the user that Claude Desktop has been restarted since that entry was last edited (step 6); only if the tools are still missing after a confirmed restart, walk through step 5's PATH-fallback paragraph against the existing entry (Desktop launches `npx` with a minimal PATH of its own, so it can fail to resolve there even though step 4's check, run in your own shell, passed), then have the user restart Desktop again (step 6) before concluding the missing tools are an auth problem: a Desktop process that predates the config edit, and an unresolvable `npx` inside Desktop's launch environment, are the dominant real causes of "the entry exists but the tools are still missing," and both go unnoticed if you jump straight to step 7.

1. **Ask the user for their OutSystems tenant hostname** (same prompt as above). 2. **Normalize and validate** (same as above). 3. **Construct the MCP URL** (same as above): `https://<TENANT>/mcp`. 4. **Confirm Node.js/npx is available, then install `mcp-remote`.** This recipe requires Node.js with `npx` available on the user's machine, but what you can check yourself depends on this host's capabilities:

• **Shell and files:** confirm `npx` yourself (e.g. `npx --version`), then run `npm install -g mcp-remote` — idempotent and safe even if it's already installed. If the command runs but reports npx missing, stop here and tell the user to install Node.js first; without it, the `outsystems` entry — whether you are about to write it below or it already exists — produces a server that silently fails to connect.
• **Files, no shell:** you can't run the check above yourself. If you're on the already-configured shortcut above, there's no config entry to write — ask the user to run `npx --version` and `npm install -g mcp-remote` in a terminal. If they report `npx` is missing, stop and tell them to install Node.js first, exactly as above; otherwise confirm Claude Desktop has been restarted since that entry was last edited (step 6), and only if the server still won't connect after that, walk through step 5's PATH-fallback paragraph against the existing entry, then have them restart Desktop again (step 6) before continuing to step 7 (Authenticate). If you're not on the shor