FR: maintain ctx.props

[hemanth]

I'm trying to access a custom header in order to conditionally load tools on an MCP server.

I'm setting ctx.props in the fetch method, expecting to access it later in the init method.

However, it appears that the ctx.props set during fetch is being flushed or not persisted, as I'm unable to access the expected values in init.

Steps to Reproduce:

1. Set a custom header in the request.
2. In the fetch method, read this header and assign it to ctx.props.
3. Attempt to read ctx.props in init to control conditional tool logic.

Expected Behavior:

The value set in ctx.props during fetch should be accessible in init.

Actual Behavior:

ctx.props appears to be empty or reset by the time init is called post auth.

//cc @geelen (we have discussed about this)

[kentonv]

What is the "init method"? I don't think the OAuth library has any sort of "init method", so I'm not sure what you mean here.

That said, each incoming event receives a new, separate ctx object, with a new copy of ctx.props. Assuming the request was authorized via OAuth, ctx.props was decrypted from the stored metadata for the key.

ctx.props is not intended to be mutable. If you modify it, your modifications will only stick around for the current request. Since the next request has a new ctx object, the props will have been re-loaded from storage and won't reflect any changes you made in the past.

The OAuth library lets you specify props when creating the authorization grant, and also lets you register a callback to update them during token exchanges (see "Token Exchange Callback" in the readme). Other than that, it's not possible to update the props value at runtime. If you need to store additional state, you'll have to store somewhere else, such as a Workers KV key, Durable Object storage, etc.

[hemanth]

What is the "init method"?

Nods, I should have provided more context! init from agents:

export class MyMCP extends McpAgent<Env, State, MyMCPProps> {
  async init() {}
}

Yes, was pawing at Token Exchange Callback and ASL was the best option we had as a workaround.

Say, if the user as the below config:

{
  "mcpServers": {
    "paypal-remote-mcp": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.example.com/sse",
        "--header",
        "x-feature-flags: foo:true"
      ]
    }
  }
}

I would like to access that x-feature-flags post first party auth, do we feel Token Exchange Callback can update the props for us here? Why ins't this customer headers maintained?