What about autonomous use cases, where the agent is running without a user principal?

[tulshi]

From @maxwellgerber:
4.3 says:

For autonomous agent use cases, the context MUST include the identity of the agent. At least one field of either the subject or the context MUST be derived from the token input variable via a CEL expression.

However, the same MCP tool can be invoked by both an autonomous agent and an agent acting on behalf of a user. The COAZ mapping is the same for all callers, though. Suggest removing the "For autonomous agent use cases" part and strengthening to "The context MUST include the identity of the agent".

Are there examples of tools that cannot be wrangled with an x-coaz-mapping? For example, the make_api_request tool fro the Block MCP - https://engineering.block.xyz/blog/build-mcp-tools-like-ogres-with-layers - where the request object schema is polymorphic and uses a tagged union (based on the method?)

[vatsalgupta]

To add to the polymorphic tool question — the core issue is that x-coaz-mapping is static and assumes a fixed parameter structure, but tagged-union tools like make_api_request have
fundamentally different authorization semantics depending on a discriminator field (e.g. method).

For example, the same tool handles two completely different operations:

{ "method": "transfer", "params": { "from": "acct-123", "to": "acct-456", "amount": 1000 } }
{ "method": "get_balance", "params": { "account": "acct-123" } }

A single x-coaz-mapping cannot express both — the resource field params.arguments.params.from only exists for transfer, not get_balance. CEL conditionals can partially work around
this:

"id": "params.arguments.method == 'transfer' ? params.arguments.params.from : params.arguments.params.account"

But this becomes unmaintainable with many method variants and cannot handle open-ended polymorphism where new methods are added dynamically.

[baboulebou]

Well, the question is then, shouldn't polymorphic tools be broken-up into separate ones? Could be done even if the underlying APIs are still the same and polymorphic...

This is an implementation concern I think, not sure what else we could provide on the standard front to solve this, besides the flexibility of CEL as you illustrate. If it's hard to manage, then implementers should prob change their implementations...

[maxwellgerber]

Can we split this issue into two? The polymorphic tool definition concern and the agent principle concern are separate.

shouldn't polymorphic tools be broken-up into separate ones?

That is the question! In the early days of MCP many MCP clients dumped the entire tool json response into the context, so people collapsed tools into each other to save on tokens. Now that clients have evolved to implement their own local tool search, should polymorphic tools be considered an antipattern? Or should the spec attempt to meet servers where they are today?

…

On Thu, Apr 16, 2026 at 6:47 AM Alex Babeanu ***@***.***> wrote: *baboulebou* left a comment (openid/authzen#483) <#483 (comment)> Well, the question is then, shouldn't polymorphic tools be broken-up into separate ones? Could be done even if the underlying APIs are still the same and polymorphic... This is an implementation concern I think, not sure what else we could provide on the standard front to solve this, besides the flexibility of CEL as you illustrate. If it's hard to manage, then implementers should prob change their implementations... — Reply to this email directly, view it on GitHub <#483 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUGESR6PKUYS3LOWJPKWBT4WDP6TAVCNFSM6AAAAACXZM6P3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENRQGU2DSMZXGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>