universal-tool-calling-protocol/python-utcp

feat: Add auth_tools support for flexible OpenAPI authentication

Closed this issue · 0 comments

Problem

Currently, the OpenAPI converter only processes standard OpenAPI security schemes, which limits flexibility for UTCP-specific authentication requirements. Users need a way to specify authentication configuration that will be properly recognized and applied to generated UTCP tools without requiring complex environment variable management.

Current Limitations

  • Rigid Authentication: OpenAPI converter relies solely on security schemes defined in the spec
  • Environment Variable Complexity: Users must manage complex variable substitution for different authentication scenarios
  • Limited Flexibility: No way to override or customize authentication for specific use cases
  • Plugin Inconsistency: Different authentication approaches across HTTP and text plugins

Proposed Solution

Introduce an auth_tools field that allows users to:

  1. Specify Custom Authentication: Define authentication independently of OpenAPI security schemes
  2. Selective Application: Apply authentication only to compatible endpoints
  3. Maintain Compatibility: Preserve existing behavior for public endpoints
  4. Cross-Plugin Consistency: Unified authentication approach across HTTP and text plugins

Use Cases

  • API Key Override: Use different API keys than those specified in OpenAPI spec
  • Local OpenAPI Files: Apply authentication to tools generated from local specs (text plugin)
  • Development/Testing: Easy switching between different authentication configurations
  • Multi-Environment: Different auth configs for dev/staging/prod without spec changes

Expected Behavior

{
 "name": "my_api",
 "call_template_type": "http",
 "url": "https://api.example.com/openapi.json",
 "auth_tools": {
   "auth_type": "api_key",
   "api_key": "Bearer ${API_TOKEN}",
   "var_name": "Authorization",
   "location": "header"
 }
}

This would apply the specified authentication to all compatible tools generated from the OpenAPI spec, while leaving public endpoints unchanged.