ResourceTemplate completion functions need access to previous parameter values for context-aware auto-completion

[dudo]

Description

When implementing ResourceTemplate completion functions, there's no way to access the current state or values of previously selected parameters. This makes it impossible to provide intelligent, context-aware auto-completion.

Use Case

For a Kubernetes resource template like kubernetes://resources/{resourceType}/{namespace?}, we want to:

1. Show all resource types for the first parameter
2. Skip namespace selection entirely if the selected resourceType is cluster-scoped (like nodes)
3. Show only relevant namespaces if the resourceType is namespaced

Currently, the namespace completion function has no way to know what resourceType was selected.

Current API

complete: {
  resourceType: async (_arg: string): Promise<string[]> => { /* ... */ },
  namespace: async (_arg: string, _context?: any): Promise<string[]> => {
    // _context is undefined - no way to know what resourceType was selected
  }
}

Desired API

complete: {
  resourceType: async (_arg: string): Promise<string[]> => { /* ... */ },
  namespace: async (_arg: string, context: { resourceType?: string }): Promise<string[]> => {
    if (context.resourceType === 'nodes') {
      return []; // Skip namespace selection for cluster-scoped resources
    }
    // Return namespaces for namespaced resources
  }
}

Benefits

• Better UX: Skip unnecessary parameter selection when it doesn't apply
• Smarter completion: Show only relevant options based on previous selections
• Reduced errors: Prevent invalid combinations of parameters
• Dynamic templates: Templates can adapt behavior based on user choices

Examples

• Kubernetes: Skip namespace for cluster-scoped resources
• Cloud resources: Show only regions that support the selected service
• File systems: Show only valid subdirectories based on the selected parent path

Current Workaround

We have to show all possible options regardless of context, leading to poor UX and potential errors.

Impact

This limitation makes ResourceTemplates less powerful and user-friendly than they could be, especially for complex hierarchical resources.