DEV Community: Ravi Kumar

Order a Database in Plain English. Crossplane Platform APIs, Now AI-Ready!

Ravi Kumar — Wed, 14 Oct 2026 13:35:39 +0000

A developer needs a Postgres database for a new service.

On a Crossplane platform, the capability already exists. The platform team has published a database API, wired it to a Composition, and decided what "small" means. But to use it, the developer still has to find the right kind, read an XRD schema, write YAML, apply it, and then interpret Ready and Synced conditions when something does not come up.

The platform API is there. The experience of using it still assumes Crossplane knowledge, and a fair amount of YAML.

What if the developer could simply ask, in plain English?

Create a small Postgres database called orders-db.

And when it is not ready ten minutes later:

Why isn't orders-db ready?

That is what crossplane-mcp-server is for. It turns a Crossplane control plane into a set of AI-ready tools, so the platform APIs you already built can be discovered, used and troubleshot from any MCP-compatible assistant or agent.

Platform APIs are the product, access is the bottleneck

Crossplane's real achievement is not provisioning cloud resources. Plenty of tools do that. It is letting platform teams expose infrastructure as APIs they own: a PostgreSQLInstance or an App that hides provider details behind a contract the platform team controls.

That contract is exactly what you want application teams to consume. But today, consuming it usually means one of:

Learning enough Crossplane and Kubernetes to write and debug manifests.
Waiting for a portal, CLI or form that the platform team has to build and maintain.
Opening a ticket and waiting for the platform team.

Each of those puts the platform team back in the loop for work the API was meant to make self-service.

MCP: one interface for every AI client

The Model Context Protocol (MCP) is an open standard that lets AI applications discover and call tools exposed by a server. Write the integration once, and every MCP-compatible client can use it: Claude Desktop and Claude Code, Cursor, Windsurf, VS Code, Goose, and agent frameworks that speak MCP.

crossplane-mcp-server is that integration for Crossplane. It is a standard MCP server, configured like any other, that exposes your control plane as tools an assistant can reason with:

A person asks	The server provides
"What can I order from this platform?"	The platform APIs the control plane offers, from its XRDs
"What do I need to give you for a database?"	The fields that API accepts, with an example manifest
"Create a small Postgres database called orders-db."	A claim built from the API's own schema, with a dry run first
"Is it ready yet? Why not?"	The composition tree, the deepest failing resource and the provider's real error
"Is anything broken in production?"	Control plane health, unhealthy resources and package status
"What would deleting this destroy?"	The blast radius, before anyone acts

Nobody in that table named a Kubernetes kind. The server finds the platform API, reads its schema and fills it in. The developer works with the capability, not the implementation.

The server provides tools and live data; the MCP client provides the language model and the conversation. The assistant answers from what the control plane actually returns, not from what a model guesses.

Ordering a database in plain English

Here is the flow against the project's demo control plane. The developer asks for a database, in their own words, and wants to see it first:

Create a small Postgres database called orders-db. Show me the manifest before you create anything.

The assistant calls crossplane_database_create with a dry run. The server finds the database API this control plane offers, reads the schema its XRD declares, and returns exactly what would be submitted:

crossplane_database_create(name="orders-db", size="small", dryRun=true)

apiVersion: demo.crossplane.io/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: orders-db
  namespace: default
spec:
  parameters:
    engine: postgresql
    size: small
    version: "16"

The developer approves, the claim is created, and Crossplane does what it always does: reconciles it through the Composition the platform team wrote. The platform team still decides what a "small Postgres database" is. The developer never wrote a line of YAML or looked up a kind.

Why isn't my database ready?

Creating is not the same as Ready. When something fails, a generic Kubernetes tool can return objects, but it does not know how a claim leads to a composite, how a composite leads to managed resources, or that the useful error is usually in an event three levels down.

This server does. Ask why a claim is not ready and it walks the tree to the deepest failure:

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

Control plane checks:
CHECK         STATE   DETAIL
composition   OK      Composition "postgres-aws" exists.
providers     OK      all 3 provider(s) are Installed and Healthy

That is the difference between "something is wrong" and "fix the instance class in your Composition". The same Crossplane knowledge powers the rest of the toolset: drift detection between declared and observed state, finding what is holding up a stuck deletion, validating or rendering a Composition before applying it, and checking provider and function health.

Built so platform teams can say yes

Giving an AI assistant access to infrastructure is a trust decision. The server is designed so that decision can be made incrementally:

