MCP | AssetRouter

The connector lets an MCP client use the same public HTTP API as a custom integration. It runs on your computer as a stdio process. Your MCP client must be able to reach the AssetRouter API.

Install Python 3.12 or later. Download the MCP connector and its pinned dependencies into a private folder.

From that folder:

python -m venv .venv-mcp
.venv-mcp/bin/python -m pip install -r requirements-mcp.txt

Configure your MCP client to launch the downloaded assetrouter-mcp.py with this environment's Python executable. On Windows the executable is .venv-mcp\Scripts\python.exe; on macOS/Linux it is .venv-mcp/bin/python.

Supply these environment variables through your client's private configuration or secret store:

Variable	Value
`ASSETROUTER_API_URL`	API origin, for example `https://assetrouter.eu`. No `/api` suffix.
`ASSETROUTER_CLIENT_ID`	The organization's API client identifier.
`ASSETROUTER_CLIENT_SECRET`	The matching API secret.

For clients using a mcpServers JSON configuration, the equivalent setup is below. Replace both absolute paths and the credential placeholders. Launching the file directly avoids a working-directory requirement:

{
  "mcpServers": {
    "assetrouter": {
      "command": "/absolute/path/to/.venv-mcp/bin/python",
      "args": ["/absolute/path/to/assetrouter-mcp.py"],
      "env": {
        "ASSETROUTER_API_URL": "https://assetrouter.eu",
        "ASSETROUTER_CLIENT_ID": "YOUR_CLIENT_ID",
        "ASSETROUTER_CLIENT_SECRET": "YOUR_CLIENT_SECRET"
      }
    }
  }
}

Use your service's HTTPS origin outside local testing. Other clients may expose command, arguments and environment as separate form fields. Do not put credentials in prompts, source control or shared configuration. Anyone allowed to use this connector acts with the configured organization's API credentials. This is a local connector, not a hosted MCP endpoint with delegated user login.

Tools

MCP tool	HTTP API call	Purpose
`list_licenses()`	`GET /api/v1/library`	Discover recorded resource URLs, collection coverage, accepted conditions and license states.
`list_authorization_requests()`	`GET /api/v1/records`	Read its request and authorization records. These do not prove download or actual use of content.
`request_authorization(tenant_id, resource, usage)`	`POST /api/v1/authorizations`	Request an access token under existing rights. `usage` defaults to `ai-input`.

Example tool arguments (replace the identifier and URL with a resource in your library):

{"tenant_id": "publisher-id", "resource": "https://publisher.example/report.pdf", "usage": "ai-input"}

A normal agent flow is: call list_licenses, inspect the entry's coverage, selected_offer, verification, validity and next_step, then request authorization for the intended URL and use. Declared rights are visible immediately but cannot authorize access before confirmation. A collection pattern is not an exhaustive file list. After authorization, the agent's HTTP tool or application fetches the resource directly from the publisher using Authorization: License <access_token>. Send that token only to the intended resource server; never send your organization API secret there.

The connector forwards JSON responses from the API. It does not buy licenses, confirm declared rights or download the requested resource. Treat returned access tokens as credentials. Content retrieval and token validation remain the publisher integration's responsibility. Library and record results follow the API's limits; the connector does not silently collect additional pages.

Requests time out after 15 seconds, responses are limited to 1 MiB, and redirects are not followed. API credentials are sent only to the configured origin. HTTP errors report their status and, for recognized refusal codes, a fixed explanation of the next step without exposing remote response text or credentials. There are no automatic retries: after a timeout, check the request records before repeating an authorization request because the API may already have processed it.