mcp.json has no headersHelper — MCP auth + X-License-Token both unset

[saurabhjain1592]

Bug suspected

`mcp.json` is just `{ "url": "..." }` — no `headersHelper`, no static `headers`. `scripts/mcp-auth-headers.sh` exists and was V1-wire-up-updated to emit `Authorization` + `X-License-Token`, but nothing in `mcp.json` invokes it.

That likely means MCP tool calls from Cursor reach the agent with no Authorization header (so community-saas auth fails) AND no X-License-Token (so Pro tier never applies on MCP path).

How to verify

1. Stand up a stub agent that logs request headers
2. Configure Cursor with this plugin pointed at the stub
3. Trigger an MCP tool call from Cursor
4. Inspect what reached the stub: Authorization? X-License-Token?

If the stub sees neither, this issue is confirmed. If Cursor's plugin runtime injects auth via a different mechanism (env-var passthrough, separate config), document the actual mechanism in this issue + close.

Fix candidate

If Cursor's MCP client supports headersHelper:

```json
{
"mcpServers": {
"axonflow": {
"url": "${AXONFLOW_ENDPOINT:-http://localhost:8080}/api/v1/mcp-server",
"headersHelper": "bash ${CURSOR_PLUGIN_ROOT}/scripts/mcp-auth-headers.sh"
}
}
}
```

(Substitute the right plugin-root variable for Cursor — may be `CURSOR_PLUGIN_ROOT`, `CURSOR_AGENT_PLUGIN_DIR`, etc.)

If Cursor doesn't support headersHelper, the V1 wire-up needs a different mechanism (e.g., the plugin runtime exporting headers via env at MCP-session-bootstrap time, or a docs change instructing users to set headers manually).

Refs

• Discovered while designing host-CLI invocation tests (V1 launch 2026-05-04).
• Sister issue: axonflow-claude-plugin#56 (same bug class on Claude Code).
• Same audit needed for axonflow-codex-plugin.