with one click
deploying-vmcp-locally
Deploys a VirtualMCPServer configuration locally for manual testing and verification
Menu
Deploys a VirtualMCPServer configuration locally for manual testing and verification
| name | deploying-vmcp-locally |
| description | Deploys a VirtualMCPServer configuration locally for manual testing and verification |
This skill helps you deploy and test VirtualMCPServer configurations in a local Kind cluster for manual verification.
Before using this skill, ensure you have:
If no Kind cluster exists, create one with the ToolHive operator:
# From the toolhive repository root
task kind-with-toolhive-operator
This creates a Kind cluster named toolhive with:
If you need to test local code changes:
# Set up cluster with e2e port mappings
task kind-setup-e2e
# Install CRDs
task operator-install-crds
# Build and deploy local operator image
task operator-deploy-local
Apply the YAML configuration you want to test:
kubectl apply -f <path-to-vmcp-yaml> --kubeconfig kconfig.yaml
Check the VirtualMCPServer status:
# List all VirtualMCPServers
kubectl get virtualmcpserver --kubeconfig kconfig.yaml
# Get detailed status
kubectl get virtualmcpserver <name> -o yaml --kubeconfig kconfig.yaml
# Check operator logs for issues
kubectl logs -n toolhive-system -l app.kubernetes.io/name=thv-operator --kubeconfig kconfig.yaml
For NodePort service type (useful for local testing):
# Get the NodePort
kubectl get svc vmcp-<name> -o jsonpath='{.spec.ports[0].nodePort}' --kubeconfig kconfig.yaml
# Test the endpoint (port will be on localhost when using kind-setup-e2e)
curl http://localhost:<nodeport>/mcp
For ClusterIP (default), use port-forward:
kubectl port-forward svc/vmcp-<name> 4483:4483 --kubeconfig kconfig.yaml
curl http://localhost:4483/mcp
Use an MCP client to verify tool discovery and execution:
# Initialize MCP session
curl -X POST http://localhost:<port>/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc": "2.0", "method": "initialize", "params": {"protocolVersion": "2024-11-05", "capabilities": {}, "clientInfo": {"name": "test", "version": "1.0"}}, "id": 1}'
# List tools
curl -X POST http://localhost:<port>/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc": "2.0", "method": "tools/list", "id": 2}'
When done testing:
# Remove specific resources
kubectl delete -f <path-to-vmcp-yaml> --kubeconfig kconfig.yaml
# Or destroy the entire cluster
task kind-destroy
Reference example configurations are in examples/operator/virtual-mcps/:
| File | Description |
|---|---|
vmcp_simple_discovered.yaml | Basic discovered mode configuration |
vmcp_conflict_resolution.yaml | Tool conflict handling strategies |
vmcp_inline_incoming_auth.yaml | Inline authentication configuration |
vmcp_production_full.yaml | Full production configuration |
composite_tool_simple.yaml | Simple composite tool workflow |
composite_tool_complex.yaml | Complex multi-step workflows |
composite_tool_with_elicitations.yaml | Workflows with user prompts |
Check that:
kubectl describe virtualmcpserver <name> --kubeconfig kconfig.yaml
kubectl get mcpgroup --kubeconfig kconfig.yaml
kubectl get mcpserver --kubeconfig kconfig.yaml
Verify backend servers have the correct groupRef:
kubectl get mcpserver -o custom-columns=NAME:.metadata.name,GROUP:.spec.groupRef --kubeconfig kconfig.yaml
For testing, use anonymous auth:
incomingAuth:
type: anonymous
authzConfig:
type: inline
inline:
policies:
- 'permit(principal, action, resource);'
Guide for using ToolHive CLI (thv) to run and manage MCP servers and skills. Use when running, listing, stopping, building, or configuring MCP servers locally. Covers server lifecycle, registry browsing, secrets management, client registration, groups, container builds, exports, permissions, network isolation, authentication, and skill management (install, uninstall, list, info, build, push, validate). NOT for Kubernetes operator usage or ToolHive development/contributing.
Validates operator chart contribution practices (helm template, ct lint, docs generation) before committing changes.
Creates ToolHive release PRs by analyzing commits since the last release, categorizing changes, recommending semantic version bump type (major/minor/patch), and triggering the release workflow. Use when cutting a release, preparing a new version, checking what changed since last release, or when the user mentions "release", "version bump", or "cut a release".
Implements a GitHub user story from planning through PR creation, with research, codebase analysis, and structured commits.
Generates polished GitHub release notes for a ToolHive release by analyzing every merged PR, cross-referencing linked issues, dispatching expert agents to assess breaking changes, and producing a formatted release body. Use when the user provides a GitHub release URL, tag name, or says "release notes".
Finds flaky tests on the main branch by analyzing GitHub Actions failures, ranks them by frequency, and enters parallel plan mode to design deflake strategies. Use when you want to find and fix the flakiest tests.