Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Read-only access to a Crossplane control plane: resources, claims, packages, compositions.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
You need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"crossplane": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"ghcr.io/ravibagri5/crossplane-mcp-server:0.1.5"
]
}
}
}Run this in your terminal
claude mcp add crossplane -- docker run -i --rm ghcr.io/ravibagri5/crossplane-mcp-server:0.1.5Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"crossplane": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"ghcr.io/ravibagri5/crossplane-mcp-server:0.1.5"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"crossplane": {
"type": "stdio",
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"ghcr.io/ravibagri5/crossplane-mcp-server:0.1.5"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 8, 2026
The registry name was verified with the GitHub account ravibagri5, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (0.1.5) reached the registry 2 months ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Docker on your computer.
In the same category: Spec Driven Development, Remote Desktop Commander, Talexio MCP by usefulapi
Servers in the same category from other makers, sorted by stars.
Reading a card:↓ Downloads per weeki★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Read employees, approved pay lines, approved time off and shift templates in Talexio.
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
A Model Context Protocol server that lets AI assistants understand a Crossplane control plane.
Ask your assistant *"how many managed resources do I have and is anything broken?"* and it will answer from your actual control plane, with the reason for every failure, instead of guessing.
> Why is the app-db claim not ready?
crossplane_diagnose(kind="PostgreSQLInstance", name="app-db")
PostgreSQLInstance app-db is NOT READY.
Verdict: Instance/app-db-rds is the deepest failure: InvalidParameterValue: the instance class db.t2.mega does not exist
Root causes (deepest failing resources): KIND NAME READY SYNCED REASON DETAIL Instance app-db-rds False False ApplyFailure InvalidParameterValue...
Control plane checks: CHECK STATE DETAIL composition OK Composition "postgres-aws" exists. providers OK all 3 provider(s) are Installed and Healthy
Fix the instanceClass field in your Composition and the claim will reconcile.
The server is read-only by default: the tools that create and update are not registered at all unless you start it with --read-only=false, so a client cannot see them, let alone call them. Nothing deletes in either mode. Turn writes on and the same assistant can provision from your platform APIs:
> Create a small Postgres database called orders-db.
crossplane_database_create(name="orders-db", engine="postgresql", size="small")
Created PostgreSQLInstance default/orders-db on kind-crossplane.
apiVersion: demo.crossplane.io/v1alpha1 kind: PostgreSQLInstance metadata: name: orders-db namespace: default spec: parameters: engine: postgresql size: small version: "16"
Next: provisioning is asynchronous. Call crossplane_resource_tree with {"kind":"PostgreSQLInstance","name":"orders-db"} to watch it come up.
Nothing there names a Kubernetes kind. The tool found the platform API this control plane offers, read the schema its XRD declares and filled it in. See examples/demo for a control plane you can try it on without a cloud account.
A general purpose Kubernetes MCP server can already reach every object on a Crossplane control plane: Crossplane resources are Kubernetes resources, and a generic resources_list with an apiVersion and a kind will happily return your XRDs. Access was never the problem.
The problem is that it does not know what any of it means, and it will happily delete it.
| Generic Kubernetes MCP | This server | |
|---|---|---|
| Reach Crossplane CRDs | Yes | Yes |
| Follow a claim to the infrastructure it created | No. It returns objects; the model has to guess which field to follow at each hop | crossplane_resource_tree walks resourceRefs for you |
| Say which resource is actually at fault | No | crossplane_diagnose finds the deepest failure, not the symptom at the top |
| Notice infrastructure changed outside Crossplane | No. It can return spec and status but has no idea they are meant to match | crossplane_drift_detect diffs desired against observed |
| Explain why a delete is hanging | No | crossplane_deleting_resources names the Usage, finalizer or provider holding it |
| Say what a delete would destroy first | No | crossplane_impact reports the blast radius before you act |
| Simulate a change without touching the cluster | No | crossplane_composition_render runs the function pipeline offline |
| Write to your cluster | Yes, always: create, update, delete, exec | Only if you ask. Off by default, never deletes, limited to Crossplane kinds, and it provisions through your platform APIs rather than writing managed resources by hand |
That last row matters more here than it does for ordinary Kubernetes work. On a Crossplane control plane a deleted object is not a pod that a ReplicaSet will recreate, it is a production database. Point this server at production and it cannot mutate anything; point it at a development control plane with --read-only=false and it still cannot delete a resource, and cannot touch a Secret, a Deployment or an RBAC rule at all.
Underneath, the Crossplane knowledge this server encodes is:
managed, composite, claim), so it works with every provider without being taught about any of them.Ready/Synced on resources and Installed/Healthy on packages, and explains the difference to the model.resourceRefs to build the composition tree, the same view as crossplane beta trace.Observe-only resource is never corrected, which is the difference between a warning and a non-event.spec.crossplane reference location.go install github.com/ravibagri5/crossplane-mcp-server/cmd/crossplane-mcp-server@latest
crossplane-mcp-server tools
crossplane-mcp-server call crossplane_status
Then add it to your MCP client (see Client configuration) and ask it about your control plane.
go install. The pre-built binaries and the container image have no such requirement.crossplane_composition_render. Rendering executes the composition function pipeline, which cannot be done through the Kubernetes API. Every other tool needs nothing beyond API access, and crossplane_composition_validate covers most of the same ground without a container runtime.go install github.com/ravibagri5/crossplane-mcp-server/cmd/crossplane-mcp-server@latest
docker run --rm -i \
-v "${HOME}/.kube:/home/nonroot/.kube:ro" \ ghcr.io/ravibagri5/crossplane-mcp-server:latest
Pre-built binaries for Linux, macOS and Windows are attached to every release. These are the easiest option if you do not have a recent Go toolchain.
git clone https://github.com/ravibagri5/crossplane-mcp-server.git
cd crossplane-mcp-server make build ./bin/crossplane-mcp-server tools
This server is listed in:
io.github.ravibagri5/crossplane-mcp-server, which is where MCP clients look it up.{
"mcpServers": { "crossplane": { "command": "crossplane-mcp-server", "args": ["--clusters", "staging,production", "--context", "staging"], "env": { "PATH": "/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin", "HOME": "/Users/you" } } } }
PATH and HOME matter whenever a kubeconfig context authenticates through an exec plugin such as kubelogin or aws. Desktop applications launch servers with a near-empty environment, so without them the plugin is either not found or cannot read its token cache.
In ~/.config/goose/config.yaml:
extensions:
crossplane: enabled: true type: stdio cmd: /path/to/crossplane-mcp-server args: ["--clusters", "staging,production", "--context", "staging"] envs: PATH: /opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin HOME: /Users/you timeout: 300
Add --read-only=false to args to let goose provision as well as inspect. examples/demo walks through that end to end on a throwaway cluster.
Add to .vscode/mcp.json in your workspace:
{
"servers": { "crossplane": { "type": "stdio", "command": "crossplane-mcp-server", "args": ["--clusters", "staging,production"] } } }
{
"mcpServers": { "crossplane": { "command": "docker", "args": [ "run", "--rm", "-i", "-v", "${HOME}/.kube:/home/nonroot/.kube:ro", "ghcr.io/ravibagri5/crossplane-mcp-server:latest" ] } } }
Run crossplane-mcp-server tools to print this list from your build.
resourcesManaged resources, composite resources and claims.
| Tool | What it answers |
|---|---|
crossplane_managed_resources_summary | How many managed resources exist, by kind, and how many are Ready and Synced |
crossplane_managed_resources_list | Which managed resources exist, optionally only the failing ones |
crossplane_composite_resources_list | Which composite resources (XRs) exist and which Composition each selected |
crossplane_claims_list | Which claims exist and which composite each is bound to |
crossplane_resource_get | Everything about one resource: conditions, external name, events, manifest |
crossplane_resource_tree | The composition tree below a claim or composite, with per-resource status |
crossplane_resource_events | The events Crossplane recorded against one resource |
crossplane_diagnose | Why a resource is not Ready, and which resource is actually at fault |
| crossplane_drift_detect | Which infrastructure no longer matches its declared spec, and whet
Only the beginning is shown; read the rest in the repo