Certification progress (ready to start testing next week)
Notes
Obligations
AlexB: will be a new profile, will be shared next week
MCP Profile
AlexO: Built a reference implementation
AlexB: Do we need logic in the mappings? Conidtionally set values
AlexO: Swapping to CEL from JSONPath would let us do this to some degree
Atul: Agree on using CEL (AlexO added a PR for that to the ref implementation)
Atul: Q from Martin whether this would need approval from MCP community - don't think so as it doesn't change the way MCP work it just adds more feilds
AlexO: What to do if mapping fails
Atul: Deny by default. If you specify the mapping at initialization time fail at startup.
AlexB: If the client doesn't know about COAZ, what should it do?
Atul: The client should just ignore it - its more informational
The client agent LLM could populate the coaz mapping with the eight parameters.
Error code when mapping field - must be an MCP error code for that
The profile needs to consider that the connections to MCP are stateful, the access token is evaluated at session init. Thereafter, we need RPC error messages.
Should we add custom errors to MCP?
Atul: we need this to be compatible for clients not aware of coaz, hence reuse existing MCP error
Julio: these are JSON-RPC codes.
Custom codes are possible, but then the clients need to understand them.
AlexO: does every MCP tool have its own schema? - Profile implementation demo + Also using CEL
Last missing pieces:
how to handle error cases.
CEL definition
Define input data schemas: is it necessary?
AlexO: We need an attribute map between data input and CEL expressions, should be agnostic. At minimum there should be a token lement in the inut dtaa schema
AlexB: the MCP server must first create an input data JSON for CEL resolution. The incoming messages need to be passed in and serve as a source/reference. The "params" object of the tool called should be enough to pass to the mapping engine.
=> pass-in the Name + Arguments + Token