Read-only by default. Out of the box, the create and update tools are not registered at all, so a client cannot see or call them. Point it at production and it can explain everything and change nothing.
Writes are opt-in. Start the server with --read-only=false to let teams order through your platform APIs, ideally starting with a development control plane.
Nothing deletes. There is no delete tool and no delete call in the codebase. Ask it to delete a database and it can show the impact; a person runs the deletion.
Platform APIs only. Writes are limited to Crossplane kinds. The server refuses Secrets, Deployments and RBAC, no matter how it is asked.
Reviewable writes. Every write tool supports dryRun, writes are server-side applies under a named field manager, and created objects are labelled for easy discovery.
RBAC still decides. The example rbac-write.yaml grants create, update and patch on named platform API groups, with no delete verb.

A sensible rollout: connect read-only, let engineers troubleshoot with it, then enable ordering where the platform API and permissions are ready for self-service.

Works wherever your AI works

Because it is a standard MCP server, the same tools can reach developers in their editor, in a desktop assistant, or inside an AI-driven automation. A chat surface such as Slack can use it too, through an assistant or bridge that supports MCP. The project itself does not ship a Slack bot; MCP is the connection point, and the host application owns the chat experience and user identity.

For platform teams, that means maintaining one Crossplane integration instead of building a separate one for every assistant, portal and bot your organization adopts.

Get started in minutes

Install it, see what it exposes, and check it can reach your control plane:

go install github.com/ravibagri5/crossplane-mcp-server/cmd/crossplane-mcp-server@latest

crossplane-mcp-server tools
crossplane-mcp-server call crossplane_status

Installing from source needs Go 1.26 or newer; pre-built binaries and a container image are on the releases page. It is also listed in the official MCP Registry and on Smithery.

Then add it to your MCP client like any other server. For VS Code, in .vscode/mcp.json:

{
  "servers": {
    "crossplane": {
      "type": "stdio",
      "command": "crossplane-mcp-server",
      "args": ["--clusters", "staging,production"]
    }
  }
}

--clusters names the control planes the assistant may reach. Add --read-only=false to args on a development control plane when you want to order as well as inspect.

No Crossplane platform handy? The demo control plane runs on kind with provider-nop, so you can order fake databases and workloads, watch them reconcile, and try every tool without a cloud account.

The point

Crossplane already lets platform teams turn infrastructure into products. MCP makes those products reachable from the AI tools developers are adopting anyway. Put the two together and a platform API stops being something you need Crossplane expertise and YAML to use, and becomes something anyone on the team can ask for in plain English, inspect and understand, within the boundaries the platform team set.

Try crossplane-mcp-server, run the demo, and tell me which platform API you would put in front of your developers first.

We Treat Applications as Products. Why Is the Platform Still a Black Box? Introducing Platform BOM (PBOM)

Ravi Kumar — Wed, 14 Oct 2026 09:29:28 +0000

An application team can point to the feature it shipped this week. A platform team may have spent that same week making deployments safer, improving cluster reliability, tightening identity, or removing a recurring obstacle from dozens of teams.

The work matters. Its impact is just harder to see.

As a platform engineer, I have sometimes felt that platform work is not seen with the same importance as application development. I do not think this is because application teams misunderstand infrastructure, or because every organization undervalues its platform. It is often a visibility problem: application features connect directly to customers, while platform improvements create value indirectly, across many teams and over time.

That difference can make the platform look like a cost center or a collection of infrastructure tickets, even when it is a product that application teams rely on every day.

I want to help change that perspective. Platform engineering deserves to be treated as software product engineering: with users, capabilities, releases, feedback, and a clear account of what is running. That is the idea behind Platform BOM.

A platform is more than its infrastructure

An internal platform is not just Kubernetes, a cloud account, or a deployment pipeline. It is the set of capabilities and experiences that help teams build, deliver, and operate their products.

That may include Kubernetes, GitOps, networking, identity, policy, observability, data services, and the self-service workflows that connect them. The implementation can change while the capability a team depends on stays the same. A platform might replace one database provider with another without changing the promise that teams can request a supported PostgreSQL service.

This is why “platform as a product” is more than a slogan. A product has users and a purpose. It has capabilities, a roadmap, support expectations, and a lifecycle. It should evolve in response to user needs, not just accumulate tools because they are available.

The CNCF Platforms White Paper describes platforms as curated capabilities presented around the needs of internal users. It also calls out user experience, documentation, self-service, and reducing cognitive load as important platform attributes. DORA’s platform engineering guidance similarly emphasizes product thinking, developer needs, and measuring outcomes.

So the industry is not ignoring platform engineering. The discipline is increasingly recognized. But recognition does not automatically make a platform’s scope, health, or impact visible inside every organization. That is the gap I want to work on.

The questions we should be able to answer

If the platform is a product, we should be able to describe it without reconstructing it from memory every time someone asks:

What capabilities does the platform offer to application teams?
Which components implement those capabilities?
What is the declared platform release?
Which versions are actually running in development, staging, and production?
Where have environments drifted from their intended release?
Which upstream updates deserve attention?

