docs: Add tool discovery proposal#227
Conversation
Signed-off-by: Gloire Rubambiza <gloire@ibm.com>
✅ Deploy Preview for kube-agentic-networking ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: rubambiza The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @rubambiza. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Tip We noticed you've done this a few times! Consider joining the org to skip this step and gain Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/ok-to-test |
Signed-off-by: Gloire Rubambiza <gloire@ibm.com>
|
/cc |
david-martin
left a comment
There was a problem hiding this comment.
Given the XBackend resource won't be in v1alpha1, we should hold this for now.
I see the value in having a controller being able to list and report back tools from mcp servers for more than AccessPolicy tool validation. For example, it can help with configuration validation, or surfacing of tools for informational purposes beyond auth.
I tend to like the standalone (extension?) approach, as making it a required piece could be a barrier to some agentic networking implementations, and could potentially be unwanted in some installations for various reasons (unwanted load, difficult to configure auth for some mcp servers)
/hold
|
|
||
| ## Non-Goals | ||
|
|
||
| - **`tools/list` response filtering.** Filtering the `tools/list` response |
There was a problem hiding this comment.
Good to call this out.
I wonder, should we be more explicit to avoid confusion here as there are 2 identities at play here.
The identity to use when this new controller calls tools/list for populating the backend status,
and the identity when an agent/user is calling tool list?
The latter tool/list filtering I see as dynamic at list time, performing an authZ function, and driven by the rules in AccessPolicy
| **Phase 1: In-cluster discovery (plain HTTP).** XBackend status extension, | ||
| discovery controller, schema validation, `list_changed` support, drift | ||
| detection. The controller connects to backends using the service name and port | ||
| from `XBackend.spec.mcp` over plain HTTP. This is sufficient for in-cluster |
| 5. **Updates** `XBackend.status.discoveredTools[]` with validated tools only. | ||
| 6. **Listens** for `tools/list_changed` notifications on backends that declare | ||
| the `listChanged` capability, triggering immediate re-discovery. | ||
| 7. **Falls back to polling** (configurable interval, default 30s) for backends |
There was a problem hiding this comment.
30s probably too aggresive.
5 minutes maybe?
| An `XAccessPolicy` referencing a non-existent tool receives a Warning: | ||
|
|
||
| ```yaml | ||
| apiVersion: agentic.prototype.x-k8s.io/v0alpha0 |
There was a problem hiding this comment.
agentic.networking.x-k8s.io
| ### AccessPolicy Validation | ||
|
|
||
| The existing AccessPolicy reconciler is extended to cross-reference | ||
| `rules[].authorization.tools[]` against `XBackend.status.discoveredTools`: |
There was a problem hiding this comment.
note the change to method based matching in v1alpha1
Will need to consider that and update here.
Summary
tools/liston MCP backends, validates schemas, and surfaces discovered tools inXBackend.statuskubectl, and a foundation for response filteringPhasing
Prior discussion
This proposal was initially drafted and reviewed on the fork PR (rubambiza#1) with feedback from @evaline-ju and @david-martin incorporated.
Test plan