Qualify an openLCA MCP client

Test the actual client/version, transport, tool discovery, openLCA connection, and permission boundary instead of inferring support from a config example.

Configuration compatibility is not host qualification

A client can accept a familiar MCP configuration shape and still fail tool discovery, streaming, permissions, or authentication. Record evidence from the exact client/version before labeling it supported.

Local stdio pattern

json

{
  "command": "python",
  "args": ["-m", "src"],
  "cwd": "/absolute/path/to/openlca-mcp",
  "env": {
    "OPENLCA_HOST": "localhost",
    "OPENLCA_PORT": "8080",
    "OPENLCA_READ_ONLY": "true"
  }
}

Streamable HTTP pattern

bash

TRANSPORT=http MCP_HOST=0.0.0.0 MCP_PORT=8000 python -m src

Connect the client to the /mcp endpoint. For remote use, terminate TLS and enforce authentication before exposing the server.

Minimum client qualification

Record client product/version and transport.
Record MCP server version/source revision.
Confirm expected tool discovery.
Call test_connection.
Confirm the active openLCA database.
Run one read-only discovery operation.
When scientifically appropriate, run one calculation and result-disposal lifecycle.
Record auth/permission failures and client limitations.

Remote streaming can fail even when HTTP is reachable

A buffering tunnel or reverse proxy can allow one-shot HTTP requests while preventing a remote MCP client from attaching the tool stream. Qualify the complete client → proxy/tunnel → MCP path, not only curl connectivity.

Hosted server boundary

openLCA is a desktop application. A remote MCP endpoint calculates against the openLCA instance/database it can actually reach. A hosted demo therefore uses the operator's database, not an arbitrary user's local database.