MCP

One combined MCP (Model Context Protocol) server exposes operations from the partner-facing APIs below as tools for AI agents -- not one server per domain, since MCP clients expect a single connection with one discoverable tool list, not one connection per domain.

Server URL

https://dev-openapi-apim.azure-api.net/mcp/partner-tools/mcp

Authenticating

The MCP server itself does not issue tokens. Get a Bearer token directly from the authorization API, then use that same token on every MCP request.

1. Get a token

POST https://dev-openapi-apim.azure-api.net/public/authorization/v1/tokens/oauth as application/x-www-form-urlencoded, with fields grant_type=client_credentials, client_id, and client_secret. No scope field is used.

curl -X POST \
  https://dev-openapi-apim.azure-api.net/public/authorization/v1/tokens/oauth \
  --data-urlencode grant_type=client_credentials \
  --data-urlencode client_id=<your-client-id> \
  --data-urlencode client_secret=<your-client-secret>

{"access_token": "eyJ...", "expires_in": 3600}

2. Use the token

Send it as Authorization: Bearer <access_token> on every request to the MCP server. Tokens expire (see expires_in); request a new one when yours does.

[PLACEHOLDER — needs real content from someone with product knowledge of this process: how a partner actually obtains a client_id and client_secret (the provisioning/onboarding process).]

Why authorization isn't exposed as an MCP tool

The operations that issue tokens are deliberately not exposed as MCP tools: they would need to issue the very JWT that gates every other tool on this same server, and API Management's MCP policy applies to every tool on a server with no per-tool scoping -- so exposing them would be circular. Get your token the normal REST way, above, then use the MCP server for everything else.

Available tools

The tool set is kept in sync automatically with the live operations on the Entities, Dispatching, and Opportunity APIs, so it can change as those APIs change. Call tools/list after connecting for the current, authoritative set rather than relying on a fixed list here.

Raw JSON-RPC example

This works with any MCP client. Initialize the connection, then list the available tools:

curl -X POST https://dev-openapi-apim.azure-api.net/mcp/partner-tools/mcp \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"my-client","version":"1"}}}'

curl -X POST https://dev-openapi-apim.azure-api.net/mcp/partner-tools/mcp \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

Claude Code example

Claude Code can fetch a fresh token automatically on every connection using headersHelper, so you never paste a token in by hand and it never goes stale. Point it at a script like scripts/get-pcs-mcp-headers.sh and add this to .mcp.json:

{
  "mcpServers": {
    "pcs-partner-tools": {
      "type": "http",
      "url": "https://dev-openapi-apim.azure-api.net/mcp/partner-tools/mcp",
      "headersHelper": "/path/to/scripts/get-pcs-mcp-headers.sh"
    }
  }
}

get-pcs-mcp-headers.sh reads your client_id/client_secret from a local file, performs the token exchange above, and prints {"Authorization": "Bearer <token>"} to stdout. Claude Code re-runs it on every connection and reconnect, so tokens are always fresh.

PCS

Documentation

MCP