MCP (Model Context Protocol) server

Ongoing WMS has a Model Context Protocol (MCP) server, which lets AI tools and assistants - such as chat assistants and coding agents - connect to a warehouse and call a set of tools (currently article and inventory lookups) on behalf of an authorized user. This page explains how to set it up and how it works.

Setting up an MCP user

To connect an AI tool, an administrator of the warehouse system first creates a dedicated MCP user from the goods owner API user screen ("Add new MCP user"):

  1. Choose an AI tool/provider from the list (for example ChatGPT, Claude, Cursor, Gemini CLI, Grok, Microsoft 365 Copilot, VS Code/GitHub Copilot, Microsoft Copilot Studio), or choose "Other" and supply a custom redirect URI and name.
  2. Select which MCP scopes the AI tool should be granted (for example mcp:articles:read).
  3. Map the MCP user to an existing human WMS user - this is the person who will be asked to authorize the connection, and whose warehouse/goods owner access the AI tool will effectively be limited to.

When saved, Ongoing WMS registers a new OAuth client with the authorization server and the dialog then displays the Client ID, Discovery URL, Authorization Endpoint, Token Endpoint, granted scopes, and the MCP API URL. Hand these values to the AI tool you are connecting (most tools only need the MCP API URL and will discover the rest automatically via OAuth/OIDC discovery).

Scopes can be changed later from the same screen, and deleting the MCP user revokes its OAuth installation.

Authorizing the connection

MCP connections use a human-in-the-loop authorization step, so that a real person explicitly approves which warehouse and user an AI tool gets to act as:

  1. When the AI tool starts its OAuth sign-in, the human mapped to the MCP user is redirected to the Ongoing WMS login page.
  2. The human logs in normally (including any multi-factor authentication configured for their account).
  3. Ongoing WMS verifies that this human is the one mapped to the MCP user being connected, then redirects back to the AI tool to complete the OAuth flow.

This login/authorization step uses short-lived, single-use tickets internally, so a completed authorization cannot be reused or replayed. Once authorized, the AI tool can call the MCP server using a bearer access token, scoped to whatever scopes were granted to the MCP user.

The MCP endpoint

The MCP server exposes a single JSON-RPC 2.0 endpoint over HTTP POST: 

POST https://api.ongoingsystems.se/{warehouse}/api/v1/mcp

Protocol details

  • Transport: JSON-RPC 2.0 over HTTP POST
  • Protocol version: 2025-03-26
  • Server name: ongoing-wms-mcp
  • Authentication: OAuth 2.0 bearer token (see "Authorizing the connection" above)

Supported methods

  • initialize - starts the session and negotiates capabilities.
  • notifications/initialized - sent by the client once initialization is complete.
  • tools/list - lists the tools available to the authorized user/scopes.
  • tools/call - invokes a tool (for example an article or inventory lookup).
  • ping - basic connectivity check.

Discovery

Clients that call the endpoint without credentials receive an HTTP 401 response with a WWW-Authenticate: Bearer resource_metadata="<api base url>/.well-known/oauth-protected-resource" header. Most MCP-compatible clients (ChatGPT, Claude, Cursor, Gemini CLI, Grok, Microsoft 365 Copilot, VS Code/GitHub Copilot, Microsoft Copilot Studio, and others) use this to self-discover the authorization and token endpoints, so they only need to be given the MCP API URL to connect.

Legacy (Basic authentication) MCP users

MCP users can also be created with classic Basic authentication (username/password) instead of OAuth. These behave like any other Basic-auth API user: full access, no scope restrictions, and the AI tool authenticates with an Authorization: Basic ... header instead of going through the human-authorization flow described above.