Using the MCP server with WATS on-premises

The MCP server in an on-premises WATS installation works the same way as in WATS Cloud, with one exception: documentation search is not available. The /mcp endpoint and the analysis tools are identical, and the same MCP clients can connect, provided your network allows it (see below).

Why documentation search is cloud-only

In WATS Cloud, the assistant can search and read the WATS documentation using the knowledge tools SearchDocuments and FetchDocuments. These tools depend on an Azure-hosted search service that exists only for cloud instances.

On-premises, these two tools are not offered to the client, and the assistant is informed that documentation search is unavailable so it does not attempt to use it. All data analysis tools work exactly as in the cloud.

Network requirements for hosted MCP clients

Hosted MCP clients such as Claude (web, desktop, mobile), ChatGPT and Copilot Studio run in the vendor's cloud and connect to your WATS server over the internet. The vendors require that the server is:

• Reachable from the internet over HTTPS on the /mcp endpoint
• Using a certificate from a public certificate authority

Certificates from your internal CA, or self-signed certificates, are not trusted by the vendor's servers, and the connection fails.

Local MCP clients run on the user's own machine and have neither requirement. They only need to reach WATS over your LAN or VPN, and an internal certificate works.

Authentication

You can authenticate MCP clients against WATS with either OAuth or a JWT token. Which one fits depends on how much network access your WATS server has.

Both methods act as the user who connected, with that user's permissions and restrictions. The assistant can only see and do what the user can see and do in WATS.

OAuth

WATS identifies an MCP client using a Client ID Metadata Document (CIMD). The client's ID is an HTTPS URL (for example on claude.ai or vscode.dev), and WATS fetches this document during sign-in to verify who is requesting access.

This fetch runs from the WATS server, so OAuth requires the server to have:

• Public DNS resolution for the client vendor's domain
• Outbound HTTPS (port 443) to that domain

If either is missing, the OAuth flow fails before the consent page appears.

JWT token (fully offline)

If your WATS server must not communicate with the internet at all, use a JWT token instead. WATS fetches nothing and sends no outbound traffic. With a local client such as Claude Code, the entire setup stays inside your network.

Each user creates a token under My settings > MCP > JWT Tokens and passes it to the client as a bearer header.

A JWT token acts as you in WATS with all your permissions. Treat it like a password: never share it, use one per client, keep lifetimes short, and revoke it if you suspect a leak. Administrators can revoke any token under Control Panel > JWT Tokens.