Hi everyone,

If you use OutSystems 11 MCP with Claude Code, you have probably noticed how much it can speed up development and application analysis.

However, we encountered a problem with some of our largest and most complex modules: Claude could not read them through MCP. Even a simple request such as “list the action names” failed with:

oml-tool did not respond within 120s.

We tried closing all other modules, reopening the affected module on its own, and restarting Service Studio. The result was the same.

I eventually found a workaround that worked for our case, so I wanted to share it.

What I found

Service Studio includes an executable called oml-tool.exe, which is used behind the MCP server.

In my investigation, each request started a new process and reloaded the module. For the affected modules, requests exceeded the 120-second timeout reported by the MCP integration.

The workaround

Instead of accessing the module through MCP, we asked Claude Code to run the same executable directly against an exported .oml file:

1. Export the module as an .oml file.

2. Ask Claude Code to run oml-tool.exe directly against a working copy.

3. Retrieve the element names first, then extract the elements individually.

4. Run a small number of requests in parallel, using a separate copy of the .oml file for each worker.

This bypassed the specific 120-second MCP timeout we were encountering. The execution timeout in the agent’s shell runner still needs to allow enough time for each request to finish.

In our tests, individual calls took approximately 60–110 seconds, using around 750 MB of RAM per worker. These figures will vary depending on the module and machine.

The result

I successfully extracted the module’s content into files that Claude could read, analyze, and use to document the application.

This is a read-only workaround based on our experience, rather than an officially documented alternative to MCP. It also works against an exported snapshot, so subsequent changes in Service Studio require a fresh export.

Prompt to try in Claude Code

Replace the module name and file path before running:

My OutSystems module is too large for the Service Studio MCP (calls fail with "oml-tool did not respond within 120s").

I exported it to: \MyModule.oml

Read it directly with Service Studio's own engine instead of the MCP:

- Tool: C:\Program Files\OutSystems\Service Studio 11\Service Studio\runtimes\win-x64\oml-tool.exe

- Run it as: oml-tool.exe --stdio  (send ONE JSON-RPC line on stdin, get one line back; one request per process)

- Request shape: {"jsonrpc":"2.0","id":1,"method":"","params":{"omlPath":"","eSpaceName":"MyModule", ...}}

- Methods are the MCP tool names: getActionNames (objectType: server|client|service), getScreenNames, getWebBlockNames,

  getServerAction / getClientAction / getServiceAction / getScreen / getWebBlock (objectName, includeJson: "Never"),

  getDataModel, getStructures.

- getSerializedObject (whole module as JSON) may fail on UI modules with "maximum configured depth of 64" - fall back to per-element calls.

Steps:

1. Pull the name lists first, then every element the module owns (IsReferenced = false), one file per element.

2. Run 2-4 calls in parallel, each worker on its OWN copy of the .oml. Each call reloads the whole module (~60-110 s and ~750 MB RAM), so size the workers to free memory.

3. Treat it as read-only: never use applyModelApiCode or save the file.

Then document the module from the extracted files.

Has anyone else encountered this timeout with large modules?  Is there a supported way to increase the timeout or reuse the loaded module across read requests?