5.10. MCPs

Note

This code is “Pre-Release Functionality” or “Pre-Release Code” and is not yet ready for production. It is made available on a complimentary basis, in order to provide experimental support, showcase samples, or for other similar experimental reasons in connection with the services you get from The Qt Company Oy. This Pre-Release Functionality/Code is governed by your licensing agreement with The Qt Company (including specifically its Pre-Release Code provisions) or, if you don’t have one, the terms and conditions available at https://www.qt.io/terms-conditions-2024-02 (including the Qt Appendix for Axivion available at https://www.qt.io/terms-conditions/axivion-2025-03, Appendix for Qt AI Services available at https://www.qt.io/terms-conditions/ai-services-2025-06 and other addenda). Access to and use of this Pre-Release Code requires a valid commercial Axivion license and is available to active license holders.

The Axivion Suite can be accessed and controlled from various coding agents / LLMs via MCP servers. There are different MCP servers available, each serving a different purpose.

5.10.1. Available MCPs

5.10.1.1. Dashboard / Results MCP

The dashboard MCP (ax_dashboard) offers access to the results stored in a given dashboard or database. It is intended for working with findings, analyzing and fixing them.

The ax_dashboard MCP server can also access the local build results if a local build has been performed, allowing it to work with the most recent analysis results alongside dashboard results. Additionally, it can execute local builds to verify whether findings have been resolved, enabling an agent loop for iterative fixing and verification.

5.10.1.2. Documentation MCP

The documentation MCP (ax_documentation) provides improved access to the Axivion documentation via hybrid search: it combines keyword search (BM25) with an optional semantic search index and fuses both rankings. It enables LLMs and agents to query the documentation efficiently and can be used standalone or to provide additional context when working with other MCP servers.

5.10.2. How to Obtain the MCPs

The MCP servers are available as Axivion-MCPs-<version>.zip, which is distributed alongside the main Axivion Suite installer.

5.10.3. Setup and Configuration

5.10.3.1. Prerequisites

The servers run on the Axivion Suite’s rfgscript, which brings its own Python and every package they need, so there is nothing to install.

The optional semantic half of the documentation search is the exception. It needs the ML packages listed in ax_documentation/requirements.txt, installed into a virtual environment, ideally managed by uv:

uv venv
uv pip install --requirements <path_to_axivion-mcps>/ax_documentation/requirements.txt

The Python executable from this environment is then passed to rfgscript via the BAUHAUS_PYTHON environment variable. rfgscript keeps the suite’s own packages ahead of it, so the server can use both.

5.10.3.2. Configuration

Dashboard MCP (ax_dashboard)

For certain commands such as creating suppression comments, ax_dashboard needs access to the current project configuration via BAUHAUS_CONFIG (set as usual).

ax_dashboard also cooperates with the Axivion Suite IDE plugins when available, using locally available build results alongside dashboard results.

Connecting to a dashboard. With AXIVION_DASHBOARD_URL set, the server connects to that dashboard - typically the central one fed by your CI - just as axivion_ci does. Without it, the server operates offline: it starts a private local dashboard on the results of the last local build.

Credentials are taken from the suite-standard variables AXIVION_USERNAME, AXIVION_PASSWORD and AXIVION_PASSFILE. Alternatively, AXIVION_TOKEN may hold an API token created on the dashboard. When none of these are set, the server connects anonymously.

A configured dashboard that cannot be reached, or that refuses the credentials, is reported as an error: the server does not silently answer from local results instead, since those describe a different state of the code. To opt into that fallback, set AXIVION_DASHBOARD_ALLOW_LOCAL_FALLBACK to 1; answers are then labeled as coming from the local analysis.

Naming the project. A configured dashboard serves many projects, so the server never guesses which one is meant. The project name is resolved in this order: the database selected with select_database(), the AXIVION_CI_PROJECT_NAME override, the project configuration (BAUHAUS_CONFIG), AXIVION_PROJECT_NAME, and - for a private local dashboard only - its single project. Setting AXIVION_PROJECT_NAME allows a purely remote session without any checkout; AXIVION_CI_PROJECT_NAME is only needed when the dashboard serves the project under a different name than the local configuration carries.

Local and CI analysis results. A local build and the configured dashboard hold analyses of two different states of the code, so their results legitimately differ. Each project therefore has an active analysis source - local, ci or both - and every findings, statistics and rules response states which analysis it came from and that analysis’s version. The source is resolved when a project is first used (preferring a local analysis that ran during the session, otherwise the newer analysis) and then kept for the session; it never changes behind the user’s back.

  • AXIVION_ANALYSIS_SOURCE preselects local, ci or both. The default newest expresses no preference. The Axivion Suite IDE plugins pass their own results-view choice this way.

  • The get_analysis_source() tool reports the active source, why it is active, and how old each analysis is; select_analysis_source() switches it for the rest of the session; refresh_analysis_sources() re-checks both sides and picks up an analysis that appeared since, e.g. after a local build.

  • When the working copy changed after the local analysis ran, responses from the local analysis carry a code_changed_since_local_analysis warning.

  • A database selected with select_database() becomes that project’s local analysis; a configured dashboard stays available as the CI side.

Documentation MCP (ax_documentation)

