Hopefully silly and simple, i am not seeing

POST

bodies in the logs, documentation leads me to believe what i have set in

hydra.yml

is sufficient.

log:
  level: trace
  leak_sensitive_values: true
  redaction_text: ""
  format: json

I believe/know

leak_sensitive_values

is working b/c it warns if its not. The reason i'm doing this is to thread through

contacts

as the

mcp-inspector

requires it be an

array

, yet is returned from

hydra

as

null

. I was hoping if it was threaded through it would be returned as an array. I can also modify the response. After i modify the request on the way in adding

contacts:[]

hydra says it can't parse the body, so i would simply like to see what is being received. So likely a multi-part question: 1 - Logging request bodies 2 - How have others solved the error from

mcp-inspector

that returns

[ { "code": "invalid_type", "expected": "array", "received": "null", "path": [ "contacts" ], "message": "Expected array, received null" } ]

In the second step of the Auth flow Thanks

The GitHub issue you commented on is the fix right now. Basically we are strictly expecting the proper types as outlined in the spec and the MCP-inspector tool just doesn’t send the key for contacts at all. Optimally if you are going to use DCR we really recommend you set that or tell your customers to. Otherwise you will get clients that you have no idea who they belong to.

I'm not commenting on the GH issue, but i have read it. I'm simply asking here the best way to address it.

Modify the inspector implementation of the MCP SDK to send an empty array on DCR. That is what I am doing. The issue is, the MCP spec/SDK have a really poor implementation of DCR (this is known to them and the next revision of the specification and SDKs is supposed to fix some of this).

OK, i see.

You could also fork Hydra and change the DCR validation to accept json null or missing props.

Appreciate it. Your post and comments on GH have been very helpful, yet if some friendly criticism is allowed... I'm not sure if the modification to add

contacts:[]

in

clientMetaData

is clear to any/most. I definitely missed it until you wrote it here. With the patch to oauth-state-machine, you did provide rationale. Again, thank you for all of it, comments or not.

Yeah I think we do need to be a bit more explicit on that! I’ll make sure to be so on the next update! It’s a bit of a chicken and the egg right now with MCP, but I expect with this next release things will be much more stable and easier to build against.

I get both sides of that, for sure...no shade coming your way 😉