In many organizations, the answers are spread across Helm releases, Git repositories, cluster APIs, dashboards, spreadsheets, and the knowledge of a few engineers. Each tool can be useful and still leave the platform itself difficult to describe as one product.

An application catalog can tell us which services exist and who owns them. A Kubernetes dashboard can show resources in a cluster. An SBOM describes the packages in a software artifact. These tools answer different questions. They do not, by themselves, connect a platform’s user-facing capabilities to the components and versions behind them across environments.

An inventory for the platform itself

Software teams use a Software Bill of Materials to describe what an artifact contains. Platform BOM applies a similar idea at a different level: describe a platform’s components, capabilities, releases, and environments, then compare what was intended with evidence of what is running.

To be precise, Platform Bill of Materials (PBOM) is a concept proposed by this project, not an established industry standard. The project does not claim CNCF endorsement or industry-wide adoption. The goal is to explore a useful model and make it practical enough for platform teams to try.

Platform BOM is an open-source, read-only inventory for platform teams. It connects a Git-declared platform and its releases with evidence discovered from Kubernetes, Helm, and Crossplane. It can compare environments with their target releases and show upstream versions that may need attention.

The model separates a few ideas that often get mixed together:

Offerings describe what platform users receive, such as GitOps delivery, metrics, or managed PostgreSQL.
Components describe the technologies behind those offerings.
Platform releases describe versioned baselines.
Environments and inventories describe where the platform runs and what discovery observed there.

That separation matters. Users depend on capabilities; platform teams operate implementations. If an implementation changes, the platform can record the change without pretending the user-facing capability disappeared.

What this looks like in practice

Platform BOM is deliberately observational. It does not install or upgrade components, and it does not compete with GitOps. Your existing deployment tools remain responsible for making changes; PBOM helps describe and compare the result.

For example, a platform team can declare that development, staging, and production should run a particular platform release. Discovery then gives the team evidence about the components found in each environment. If production is still on an earlier release, the difference is visible instead of being hidden in a spreadsheet or rediscovered during an incident.

The project includes a Helm chart and a getting-started guide. To try the released v0.9.0 chart on a cluster you are authorized to inspect:

helm upgrade --install pbom oci://ghcr.io/ravibagri5/charts/platform-bom \
  --version 0.9.0 \
  --namespace platform-bom --create-namespace --wait

kubectl -n platform-bom port-forward svc/pbom-platform-bom 8080:80

Then open http://127.0.0.1:8080. The default service account is read-only. Before sharing the UI, configure sign-in or an authenticating proxy, as described in the authentication guide. The getting-started guide walks through describing a platform and its release baselines in YAML.

The project is at v0.9.0 today. It includes multi-environment inventory, component and offering views, release comparison, upstream version information, cloud workload identity for supported managed Kubernetes environments, and OIDC or proxy-based authentication. Those are current capabilities, not a claim that every platform concern is solved.

What a BOM can and cannot prove

A platform inventory can make composition, declared releases, observed versions, and drift easier to discuss. That can support upgrade planning, operational reviews, and conversations about which capabilities the platform provides.

It cannot prove that developers are satisfied. It cannot show on its own that onboarding is faster, cognitive load is lower, or product outcomes have improved. Those questions need user feedback and outcome measures: task success, onboarding time, satisfaction, delivery performance, and other signals that make sense for the organization.

That distinction is important to me. A BOM should not become another dashboard used to justify building a platform nobody asked for. It should make the platform easier to understand, then help platform teams have better conversations with the people who use it.

Where the project is heading

The roadmap is a statement of direction, not a promise of dates. Areas under consideration and active development include:

A versioned API and integrations with tools such as Backstage and MCP clients.
More evidence from GitOps controllers and infrastructure-as-code systems.
Better upstream intelligence, including support windows, security advisories, and compatibility information.
Interoperability work, including exporting a platform release in an established format such as CycloneDX.
A shared PBOM specification, if the model proves useful beyond this project.

These are ways to make the platform easier to inspect and integrate with existing workflows. They are not reasons to replace the systems that already deploy, secure, or observe it.

Make the platform legible

Platform engineering is software engineering applied to shared capabilities and developer experience. If we expect platform teams to own products, we should also make it possible to describe those products: what they offer, how they are assembled, which release is intended, and what is actually running.

That is the problem I am exploring with Platform BOM. It is early, the resource model is still evolving, and the PBOM concept is not a standard. I would rather be explicit about those limits than imply the problem is already solved.

If you work on an internal platform, I would be interested in how your team answers these questions today. What do you track? What remains tribal knowledge? Which evidence sources or integrations would make a platform inventory genuinely useful in your workflow?

Explore the project, try the getting-started guide, or share feedback through GitHub Discussions.