Add the ability to override global Service configuration per invocation using Tool definition

[luigidemasi]

support the configuration override like this one:

    {
        "name": "get_weather", 
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            }
            "_configuration.xxxxx=yyyyy": {
              "type": "string",
              "description": "configuration xxxx for the service"
            }
          },
          "required": ["location"]
        }
      }

[orpiske]

@luigidemasi I have been thinking about this one and also #186 and #187. One thing that I've considered for #187 was to add class and scope properties to the arguments. Something like this:

{
        "name": "get_weather", 
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
              "class": "argument"
              "scope": "llm"
            }
          },
          "required": ["location"]
        }
      }

Then, we could bundle all these changes so that

 xxxxx=valueXXXX": {
        "type": "string",
         "description": "configuration xxxx for the service",
         "class": "configuration",
         "scope": "service",
},
 zzzz=valueZZZZ": {
        "type": "string",
         "description": "header zzzz for the service",
         "class": "header",
         "scope": "service",
},
aaaa=valueAAAA": {
        "type": "string",
         "description": "configuration aaaa for the service endpoint",
         "class": "configuration",
         "scope": "service-endpoint",
}

The idea here is that the class identifies the purpose* (i.e.: where to be used) and the scope identifies to where it applies (i.e.: llm is something to be used by the model, service is something to be used by a downstream service, server would be used by Wanaku MCP, and so on).

What do you think?

With that, we could simplify and consolidate a lot of the handling of these parameters.

[luigidemasi]

I like it, but I would go further, I would add the value property to the body, like:

 "xxxxx": {
        "type": "string",
         "description": "configuration xxxx for the service",
         "class": "configuration",
         "scope": "service",
         "value": "valueXXXX"
},
 "zzzz": {
        "type": "string",
         "description": "header zzzz for the service",
         "class": "header",
         "scope": "service",
         "value": "valueZZZZ"
},
"aaaa": {
        "type": "string",
         "description": "configuration aaaa for the service endpoint",
         "class": "configuration",
         "scope": "service-endpoint",
         "value": "valueAAAA"
}

wdyt?

[orpiske]

I like it, but I would go further, I would add the value property to the body, like:

"xxxxx": {
"type": "string",
"description": "configuration xxxx for the service",
"class": "configuration",
"scope": "service",
"value": "valueXXXX"
},
"zzzz": {
"type": "string",
"description": "header zzzz for the service",
"class": "header",
"scope": "service",
"value": "valueZZZZ"
},
"aaaa": {
"type": "string",
"description": "configuration aaaa for the service endpoint",
"class": "configuration",
"scope": "service-endpoint",
"value": "valueAAAA"
}

wdyt?

This is much better.

+1 from me.

[orpiske]

I'm going to go ahead and merge #187. Once we have this fix in the code, then I can do a second pass and improve the URI building/parsing code so that I can leverage the new properties.