Feat: Add MCP client caching configuration to Configuration Plans

[Vaishnav88sk]

Closes #323

Description

This PR introduces support for customizing the MCP client-side caching configuration (ttlMs and cacheScope) per Configuration Plan, as requested in #323. Previously, caching hints for tools/list and tools/read were hardcoded to 30000ms and public.

With this change, administrators can explicitly define these settings in the UI or via the API, which the proxy will use during MCP interactions (protocol ≥ 2026-07-28).

Changes

• Database: Added caching_configuration (JSONB) to the configuration_plan table (Flyway V1.5.0).
• API / Control Plane: Added cachingConfiguration field to ConfigurationPlan, ConfigurationPlanDTO, and eds-v1.proto.
• Proxy: Removed hardcoded values in McpController and wired it to read from the dynamically loaded ConfigurationEntry.
• Web UI: Added "Cache TTL (ms)" and "Cache scope" inputs to the Operations section in PlanEditor.svelte.

Verification

vaishnavsk@vaishnav88:~$ curl -s -X POST http://localhost:7777/mcp/reshapr/dummy/1.0 \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | python3 -m json.tool
{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "resultType": "complete",
        "tools": [
            {
                "name": "get_hello",
                "inputSchema": {
                    "type": "object",
                    "properties": {},
                    "required": [],
                    "additionalProperties": false
                }
            }
        ],
        "ttlMs": 120000,
        "cacheScope": "private"
    }
}

[Vaishnav88sk]

/hold
Adding CLI rel code

[Vaishnav88sk]

/unhold

Updated CLI code:

vaishnavsk@vaishnav88:~/reshapr/cli$ reshapr service list
ID             NAME           VERSION  TYPE  AGE
0RDKX7826076H  Dummy Service  1.0.0    REST  76s
vaishnavsk@vaishnav88:~/reshapr/cli$ reshapr config create my_plan -s 0RDKX7826076H --be http://localhost:8080 --ct 15000 --cs private
✅ Configuration plan 'my_plan' created successfully with ID: 0RDKXKPD207FX
vaishnavsk@vaishnav88:~/reshapr/cli$ reshapr config list
ID             NAME          SERVICE        BACKEND                API_KEY  OAUTH2_CONFIG  AUDIT
0RDKX78SE07BW  default       0RDKX7826076H  http://localhost:8080  No       No             No
0RDKX919Y07FG  my-test-plan  0RDKX7826076H  http://localhost:8080  No       No             No
0RDKXKPD207FX  my_plan       0RDKX7826076H  http://localhost:8080  No       No             No
vaishnavsk@vaishnav88:~/reshapr/cli$ reshapr config get 0RDKXKPD207FX -o json
{
  "id": "0RDKXKPD207FX",
  "organizationId": "acme",
  "name": "my_plan",
  "serviceId": "0RDKX7826076H",
  "backendEndpoint": "http://localhost:8080",
  "includedArtifacts": [],
  "audit": false,
  "cachingConfiguration": {
    "ttlMs": 15000,
    "cacheScope": "private"
  }
}
vaishnavsk@vaishnav88:~/reshapr/cli$ 

[lbroudoux]

This is really great! I have one doubt about the naming. ConfigurationPlan.cacheConfiguration is a bit long and redundant, IMO. I wonder if we could shorten this:

• configurationPlan.cacheConfig?
• configurationPlan.cache?
• configurationPlan.cachePolicy? => if we consider that Template is the best naming option for Allow the definition of reusable configuration elements via a Policy or Template concept #326...

What do you think?

[Vaishnav88sk]

Thanks, Laurent! I totally agree that cachingConfiguration is a bit long and redundant.

I think cachePolicy is the best option here. It aligns perfectly with standard API gateway terminology since we are defining strict rules (like TTL and Scope) for this specific plan.

It also ties in perfectly with the discussion in #326! If we stick with Template for #326 (which acts as a blueprint to quickly initialize values), it makes total sense that a Template would populate the cachePolicy inside a ConfigurationPlan.

I'll go ahead and update the database, API payloads, CLI, and Web UI to use the new name!

[lbroudoux]

It looks great! Thanks @Vaishnav88sk, for this big contribution!