Name and Version
dial-core 0.46.3
What is the problem this feature will solve?
Toolsets defined in aidial.config.json with authentication_type: OAUTH must carry client_id, client_secret, authorization_endpoint and token_endpoint. Dynamic client registration (ResourceAuthSettingsService.processResourceAuthSettings -> ResourceRegistrationService) runs only for toolsets created through the API (ToolSetService.putToolSet) or via the repair endpoint. ConfigPostProcessor.processToolSets only validates names, so a file-defined toolset with just an endpoint and authentication_type: OAUTH is served exactly as written.
Clients then see no client_id / authorization_endpoint in auth_settings, mark the toolset as misconfigured, and sign-in cannot start.
Example: Glean's remote MCP server (https://<tenant>-be.glean.com/mcp/default) publishes RFC 9728 protected-resource metadata, points at an authorization server with a registration_endpoint, and supports DCR. Today it can only be declared in the config file by first creating a static OAuth client in the Glean admin console and putting the credentials into the secret config.
#1239 added authenticated toolsets to the config file, but only the static shape; it does not state that DCR is out of scope for file-defined toolsets.
What is the feature you are proposing to solve the problem?
When a file-defined toolset has authentication_type: OAUTH and no client_id / client_secret, run the same discovery + dynamic registration that the API create path uses, either at config load or lazily on the first sign-in, and persist the resulting registration alongside the platform toolset. That way the repair / re-registration work discussed in #1854 applies to file-defined toolsets as well.
What alternatives have you considered?
Name and Version
dial-core 0.46.3
What is the problem this feature will solve?
Toolsets defined in
aidial.config.jsonwithauthentication_type: OAUTHmust carryclient_id,client_secret,authorization_endpointandtoken_endpoint. Dynamic client registration (ResourceAuthSettingsService.processResourceAuthSettings->ResourceRegistrationService) runs only for toolsets created through the API (ToolSetService.putToolSet) or via the repair endpoint.ConfigPostProcessor.processToolSetsonly validates names, so a file-defined toolset with just anendpointandauthentication_type: OAUTHis served exactly as written.Clients then see no
client_id/authorization_endpointinauth_settings, mark the toolset as misconfigured, and sign-in cannot start.Example: Glean's remote MCP server (
https://<tenant>-be.glean.com/mcp/default) publishes RFC 9728 protected-resource metadata, points at an authorization server with aregistration_endpoint, and supports DCR. Today it can only be declared in the config file by first creating a static OAuth client in the Glean admin console and putting the credentials into the secret config.#1239 added authenticated toolsets to the config file, but only the static shape; it does not state that DCR is out of scope for file-defined toolsets.
What is the feature you are proposing to solve the problem?
When a file-defined toolset has
authentication_type: OAUTHand noclient_id/client_secret, run the same discovery + dynamic registration that the API create path uses, either at config load or lazily on the first sign-in, and persist the resulting registration alongside the platform toolset. That way the repair / re-registration work discussed in #1854 applies to file-defined toolsets as well.What alternatives have you considered?