Releases: kagent-dev/kmcp
Releases · kagent-dev/kmcp
v0.2.6
feat(crd): add default timeout field to MCPServerSpec (#121) ### Summary Adds a `Timeout` field to `MCPServerSpec` with a kubebuilder default of `30s`. This addresses [kagent-dev/kagent#1272](https://github.com/kagent-dev/kagent/issues/1272): MCP servers deployed via the MCPServer CRD use a sidecar gateway that spawns a new stdio process (e.g. via `uvx`/`npx`) for each session. Process startup can take 2–8 seconds depending on package cache state, which exceeds the default 5-second timeout used by some ADK clients (e.g. Python ADK `StreamableHTTPConnectionParams`), causing intermittent `"Failed to create MCP session"` errors. ### Context An initial fix was proposed in [kagent-dev/kagent#1275](https://github.com/kagent-dev/kagent/pull/1275) by making the timeout configurable via the Helm chart (env var → controller flag → handler threading). A maintainer [correctly pointed out](https://github.com/kagent-dev/kagent/pull/1275#issuecomment-) that the proper fix is to add this field to the MCPServer CRD itself, which: - Follows existing CRD patterns (`Port` has `+kubebuilder:default=3000`, `Replicas` has `+kubebuilder:default=1`) - Provides **per-resource granularity** (each MCPServer can specify its own timeout) - Eliminates complex threading through Helm/env/flags/handlers - Is the Kubernetes-idiomatic approach ### Changes | File | Description | |------|-------------| | `api/v1alpha1/mcpserver_types.go` | Add `Timeout *metav1.Duration` field with `+kubebuilder:default="30s"` | | `api/v1alpha1/zz_generated.deepcopy.go` | Regenerated via `make generate` | | `config/crd/bases/kagent.dev_mcpservers.yaml` | CRD manifest regenerated via `make manifests` | | `helm/kmcp-crds/templates/mcpserver-crd.yaml` | Helm CRD template updated to match | ### Backward Compatibility - The default value is `30s` — existing MCPServer resources without an explicit timeout will automatically get this default applied by the API server. - No breaking changes to existing CRs. ### Companion PR Once this is merged and released, I will create a new PR and the kagent controller will be updated to propagate this field: `ConvertMCPServerToRemoteMCPServer` propagates `MCPServer.Spec.Timeout` → `RemoteMCPServer.Spec.Timeout` Ref: [kagent-dev/kagent#1272](https://github.com/kagent-dev/kagent/issues/1272) Signed-off-by: skhedim <sebastien.khedim@gmail.com>
v0.2.5
feat: support custom service account for mcp deployments (#120) Closes #112 --------- Signed-off-by: Jet Chiang <pokyuen.jetchiang-ext@solo.io>
v0.2.4
feat: add tls configuration in mcpserver (#114)
I tried to deploy an MCPServer. During the deployment, the kagent
controller attempts to list tools from the MCP backend over HTTPS, but
it fails with the following error:
> "reconcileID":"c77f3b32-f68a-443d-8a1f-b56a1fe7d3a9","error":"failed
to upsert tool server for remote mcp server default/dahu-mcp: failed to
fetch tools for toolServer default/dahu-mcp: failed to initialize client
for toolServer default/dahu-mcp: transport error: request failed with
status 400: Client sent an HTTP request to an HTTPS server.\n"
To address this, I think we should enhance MCPServer by adding an
HTTPTransportTLS field, so users can customize the TLS client
configuration (e.g., client certificate/key and CA bundle) when
connecting to the MCP server. An example:
```yaml
apiVersion: kagent.dev/v1alpha1
kind: MCPServer
metadata:
name: test-mcp
spec:
transportType: http
httpTransport:
targetPort: 8443
path: /
tls:
secretRef: test-tls-client # Custom client certificate used to access the MCP server
deployment:
image: ghcr.io/test/test-mcp:v0.1.0
port: 8443
args:
- --http-addr
- :8443
- --tls-cert
- /etc/tls/tls.crt
- --tls-key
- /etc/tls/tls.key
# Explicitly create the volume
volumes:
- name: tls-certs
secret:
secretName: test-tls-server
volumeMounts:
- name: tls-certs
mountPath: /etc/tls
readOnly: true
Signed-off-by: dahu.kdh <dahu.kdh@alibaba-inc.com>
v0.2.3
feat: add tls configuration in mcpserver (#114)
I tried to deploy an MCPServer. During the deployment, the kagent
controller attempts to list tools from the MCP backend over HTTPS, but
it fails with the following error:
> "reconcileID":"c77f3b32-f68a-443d-8a1f-b56a1fe7d3a9","error":"failed
to upsert tool server for remote mcp server default/dahu-mcp: failed to
fetch tools for toolServer default/dahu-mcp: failed to initialize client
for toolServer default/dahu-mcp: transport error: request failed with
status 400: Client sent an HTTP request to an HTTPS server.\n"
To address this, I think we should enhance MCPServer by adding an
HTTPTransportTLS field, so users can customize the TLS client
configuration (e.g., client certificate/key and CA bundle) when
connecting to the MCP server. An example:
```yaml
apiVersion: kagent.dev/v1alpha1
kind: MCPServer
metadata:
name: test-mcp
spec:
transportType: http
httpTransport:
targetPort: 8443
path: /
tls:
secretRef: test-tls-client # Custom client certificate used to access the MCP server
deployment:
image: ghcr.io/test/test-mcp:v0.1.0
port: 8443
args:
- --http-addr
- :8443
- --tls-cert
- /etc/tls/tls.crt
- --tls-key
- /etc/tls/tls.key
# Explicitly create the volume
volumes:
- name: tls-certs
secret:
secretName: test-tls-server
volumeMounts:
- name: tls-certs
mountPath: /etc/tls
readOnly: true
Signed-off-by: dahu.kdh <dahu.kdh@alibaba-inc.com>
v0.2.2
fix(cli): fix generated Go MCP server run and doc (#104) This fixes the kmcp run command for mcp servers generated with kmcp init go and updates the generated README with the accurate file paths ### Before these change kmcp run results in the following error ``` Running server directly: go run main.go Server is running and waiting for MCP protocol input on stdin... Press Ctrl+C to stop the server stat main.go: no such file or directory Error: exit status 1 ``` ### After these changes - Docs reference the proper file paths - `kmcp run` uses the right path to main.go to start the server - The mcp inspector server config uses the right path to main.go Signed-off-by: kevdkr <48852657+kevdkr@users.noreply.github.com>
v0.2.1
fix: controller to reconcile on label changes (#103) - Fixes an issue where label changes do not trigger reconciliation. --------- Signed-off-by: JM Huibonhoa <jm.huibonhoa@solo.io>
v0.2.0
refactor: add extension config (#100) Add extension config to `main.go` to allow extension configs to be provided directly to the controller. This allows downstream forks to easily extend the main controller with plugins and additional schemes easily. --------- Signed-off-by: JM Huibonhoa <jm.huibonhoa@solo.io>
v0.1.9
add configurable init container image (PR 1007 from kagent) (#92) fixes #91 (code from https://github.com/kagent-dev/kagent/pull/1007/files) Signed-off-by: Peter Jausovec <peter.jausovec@solo.io>
v0.1.8
fix: Push images workflow failure (#84) Fixes an issue introduced in https://github.com/kagent-dev/kmcp/pull/79 where we were trying to retag a pushed image that wasn't available in our local repository in our CI workflow. Signed-off-by: JM Huibonhoa <jm.huibonhoa@solo.io>
v0.1.7
Add extension points (#78) adds extension points for downstream forks / extensions of the core kmcp code base