The search_axivion_documentation tool searches the documentation with two complementary indexes and fuses their rankings:

  • A keyword index (BM25 on SQLite FTS5). It ships pre-built inside Axivion-MCPs-<version>.zip, so keyword search answers from the moment the server starts. Use the archive of the Axivion Suite version the server is pointed at. Answers and their links otherwise describe a different release, which the server reports as a warning in its log.

  • An optional semantic search index, which turns each chunk of documentation into a vector embedding and lets queries match documentation by meaning rather than exact keywords. It requires the ML packages (see the prerequisites above) and is generated once after installation:

    BAUHAUS_PYTHON=<path_to_venv>/bin/python <path_to_bauhaus-suite>/bin/rfgscript \
        <path_to_axivion-mcps>/ax_documentation/parse_docs.py \
        --suite-path <path_to_bauhaus-suite>
    

    This creates <path_to_axivion-mcps>/ax_documentation/doc_index/ from the HTML documentation and code examples shipped with the suite. Note that the generation can take several hours.

When the semantic search index or the ML packages are missing, search transparently runs on the keyword index alone. Adding --lexical-only to the command above rebuilds only the keyword index, which is what a documentation update in place calls for.

If you run into issues check the FAQ or contact axivion.support@qt.io

5.10.3.3. Integration into IDEs

VS Code (Windows, Linux, macOS)

VS Code 1.109.2 or later is required for MCP server support. Add the servers to .vscode/mcp.json, adapting the paths to your Axivion installation and project:

{
  "servers": {
    "axdocumentation": {
      "type": "stdio",
      "command": "<path_to_bauhaus-suite>/bin/rfgscript",
      "args": [
        "<path_to_axivion-mcps>/ax_documentation/ax_documentation.py"
      ],
      "env": {
        "BAUHAUS_INSTDIR": "<path_to_bauhaus-suite>"
      }
    },
    "axdashboard": {
      "type": "stdio",
      "command": "<path_to_bauhaus-suite>/bin/rfgscript",
      "args": [
        "<path_to_axivion-mcps>/ax_dashboard/ax_dashboard.py"
      ],
      "env": {
        "BAUHAUS_INSTDIR": "<path_to_bauhaus-suite>",
        "BAUHAUS_CONFIG": "${workspaceFolder}/axivion",
        "AXIVION_DATABASES_DIR": "<optional_path_to_databases>"
      }
    }
  }
}

To let ax_dashboard answer from a central dashboard, add AXIVION_DASHBOARD_URL, a credential (e.g. AXIVION_TOKEN) and, without a checkout, AXIVION_PROJECT_NAME to its env block (see Dashboard MCP (ax_dashboard)).

ax_documentation can also be hosted centrally over HTTP:

MCP_HTTP_HOST=<hostname> MCP_TRANSPORT=http DOC_HTTP_BIND=0.0.0.0 rfgscript <path_to_axivion-mcps>/ax_documentation/ax_documentation.py

For this case, add it as an HTTP server in .vscode/mcp.json instead:

{
  "servers": {
    "axdocumentation_http": {
      "type": "http",
      "url": "http://<hostname>:<port>/mcp"
    }
  }
}

Claude Desktop (Windows)

Add the following to %APPDATA%\claude_desktop_config.json:

{
  "mcpServers": {
    "axdocumentation": {
      "command": "<path_to_bauhaus-suite>\\bin\\rfgscript.exe",
      "args": [
        "<path_to_axivion-mcps>\\ax_documentation\\ax_documentation.py"
      ],
      "env": {
        "BAUHAUS_INSTDIR": "<path_to_bauhaus-suite>"
      }
    },
    "ax_dashboard": {
      "command": "<path_to_bauhaus-suite>\\bin\\rfgscript.exe",
      "args": [
        "<path_to_axivion-mcps>\\ax_dashboard\\ax_dashboard.py"
      ],
      "env": {
        "BAUHAUS_INSTDIR": "<path_to_bauhaus-suite>",
        "BAUHAUS_CONFIG": "<path_to_project_config>"
      }
    }
  }
}

Claude Code (Windows, Linux, macOS)

Adapt the configuration bellow and add it to C:\Users\<username>\.claude.json on Windows or /home/<username>/.claude.json on Linux or /Users/<username>/.claude.json on macOS:

{
  "mcpServers": {
    "axdocumentation": {
      "command": "<path_to_bauhaus-suite>\\bin\\rfgscript.exe",
      "args": [
        "<path_to_axivion-mcps>\\ax_documentation\\ax_documentation.py"
      ],
      "env": {
        "BAUHAUS_INSTDIR": "<path_to_bauhaus-suite>"
      }
    },
    "ax_dashboard": {
      "command": "<path_to_bauhaus-suite>\\bin\\rfgscript.exe",
      "args": [
        "<path_to_axivion-mcps>\\ax_dashboard\\ax_dashboard.py"
      ],
      "env": {
        "BAUHAUS_INSTDIR": "<path_to_bauhaus-suite>",
        "BAUHAUS_CONFIG": "<path_to_project_config>"
      }
    }
  }
}

5.10.4. FAQ

Q: When running parse_docs.py or after doing a prompt I get a huggingface.co connection issue.

A: For semantic search, the MCP downloads a text embedding model from huggingface.co and uses it to turn each chunk of documentation into a vector embedding. Together these embeddings form a semantic search index, which lets queries match documentation by meaning rather than exact keywords.

If you run into connection issues, it is likely that a company policy blocks the internet connection to huggingface.co. In this case, you can ask axivion.support@qt.io to transfer the model to you. Documentation search keeps working without the model: the keyword (BM25) index does not need one.