category: reference

tags: [tasks, mcp, bug, multi-tenant]

last_updated: 2026-03-15

The MCP sidecar calls the otterwiki REST API at `http://localhost:8000` without a Host header. The TenantResolver on port 8000 treats requests without a wiki subdomain as the default wiki (`_default`). All MCP reads and writes go to the wrong wiki.

This means:

- Pages written via MCP go to `/srv/wikis/_default/`, not the intended wiki

- Pages read via MCP return content from `_default`, not the wiki the user connected to

- Semantic search queries search the wrong index

- The three `Tasks/` pages created today via MCP are in the `_default` wiki, not the dev wiki

The MCP server (otterwiki-mcp) creates a `WikiClient` with `OTTERWIKI_API_URL=http://localhost:8000`. When it makes HTTP requests to the REST API, it doesn't set a Host header. The TenantResolver sees `localhost` and falls through to the default wiki.

On 3gw (single-tenant), this works because there's only one wiki. On robot.wtf (multi-tenant), the MCP sidecar needs to forward the wiki context.

The MCP sidecar receives requests on wiki subdomains (e.g., `dev.robot.wtf/mcp`). It needs to:

1. Extract the wiki slug from the incoming request's Host header

2. Pass `Host: {slug}.robot.wtf` on its API calls to `http://localhost:8000`

3. This way TenantResolver resolves the correct wiki for each API call

The `WikiClient` in `otterwiki_mcp/api_client.py` needs to accept a `host_header` parameter and include it in all requests. The MCP tool handlers need to know the current wiki slug (from the incoming request context) and pass it to the client.

FastMCP's tool handlers are async functions registered with `@mcp.tool()`. They don't have direct access to the HTTP request context (Host header). The wiki slug needs to be threaded through somehow — either via a context variable, or by creating a per-request WikiClient.

The V5 consent flow already extracts the wiki slug in the `/authorize/callback` handler. A similar pattern can be used for tool calls.