TL;DR: GitHub just launched the MCP Registry, a central hub to discover, trust, and install Model Context Protocol (MCP) servers. This isn’t just a developer convenience—it’s the foundation for how we’ll compose APIs, AI, and agents into workflows. At La Rebelion Labs, we see this as validation of the path we’re already on with the HAPI MCP Stack.

Why this matters now

Let’s be real:

• APIs are everywhere. Every system has one, but discovery and integration are still messy.

• AI agents need context. Without structured ways to plug into APIs, they hallucinate, break, or fail silently.

• Builders are stuck. Too much time is lost searching for integrations, worrying about trust, and duplicating work.

GitHub’s MCP Registry solves the discovery problem: one place to find vetted MCP servers, right inside VS Code or any MCP-compatible environment.

But the bigger story? This is how API-first architectures evolve into AI-ready ecosystems.

🧩 What is MCP, really?

• Model Context Protocol (MCP) is a standard that lets AI agents fetch fresh, trusted context from external systems.

• It is the “API for AI Agents”: plug in a new server (like Slack, Jira, Stripe, LinkedIn, Strava, Kubernetes, you name it), and your AI agent instantly knows how to use it.

  We’ve been saying it for months: API-first solutions are the easiest to transform into AI-first. MCP is the bridge.

⚡ GitHub’s big move: The MCP Registry

Here’s what GitHub shipped:

1. Central Directory – a hub of MCP servers, from partners and the community. Each point links to a GitHub repo, so you can inspect the code and trust what you install.

2. 1-Click Install – With GitHub Copilot in VS Code, you can add MCP servers without digging through documentation or repositories. (I am more in favor of remote servers, but we still have plenty implemented with stdio transport 🤷🏽‍♂️).

3. Trust Signals – ranking and metadata (stars, activity, provenance) help filter noise.

4. Open Ecosystem – anyone can publish to the OSS MCP Community Registry, which then syncs into GitHub’s directory.

This can be translated into spending less time searching, reducing the risk of guessing, and increasing building speed.

💡 Why this aligns with La Rebelion Labs’ vision

At La Rebelion Labs, we’ve been building the HAPI MCP Stack—a framework where APIs and AI meet:

• HAPI Server → headless API instances that expose REST + MCP endpoints.

• OrcA → an orchestrator to visually design Arazzo-compliant workflows in VS Code.

• QBot & runMCP → tools to simplify how developers test and consume MCP servers.

  • RunMCP is, by itself, an MCP registry. 🤓

The MCP Registry? It’s the missing puzzle piece that confirms this movement. GitHub just made it mainstream.

When you put GitHub’s registry + HAPI Stack together, you get a whole supply chain for AI integrations:

• Discover → find servers in the Registry.

• Deploy → run them via HAPI Server.

• Compose → orchestrate with OrcA.

• Consume → connect through RESTful or MCP Clients!

This isn’t theory. It’s already working in our stack.

🏢 Business Translation: What leaders should care about

• Faster time-to-market with safer, standardized AI integrations. The risk of “shadow AI tools” decreases when discovery and trust are centralized.

• Accelerate feature delivery. Instead of writing custom integrations, pick from the MCP servers, or transform Swagger into MCPs. Example: Connect your roadmap tool (e.g., Jira, Linear) to AI workflows in days, not quarters.

• Better UX with AI copilots that actually know your stack. Fewer broken prompts, more consistent results.

• Stop reinventing integrations. Utilize trusted MCP servers and focus your energy on addressing unique problems.

🌍 Ecosystem impact

This shift is bigger than GitHub:

• Standardization: Just like OCI standardized containers, MCP + registries will standardize AI toolchains.

• Open Collaboration: The OSS MCP Community Registry ensures anyone—startups, enterprises, hobbyists—can contribute.

• Trust Layer: Verified metadata and provenance become the guardrails for enterprise adoption.

The registry is the App Store moment for MCP servers.

🔮 What’s next

We’re still early. Expect:

• Self-publishing flows: easier ways to push MCP servers into the registry.

• Metadata maturity: verification, usage metrics, security scans.

• Enterprise overlays: private registries for regulated environments.

• Composable AI stacks: where registries, orchestrators, and agents form complete ecosystems.

La Rebelion Labs is already exploring airgap registries, extended SBOMs for MCP servers, and multi-cloud distribution—bridging GitHub’s registry to zero-trust and enterprise needs.

✅ What to do now

• Developers: Explore the MCP Registry and try installing a server that matches your workflow (e.g., GitHub Issues, Slack, Kubernetes)… or spin up an MCP Server from your Swagger.

• Product Leaders: Audit your roadmap. Where could MCP servers accelerate delivery?

• Security Teams: Define Your Internal MCP Trust Policy. What’s approved? What’s blocked?

• Innovators: Think beyond tools. How will MCP reshape your business model?

🚀 Bottom line

GitHub’s MCP Registry is more than a directory. It’s a signal: the future of API + AI is composable, discoverable, and trusted.

At La Rebelion Labs, we’re building alongside this wave with the HAPI MCP Stack.

👉 If you want to survive (and thrive) in the new agentic era, start with MCP servers. The registry is your gateway.

Go Rebels! ✊🏽

That world is here.

OpenAI's allowing to connect Model Context Protocol (MCP) has just crossed a huge milestone: ChatGPT can now connect with "custom" MCP Servers. And with HAPI MCP Servers, you can start building and connecting your own today in seconds.

But there's a caveat: right now, ChatGPT only works if your MCP Server implements two specific tools: search and fetch. Don't worry—I'll guide you through setting it up, explain what it means, and show you why this makes a significant difference.

What Is MCP, and Why Should You Care?

Let's break it down.

• APIs today: Think of APIs as doors. If you have the right key (credentials, documentation, SDK), you can open them. But every door looks different. Some are REST, some GraphQL, some gRPC. Some are well-documented, others are a nightmare.

• MCP's promise: MCP standardizes how AI models like ChatGPT talk to APIs. Instead of building one-off integrations, you build a server that follows the MCP spec. Once that's done, ChatGPT automatically knows how to talk to it. (or any other MCP-compatible client, i.e. Claude Desktop, QBot).

• The business angle: This isn't just technical elegance—it's faster integrations, less developer overhead, and reduced cost of maintaining custom connectors. That means faster time to market and lower risk.

In short: MCP turns APIs into AI-ready services.

⚡ The Big News: ChatGPT Meets Custom MCPs

Until now, ChatGPT has only worked with a fixed set of tools. Think of them as pre-installed apps. Useful, but limiting.

Now? You can bring your own MCP Server into ChatGPT. That's like installing your own app in the App Store of AI.

With HAPI MCP Servers, the door is open:

• You define your MCP logic (Swagger/OpenAPI, custom code, etc).

• You expose it through the MCP standard (one command line to start).

• ChatGPT connects and can be immediately used.

But there's a catch…

⚠️ The Caveat: search and fetch

Here's the current limitation (at least as of when this was written): ChatGPT will only talk to custom MCP Servers that expose two specific tools:

1. search – Let’s ChatGPT ask your server what resources are available.

   • Think of it like browsing an API catalog.

   • Example: ChatGPT can "search" for available endpoints, functions, or datasets.

2. fetch – Let’s ChatGPT request a resource by name.

   • Think of it like hitting "download" on the resource you found.

   • Example: ChatGPT can "fetch" a specific record, report, or file.

👉 Without these two, ChatGPT won't know how to interact with your MCP Server, and as of now, it won't work at all, even if your MCP server exposes other tools. You will get an error: “This MCP server doesn’t implement our specification. “

This is important. It means that if you're building your own MCP, you need to start with search and fetch as your baseline tools, at least for now, if you want ChatGPT to connect.

🛠️ Step 1: Build Your First MCP with HAPI

Here's where it gets exciting.

With HAPI MCP Servers, you don't have to reinvent the wheel. HAPI gives you a framework to:

• Take your API logic.

• Wrap it in MCP's protocol.

• Expose it so ChatGPT can connect.

Think of HAPI as a Gateway for MCP Servers—a lightweight, flexible way to spin up a server that speaks MCP fluently.

🧩 Step 2: Point HAPI to your OpenAPI/Swagger (auto-generates search)

With HAPI MCP Servers, you don't implement search. HAPI reads your OpenAPI/Swagger spec and auto-builds the resource catalog, exposing a standards-compliant search tool automatically.

What to do:

• Provide your OpenAPI/Swagger spec (file or URL).

• Start HAPI MCP against that spec.

Example (pay attention to the --chatgpt flag):

# Local file
hapi serve petstore --headless --chatgpt

# Or remote spec
hapi serve --openapi https://petstore3.swagger.io/api/v3/openapi.json

Result:

• search is available immediately, listing operations/resources derived from your spec (endpoints, tags, summaries, etc.).

• No custom code required.

🧩 Step 3: Zero‑code fetch (auto-generated)

You also don't implement fetch. HAPI maps each searchable resource to a concrete retrieval operation using your OpenAPI details (paths, params, auth, and response schemas).

What you get:

• fetch executes the proper request and returns JSON/text per the spec.

• Response shaping and content-type handling come out of the box.

Optional:

• You can override defaults (e.g., auth, headers, timeouts), but it's not required for ChatGPT connectivity.

🔌 Step 4: Connect It to ChatGPT

OpenAI's MCP docs show how to connect MCP Servers. Here's the gist:

1. Run your HAPI MCP Server locally or in the cloud.

   1. If you run it locally, use a tool like ngrok to expose it publicly.

   2. If you want to run it in the cloud, install it on any VM server or use runMCP.

2. Go to your ChatGPT settings → Connectors → Create.

3. Fire up ChatGPT and test!

From that point on, ChatGPT treats your MCP like a first-class citizen. Ask it:

"What's in my Q1 Revenue Report?"

And instead of hallucinating, ChatGPT fetches real data from your MCP. Is RAG from your own systems!

Demo Time!

Here's a quick demo of how it works in practice:

🎯 Business Impact: Why This Matters

Let's translate the tech into business value.

• For executives: This reduces integration costs and speeds up AI adoption.

• For PMs: You can now think of MCPs as product features. Want ChatGPT to "understand your platform"? Wrap your API in MCP and ship it.

• For engineers: It's one spec to learn. One server to implement. No more writing custom ChatGPT plugins.

• For designers & end-users: It means faster, smoother, and more reliable AI-powered workflows. Less "Sorry, I don't know that" and more real answers from real systems.

📚 A Guided Path: From Zero to MCP

Here's how you can get started:

1. Read the MCP spec – OpenAI's MCP docs.

2. Use HAPI – the quickest way to spin up your MCP Server.

3. Start small – customize search and fetch. Test them with ChatGPT.

4. Iterate – add more tools once the basics work.

And remember: these are early days. My expectations are high. The current limitation (only search + fetch) will expand. Soon, you'll be able to expose more advanced tools and workflows. 🤞🏽

What's Next?

Here's where I see this going:

• Beyond search and fetch – Future versions of ChatGPT will support richer tools. Imagine create, update, delete, or even full workflow orchestration.

• Enterprise MCPs – Companies will wrap entire business systems in MCP to make them AI-ready.

• Agent-to-Agent Communication – MCP makes it possible for different AI agents (not just ChatGPT) to talk to the same backend services consistently.

This isn't just a developer milestone—it's a paradigm shift for AI-powered business workflows.

✅ Final Thoughts

The integration of ChatGPT with custom MCP Servers is one of those rare shifts that unlocks a cascade of possibilities.

Today, it's simple: implement search and fetch. Tomorrow, it's expansive: AI systems deeply integrated with your data, tools, and workflows.

With HAPI MCP Servers, you don't just consume this future—you build it.

So, the question isn't "Should I try this?" It's: How fast can you wrap your API in MCP and let ChatGPT talk to it?

🔗 Resources

• OpenAI MCP Documentation

• HAPI MCP Servers

That’s the vision behind QBot, my new CLI MCP client built to help DevOps practitioners interact with their infrastructure using natural language.

This started as a Sunday afternoon experiment. I stumbled upon a $1 promo code for OpenAI and decided to give Codex a spin. My goal: generate a Claude Code + Codex-style clone that could serve as the foundation for QBot. To my surprise, the first MVP came together quickly—and it’s already powerful enough to be useful.

Thanks to the HAPI MCP Stack, connecting QBot to any MCP server became not only possible but seamless.

What QBot Can Do Today

With the MVP, here’s what I can already do in just a few steps:

• Connect to an MCP server.

• List all available tools.

• Call tools directly—or simply type prompts in natural language.

• Configure the LLM provider and model on the fly.

That means I can now interact with my MCP server and my infrastructure as if I were chatting with a colleague.

Demo: QBot in Action

Here’s a quick example using the classic Petstore API (a favorite for demos because it’s simple and widely available).

$ qbot --url http://localhost:3000/mcp
QBot • MCP REPL  Type text to chat, /help for commands
➜ Connected to http://localhost:3000/mcp
qbot> /tools
... removed for brevity ...  
qbot> /llm status
Provider: ollama
Model: llama3.1:latest
Keys: (none)
Base URLs: ollama
qbot> get pet with ID 1
➜ Calling tool getPetById
assistant: The pet with ID 1 has the following details:

* Category: Cats (ID 2)
* Name: Cat 1
* Photo URLs: url1, url2
* Tags: tag1, tag2
* Status: available
qbot> delete order with ID 10
➜ Calling tool deleteOrder
assistant: Order with ID 10 has been deleted successfully.
qbot> /exit

Simple, right? No SDK setup. No boilerplate code. Just type what you need, and QBot handles the rest.

👉 I’ve included a full video walkthrough of the demo below so you can see it in action.

What’s Next for QBot

The MVP is just the beginning. I’m already exploring ways to extend QBot with:

• Few-shot prompts for more context-aware interactions.

• Tool chaining to run multi-step workflows automatically. (The AI formula: OAS + MCP + Arazzo)

• Deeper integration with infrastructure APIs so DevOps tasks become as easy as chatting.

Ultimately, QBot aims to become the CLI sidekick every DevOps practitioner wishes they had.

Why This Matters

Infrastructure is getting more complex, not less. Kubernetes, multi-cloud, APIs everywhere—DevOps teams are drowning in tools and dashboards. A conversational CLI like QBot flips that complexity on its head.

Instead of memorizing commands, you can describe your intent—and let QBot translate that into precise API calls. That’s where the HAPI MCP Stack shines. It provides the foundation for exposing APIs in a standard, machine-readable way, so tools like QBot can plug in and just work.

If you’re exploring how MCP can simplify your workflows, I’d highly recommend checking out the HAPI Stack—it’s the backbone of everything I’m building here.

Final Thoughts

This is just the start, but I’m excited about where QBot is heading. Imagine pairing natural language with infrastructure automation—suddenly, DevOps feels less like firefighting and more like flow.

I’d love to hear what you think:

• What features would you like to see in QBot?

• How would you use a conversational CLI in your workflow?

Drop your thoughts in the comments, and stay tuned for updates.

Be HAPI. 😁 Go Rebels! ✊🏽

In this post, I'll show you how to take a Swagger (OpenAPI) specification and, with just one command, spin up an MCP server ready to power copilots, agents, and AI-native applications.

And here's the kicker: you won't write a single line of code.

👉 At the end, you'll also find the video walkthrough where I demo this live.

TL;DR

For those in a hurry, here's the TL;DR:

• MCP standardizes how AI agents interact with APIs, eliminating the need for custom integrations.

• You can convert OpenAPI specs into MCP servers effortlessly, and you can have an MCP server up and running in minutes, making your APIs AI-ready.

• This approach saves time, reduces costs, and future-proofs your API strategy.

That's not all, from the date this post was written (September, 2025), many things are happening in the MCP ecosystem, AI time is moving fast:

Here's some great news! You can now explore MCP-related skills on Skills.sh, making it easier to work with MCP servers and APIs. For specific details, check out Agent skills.

If you're interested in building MCP servers using OpenAPI specs, be sure to visit hapi.mcp.com.ai. Plus, our community offers fantastic tools: convert OpenAPI to MCP with swagger-to-mcp skill and evaluate MCP servers with mcp-server-evaluations skill.

Business Impact First

When considering the adoption of MCP, it's essential to understand the tangible benefits it brings to both technical teams and business stakeholders.

For businesses, MCP eliminates the need for costly and time-consuming custom integrations. Standardizing how APIs interact with AI agents reduces the reliance on fragile, one-off connectors that often lead to maintenance headaches. This translates directly into cost savings and reduced operational risk.

From a time-to-market perspective, MCP accelerates the process of making APIs AI-ready. Instead of spending weeks or months building glue code, teams can leverage MCP to instantly expose their APIs to AI agents. This means businesses can respond faster to market demands and stay ahead of competitors.

Moreover, MCP positions organizations for the future. As AI agents become a standard part of digital ecosystems, having APIs that are already consumable by these agents ensures future-proofing. This strategic alignment not only supports innovation but also minimizes disruption as AI adoption grows.

For executives, MCP aligns with broader business strategies by enabling agility and reducing technical debt. For engineers, it simplifies workflows, allowing them to focus on delivering value rather than wrestling with integration challenges.

In short, MCP bridges the gap between technical efficiency and business impact, making it a win-win for all stakeholders.

🤔 What is MCP, Really?

MCP (Model Context Protocol) is like REST for AI agents.

• It defines how agents (Copilot, LangChain, custom LLMs, etc.) can discover, connect to, and use APIs.

• It standardizes interactions so we don't reinvent integration every time.

• It's designed to be open, language-agnostic, and scalable.

If you think about it, APIs revolutionized cloud services by making them programmable. Similarly, MCP is transforming APIs into agent-consumable interfaces. To achieve this, API providers can leverage their existing OpenAPI specifications to seamlessly expose their APIs in a way that MCP clients can readily understand and utilize; that's why MCP and OpenAPI are a perfect match.

🛠️ The Technical Challenge

Traditionally, if you wanted your AI copilot to talk to your API, you had to:

1. Write custom wrappers.

2. Manually map endpoints to AI tools.

3. Deal with endless schema alignment issues.

This is fragile, time-consuming, and expensive.

Enter HAPI: Your Shortcut to MCP Servers

Imagine a tool that takes your Swagger/OpenAPI specification and, with minimal effort, transforms it into a fully functional MCP server. That's exactly what HAPI does.

HAPI is a framework designed to simplify the process of creating MCP servers. It eliminates the complexity of manual integration by instantly exposing your API as an MCP server. With HAPI, you can bridge the gap between your APIs and AI agents in just a few steps—no coding required.

Whether you're working with a simple API or a complex enterprise-grade system, HAPI ensures that your APIs are AI-ready, scalable, and easy to manage. It's the ultimate enabler for teams looking to unlock the potential of AI-driven applications without the usual headaches of custom development.

Get the latest version of HAPI from GitHub.

⚡ The Simplest Way to Create an MCP Server

Here's how I did it in the demo video (below):

1. Start with Swagger Spec

I used the famous PetStore Swagger example. This gives us a simple API with endpoints like:

• GET /pet/{id} → Get pet by ID

• GET /pet/findByStatus → Find pets by status

No coding needed. Just the API spec.

2. Store the Spec Locally

Download the spec and save it locally. This gives us a blueprint of endpoints and operations.

3. Run HAPI

Now the magic:

hapi serve petstore --headless

That's it.

• --headless tells HAPI to consume services from the backend directly (the head).

• The MCP server is now running locally on port 3000.

4. Connect to VS Code

Open VS Code, add an MCP server configuration:

{
  "name": "Petstore MCP",
  "url": "http://localhost:3000/mcp"
}

Start the server, connect, and you'll see 19 tools exposed automatically.

🔍 Putting It to the Test

Once connected, you can:

• Ask your AI copilot: "Get pets by status available."

• The LLM resolves the correct MCP tool (findPetsByStatus).

• The response comes back instantly, just like hitting the API.

Example:

[
  {
    "id": 10,
    "name": "doggie",
    "category": {
      "id": 1,
      "name": "Dogs"
    },
    "photoUrls": [
      "string"
    ],
    "tags": [
      {
        "id": 0,
        "name": "string"
      }
    ],
    "status": "available"
  }
]

And it works the same if you hit the API directly.

🎯 Why This Matters for AI Agents

With MCP:

• AI copilots don't need custom wrappers anymore.

• LLMs can auto-discover tools via your API spec.

• You can control which endpoints are exposed to the agent (important for governance and security).

This transforms any API into an AI-first product.

🔒 Sneak Peek: Adding OAuth2

In the next step (and in the upcoming video), I'll show how you can inject OAuth2 authentication directly into the Swagger spec.

• No extra code.

• HAPI auto-detects the auth configuration.

• You can integrate with providers like Authentik seamlessly.

This makes MCP servers not just easy but also enterprise-ready.

📺 Watch the Walkthrough

Here's the full demo where I set up the MCP server in real time:

FAQ

What is MCP (Model Context Protocol)?

MCP is a standard that lets AI agents discover and use tools exposed by APIs in a consistent, secure, and auditable way.

What is the fastest way to convert an OpenAPI (Swagger) spec into an MCP server?

Use HAPI. With a single command like hapi serve <project> --headless, you can generate an MCP server without writing custom code.

Do I need to write code to create an MCP server from Swagger/OpenAPI?

No. HAPI can turn an OpenAPI v3 spec into an MCP server with zero custom code. Skill available: swagger-to-mcp.

Does MCP work with OpenAPI v2 (Swagger 2.0)?

HAPI requires OpenAPI v3.x. If you have Swagger 2.0, convert it to OpenAPI v3 first.

Where is the MCP endpoint when using HAPI?

By default, MCP is available at http://localhost:3000/mcp (or the port you configure).

How do AI agents discover tools in MCP?

Agents call tools/list on the MCP server, which returns the tool catalog derived from your OpenAPI operations.

Can I control which API endpoints are exposed as tools?

Yes. You can limit exposure by curating your OpenAPI spec or providing a filtered spec for MCP generation.

Is MCP secure for enterprise use?

Yes, when deployed with proper auth (OAuth2, API keys, etc.) and policy enforcement at the boundary. MCP keeps authority outside the model.

Can I deploy MCP servers to the cloud?

Yes. HAPI supports deployments to Cloudflare Workers, Docker, Fly.io, and other environments.

How do I test if my MCP server works?

Check /health, call ping, list tools with tools/list, and run a sample tool call. You can also use the mcp-server-evaluations skill for a structured test.

What’s the difference between MCP and REST?

REST is an API style. MCP is a protocol for how AI agents discover and invoke tools, often backed by REST APIs.

How does MCP improve SEO/AEO for APIs?

It makes APIs machine-discoverable for AI agents, increasing tool discoverability and enabling answer engines to access structured actions.

✊ Go Rebels

At La Rebelion, we believe in tools that remove friction and let engineers (and businesses) focus on what matters: building value.

MCP is more than just another protocol. It's the bridge between your APIs and the AI-native future.

So, go ahead. Try it with your own Swagger spec. You'll see just how easy it is.

The future of API integration is agent-first. And it starts with MCP.

💡 Pro tip: Share this with your engineering team and product leaders. MCP will impact both sides of the business equation — execution and strategy.

In one word: everything.

We’re standing on the edge of a new era in AI automation—where workflows that once took weeks to wire up across APIs, SDKs, and custom scripts could soon be described, orchestrated, and executed seamlessly.

Why This Formula Matters

The combination of OpenAPI, MCP, and Arazzo is transformative for AI-powered automation:

• OpenAPI provides a universal language to describe APIs—a trusted blueprint that ensures clarity and consistency across systems.

• MCP introduces a native protocol for LLMs to interact with APIs directly—eliminating hacks and workarounds. It acts as the bridge, enabling seamless communication between AI agents and APIs.

• Arazzo serves as the orchestration layer, defining workflows as portable, spec-driven processes. It’s the glue that binds everything together.

This synergy means you’re no longer confined to a single ecosystem and vendor lock-in like n8n, LangFlow, Flowise, or traditional engines like Temporal or Camunda. With Arazzo as the workflow layer, you can orchestrate processes across any system while maintaining the confidence and reliability of an API-first approach.

By leveraging these standards, you unlock a future where AI workflows are not only powerful but also portable, scalable, and ecosystem-agnostic.

The result? An LLM can take “Place an order for SKU123” and autonomously execute the workflow across services with full visibility.

MCP + OpenAPI in Action

Imagine you’ve got an API for order processing:

sequenceDiagram
    participant User
    participant LLM as LLM (via MCP)
    participant OrderAPI as Order Processing API (OpenAPI)
    User->>LLM: "Place order for SKU123"
    LLM->>OrderAPI: MCP call to create order
    OrderAPI-->>LLM: Order confirmation
    LLM->>User: "Order placed successfully!"

Adding Arazzo to the mix

Now, let’s say placing an order involves multiple steps: checking inventory, processing payment, and sending a confirmation email. Here’s how Arazzo orchestrates that process in a structured, spec-driven way:

arazzo: 1.0.0
info:
  title: AI Order Workflow
  version: 1.0.0
workflow:
  - step: checkInventory
    description: "Verify if the requested SKU is available in inventory."
    call:
      operationId: getInventory
    next: [createOrder]
  - step: createOrder
    description: "Create an order for the requested SKU after inventory confirmation."
    call:
      operationId: postOrder
    next: [sendConfirmation]
  - step: sendConfirmation
    description: "Send a confirmation email to the user after the order is successfully created."
    call:
      operationId: postEmail

This YAML specification defines a clear, step-by-step workflow for placing an order. Each step is described with its purpose, the API operation it calls, and the next step(s) in the sequence. This makes the workflow not only executable but also easy to understand and maintain.

How does this play out in practice? Here’s the sequence of interactions visualized:

sequenceDiagram
    participant User
    participant LLM as LLM<br>(via MCP Client)
    participant Arazzo as (Arazzo)<br>Workflow Engine
    participant InventoryAPI as Inventory API (HAPI)
    participant OrderAPI as Order Processing API (HAPI)
    participant EmailAPI as Email Service API (HAPI)

    User->>LLM: "Place order for SKU123"
    LLM->>+Arazzo: Start order workflow
    Arazzo->>InventoryAPI: Check inventory for SKU123
    InventoryAPI-->>Arazzo: Inventory available
    Arazzo->>OrderAPI: Create order for SKU123
    OrderAPI-->>Arazzo: Order created successfully
    Arazzo->>EmailAPI: Send confirmation email
    EmailAPI-->>Arazzo: Email sent successfully
    Arazzo-->>-LLM: Order workflow completed
    LLM->>User: "Order placed successfully!"

In this diagram:

1. The User initiates the process by requesting to place an order in natural language.

2. The LLM, using the MCP protocol, delegates the workflow execution to the Arazzo Workflow Engine.

3. Arazzo orchestrates the steps:

   • It first checks the inventory via the Inventory API.

   • If inventory is available, it proceeds to create the order using the Order Processing API.

   • Finally, it sends a confirmation email through the Email Service API.

4. Once all steps are completed, Arazzo reports back to the LLM, which informs the user of the successful order placement.

Because this workflow is defined in a spec-driven manner, it is portable across platforms like n8n, LangFlow, Temporal, or Camunda. Arazzo ensures that the logic remains consistent and reusable, regardless of the underlying execution engine.

This approach not only simplifies complex workflows but also makes them scalable, maintainable, and transparent—key factors for building robust AI-powered automation systems.

The real business impact

Executives care about cost, speed, and risk. Developers care about standards and reusability. Operators care about observability and maintainability.

This formula speaks to all of them:

• Faster integration = faster time-to-market

• Standards = reduced tech debt and vendor lock-in

• Clear orchestration = predictable, auditable AI-powered workflows

It’s not just about building cool AI toys—it’s about building resilient, future-proof business systems.

Why I’m excited about Arazzo

The Arazzo Spec feels like the orchestration layer AI has been waiting for. Imagine telling your AI agent not just what API to call (that’s OpenAPI), or how to connect to it (that’s MCP), but also why, when, and in what order.

That’s Arazzo. That’s AI workflows as code.

This opens the door to something bigger: cross-platform automation without silos.

Where the HAPI Stack fits

The HAPI Stack for MCP explores how these standards—OpenAPI, MCP, and now Arazzo—can accelerate the API-First + AI-Orchestration future. Instead of reinventing the wheel every time, we’re building with standards-first tooling that makes it easier to go from idea → workflow → production.

What is your take?

I’d love to hear your take

• Do you see Arazzo becoming the universal glue for workflows?

• How do you imagine AI agents benefiting from an OpenAPI + MCP + Arazzo formula?

• What opportunities—or challenges—do you see for your teams or projects?

Check out the Arazzo spec here: Arazzo Latest Draft and the deep dive here: Swagger Blog.

Let’s spark a conversation about what’s next—because this might just be the foundation of AI-native automation.

Go Rebels! ✊🏽

• OIDC is now officially published as ISO/IEC standards (nine specs) in October 2024.

• ISO brand means it’s trusted globally and meets governments’ legal rules.

• ISO versions have all updates and fixes built in, so they’re cleaner and more stable.

• For companies, this means easier compliance, better interoperability, and stronger product trust worldwide.

🎯 What Does the ISO Version Include Technically?

ISO/IEC 26131–26139 (2024) cover:

• Core OIDC flows (authentication, claims, ID tokens)

• Discovery, dynamic client registration

• Front-channel and back-channel logout, session management

• Response encoding like OAuth response-mode/form-post, multiple response handling

These make up the full family of essential OIDC functionality—certified as international standards.

Why This Moment Matters

OpenID Connect (OIDC) has been the de facto standard for user authentication, but it wasn’t formally an international standard. Every organization interpreted or patched it slightly differently. The result: identity technical debt at scale.

Fast forward to October 2024. OpenID Connect is now published as an ISO/IEC standard (ISO/IEC 26131–26139). This isn’t just symbolic. It’s a clean ledger moment: a way to pay down accumulated debt, unify digital identity practices, and prepare for what’s next — the agentification era powered by AI and the Model Context Protocol (MCP).

This post explores:

• Why OIDC becoming ISO is a business and technical milestone

• How it aligns with the Technical Debt Model

• What this means for the rise of AI agents and MCP ecosystems

• How enterprises can act now to leverage this milestone strategically

What Does OIDC Becoming ISO Mean?

A Quick Refresher

• OpenID Connect (OIDC): A simple identity layer on top of OAuth 2.0, enabling apps to verify user identities and fetch profile data securely.

• ISO/IEC 26131–26139: The family of international standards formally publishing OIDC as a global standard, incorporating all corrections and clarifications accumulated since its original release in 2014.

Why It Matters Now

1. Compliance and Trust: ISO standards are recognized globally by governments and regulators. For industries like banking, healthcare, and telecom, this unlocks new adoption opportunities.

2. Consolidation: Multiple OIDC drafts, errata, and extensions are now unified into a stable, internationally recognized baseline.

3. Future Alignment: Extensions like Financial-grade API (FAPI) and eKYC are already being prepared for ISO. This sets a path for the entire identity ecosystem.

OIDC ISO Through the Lens of the Technical Debt Model

Principal: The Cost We’ve Accumulated

Organizations have been carrying identity debt for years:

• Supporting multiple OIDC drafts across vendors

• Maintaining custom flows for session management, logout, or claims

• Rewriting integrations due to inconsistent interpretation

Interest: The Daily Penalties

Every day this debt continues:

• Security risk increases (misapplied patches, outdated flows)

• Compliance costs rise (auditors chasing mismatched versions)

• Engineering time is wasted maintaining divergent code

Repayment Plan: ISO Adoption as Debt Reduction

• Short term: Audit existing identity flows, mapping them against the ISO/IEC baseline.

• Medium term: Update configurations and require ISO alignment in vendor contracts.

• Long term: Use ISO as the single source of truth, reducing spec fragmentation permanently.

Future Investment: Avoiding New Debt

By adopting ISO OIDC now, organizations build on a foundation that:

• Prepares them for FAPI, eKYC, and AI-integrated identity standards

• Ensures future AI agents can authenticate in globally interoperable ways

The AI Agentification Era Meets ISO OIDC

Why AI Agents Need Strong Identity

AI agents — autonomous, API-driven entities — are becoming the new workforce. They:

• Access enterprise APIs

• Execute workflows across cloud environments

• Act on behalf of humans and organizations

But here’s the catch: without a trusted, standardized identity, agents become security risks. Rogue, spoofed, or misconfigured agents could wreak havoc.

The Role of MCP (Model Context Protocol)

MCP is a new REST-like protocol for LLMs to interact with tools and APIs. It provides context-sharing and interoperability across agent ecosystems. But MCP itself relies on identity assurances to:

• Authenticate agents

• Authorize actions

• Ensure interoperability across organizations

Where OIDC ISO Fits

With OIDC as ISO:

• Agents authenticate securely across ecosystems

• MCP servers trust external agents without one-off integrations

• Global interoperability becomes possible — a government AI agent in Europe can authenticate with an enterprise API in the US without legal or technical headaches

Real-World Case Studies

Banking and Finance

Banks adopting FAPI (Financial-grade API) need rock-solid authentication. Before ISO, regulators hesitated because OIDC was a community spec. With ISO/IEC recognition:

• Banks can rely on a globally certified baseline.

• Cross-border financial transactions become smoother.

• AI-powered finance agents (e.g., portfolio optimizers) can operate across institutions securely.

Healthcare

Hospitals and telemedicine providers struggle with identity silos across systems. An ISO-standard OIDC allows:

• Unified patient login across multiple providers

• Secure AI agents acting as digital health assistants

• Compliance with strict privacy laws (HIPAA, GDPR)

Government Digital IDs

National ID programs increasingly rely on OIDC (e.g., Gov.UK Sign-In, European eIDAS pilots). ISO formalization means:

• OIDC can now be used in legally binding digital identity frameworks.

• Government AI agents can authenticate into regulated ecosystems without custom bridges.

Telecom

Telecom operators adopting GSMA Open Gateway need standard APIs for cross-carrier services. ISO OIDC provides:

• A trusted baseline for API authentication.

• AI agents (e.g., fraud-detection bots) that can move across carrier networks securely.

Why Executives, PMs, and Engineers Should Care

Executives: Reducing Risk, Unlocking Growth

• Compliance-ready: ISO-certified OIDC reduces regulatory headaches

• Market expansion: Enables secure partnerships in finance, healthcare, telecom

• Future-proofing: Establishes trust in AI agent ecosystems before regulations catch up

Product Managers: Selling ISO OIDC as a Feature

• “Audit-ready login” for compliance-focused customers

• “Government-grade authentication” for global enterprises

• Interoperable identity as a competitive differentiator

Engineers: Less Maintenance, More Clarity

• A single reference spec (ISO/IEC 26131–26139)

• No more guessing which draft your vendor supports

• Cleaner upgrades to FAPI, eKYC, and MCP integrations

Steps to Adopt ISO OIDC

1. Audit Current Implementations: Identify all OIDC flows, libraries, and vendors in use.

2. Map to ISO/IEC 26131–26139: Compare existing implementations against the ISO standard to identify gaps.

3. Update Configurations: Work with vendors to ensure they support the ISO version. Update your identity provider settings accordingly.

4. Train Teams: Educate engineering, security, and compliance teams on the changes and benefits of ISO OIDC.

FAQs

Q1: What does OIDC becoming ISO mean for businesses? It means organizations can now rely on an internationally recognized, audit-ready identity standard — reducing compliance risk and unlocking new regulated markets.

Q2: How does OIDC ISO help AI agents? It ensures AI agents can authenticate securely and interoperably across systems, forming the trust layer for MCP-driven ecosystems.

Q3: How is ISO OIDC different from earlier OIDC specs? ISO versions consolidate all errata and clarifications, providing a single, globally trusted reference point.

Q4: Why should enterprises act now? Adopting ISO OIDC now reduces identity technical debt, lowers compliance costs, and positions enterprises ahead of future regulations.

Conclusion: A Clean Ledger for the Future of Identity

OIDC becoming ISO is not just a standards milestone. It’s a technical debt repayment plan for digital identity — giving businesses a chance to reset, unify, and secure their ecosystems. And as AI agents and MCP become central to enterprise workflows, ISO OIDC is the trust anchor they’ll rely on.

For executives, PMs, and engineers alike, this is a rare chance to pay off accumulated debt and position identity as a growth enabler. Because in the era of agentification, trust isn’t optional — it’s the foundation.

Pro Tip: If you’re building agent ecosystems or planning MCP integrations, bake ISO OIDC compliance into your roadmap now. Think of it as paying off debt today to avoid bankruptcy tomorrow.

Go Rebels! ✊🏽

Learn more about the new OIDC

• 10 Years On: OpenID Connect Published as an ISO/IEC Spec

• OpenID Connect specifications published as ISO standards

• OpenID Connect for Identity Assurance 1.0

• How many applications can you think of that use OAuth for authentication and authorization?

• How many applications had you actually approved with your social login!?

But OAuth itself has evolved. As the AI ecosystem grows, we're witnessing a new level of demand for Dynamic Client Registration (DCR) — the ability for clients to register with an authorization server on the fly.

This post is your guide:

• How OAuth has changed (and why it matters).

• Why Dynamic Client Registration is a cornerstone for multi-tenant and AI-driven systems.

• How the Model Context Protocol (MCP) is adopting these patterns.

• And a practical step-by-step with Authentik and the HAPI MCP Server to ground it all.

1. OAuth's Evolution: From Delegation to Identity to Best Practice

Let's start simple.

• OAuth 2.0 (2012): The original delegation protocol. It let apps request access to resources on your behalf (e.g., a calendar app accessing your Google Calendar). But it was flexible — sometimes too flexible. Some flows turned out to be insecure.

• OpenID Connect (2014): A layer on top of OAuth 2.0. It added an ID token so apps could also know who you are — not just access your data. Think of it as turning OAuth into both an access key and a passport.

• OAuth 2.1 (draft, 2020+): A cleanup spec. It didn't reinvent the wheel — it just enforced best practices learned over a decade:

  • No more Implicit or Password flows.

  • PKCE everywhere.

  • Refresh token rotation.

  • TLS mandatory.

  • Discovery & registration treated as first-class citizens.

👉 In short: OAuth matured from a flexible toolkit to a secure, standardized foundation.

2. Why Dynamic Client Registration Matters Now

Static client registration works fine if you're only registering a handful of apps. But what if:

• You're running a multi-tenant SaaS platform with thousands of customers, each needing isolated integrations?

• You're building AI agent ecosystems, where agents spawn dynamically and need credentials to access APIs in real time?

  • With MCP, these agents can self-register and obtain the necessary credentials without manual intervention.

That's where Dynamic Client Registration (RFC 7591) comes in:

• Clients can register programmatically with an Authorization Server.

• They receive credentials (client ID, secrets, etc.) automatically.

• They can operate without human intervention.

This matters because:

• Cost savings: No manual provisioning overhead.

• Scalability: Hundreds or thousands of clients → no problem.

• Security: Credentials are issued and rotated via defined policies.

Without DCR, scaling modern environments is like trying to hand out car keys at a concert — messy, error-prone, and slow.

3. MCP and Dynamic Registration: A Perfect Fit

Fast forward to today's AI-driven world. Enter the Model Context Protocol (MCP) — an emerging specification defining how AI systems interact securely and consistently with external tools, APIs, and resources.

From the MCP specification (June 2025 release):

"Dynamic Client Registration enables MCP clients to register securely with authorization servers, supporting environments with high client churn such as multi-agent systems."

What this means in plain language:

• AI agents (think assistants, copilots, bots) can self-register with a system.

• No admin has to pre-configure each one.

• The authorization flow is standardized, portable, and safe.

MCP leverages the OAuth ecosystem — discovery, PKCE, and DCR — to make this seamless.

This is big. Imagine AI agents spinning up per request, each one negotiating its credentials securely without any human intervention. That's the kind of automation we're heading toward.

4. Example: Authentik + HAPI MCP Server

Enough theory — let's make it real.

Imagine you're deploying Authentik (an open-source Identity Provider) as your authorization server, and you want your AI agents running in the HAPI MCP Server (hapi.mcp.com.ai) to register dynamically.

Here's the simplified step-by-step flow; for more details, refer to the MCP specification.

sequenceDiagram
    participant Client as MCP Client (Agent)
    participant Auth as Authentik (Auth Server)
    participant Server as HAPI MCP Server

    rect Purple
      critical ​Authorization Server Discovery
        Client-->Server: Tell me where
      end
    end

    critical ​Dynamic Client Registration
      rect rgb(17,147,176)
        Client->>Auth: POST /register -> client_id, secret
        Auth->>Client: Client Credentials
      end
      critical User Authorizes
        rect rgb(218,119,86)
              Client-->Auth: Auth Request (PKCE)<br>Token exchange
        end
      end
    end

    rect green
      critical Ready<br>(new agent linked/<br>ready to call APIs)
        Client->>Server: Request with token      
        Server->>Client: Response
      end
    end

Step 1. Discovery

• The MCP client queries something without a token,

• The MCP Server responds with the discovery endpoint:

https://<authentik-domain>/.well-known/openid-configuration

"I can't grant you access without a token. Check with Auth Server for details."

• From here, it learns where to send authorization and registration requests.

Step 2. Dynamic Client Registration

• The MCP client calls Authentik's registration endpoint (from discovery metadata):

POST /application/o/token/
Content-Type: application/json
{
  "client_name": "hapi-agent-123",
  "redirect_uris": ["https://hapi.mcp.com.ai/callback"],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

• Authentik returns:

{
  "client_id": "abc123",
  "client_secret": "xyz789",    // <-- optional, two client types
  "registration_access_token": "rat_456"
}

OAuth 2.1 defines two client types based on their ability to authenticate securely with the authorization server:

• "confidential": Clients that have credentials with the Authorization Server (AS) are designated as "confidential clients"

• "public": Clients without credentials are referred to as "public clients." Public clients are incapable of maintaining confidentiality and should utilize methods like PKCE.

Step 3. Authorization Code + PKCE Flow

• The MCP client (HAPI agent) initiates an auth request:

GET /application/o/authorize?
    response_type=code
    &client_id=abc123
    &redirect_uri=https://client.mcp.com.ai/callback
    &scope=openid profile
    &code_challenge=... 
    &code_challenge_method=S256

• Authentik handles user consent, then redirects back to HAPI MCP Client with an authorization code.

Step 4. Token Exchange

• The HAPI MCP Client exchanges the code (with PKCE verifier) at Authentik's token endpoint:

POST /application/o/token/
grant_type=authorization_code
code=...
client_id=abc123
code_verifier=...

• Authentik issues access + refresh tokens.

Step 5. Agent Ready

• Now the HAPI MCP agent can call APIs securely, and if refresh tokens rotate, it seamlessly handles renewal.

5. Why This Matters

By combining OAuth 2.1 best practices, Dynamic Client Registration, and the MCP standard, you get:

• Seamless scaling of clients/agents.

• Zero manual overhead for new tenants or AI workloads.

• Security baked in with PKCE, HTTPS, and rotation.

• Interoperability — the same flows work across Authentik, Keycloak, Azure AD, and beyond.

This isn't just theory. It's the backbone for the next generation of AI-native infrastructure.

Final Thought

OAuth originated as a method for logging in with your Google account. Today, it's the glue that lets AI agents, SaaS platforms, and enterprises interact safely and automatically. OpenID Connect (OIDC) becoming an ISO standard matters now more than ever.

And if you're ready to experiment:

👉 Try spinning up an agent with the HAPI MCP Server and plug it into Authentik. You'll see just how powerful Dynamic Client Registration is when theory meets practice.

The magic of HAPI Server is that it simplifies the implementation of OAuth 2.1 flows out of the box, using just the Swagger Specs and zero coding, making it easier for developers to build secure and scalable applications. PMs can spin up new agents in minutes, not weeks.

Go Rebels! ✊🏽

👉 How many tools should an agent actually have access to?

It sounds simple: connect your agent to a bunch of MCP servers, aggregate the tools, and let the model decide. But in practice, that "let's give it everything" approach is a recipe for confusion, higher latency, and even session corruption.

Let's break it down.

The Hidden Risk: Tool Overload

Think about it like this:

• If you give a chef one pot, they'll probably make a meal just fine.

• If you give them a hundred different pots, each slightly different, the kitchen slows down. They spend more time choosing than cooking.

The same thing happens with agents. Presenting too many tools to the model increases "decision friction" and makes it more likely that the wrong one gets called.

The result?

• Wasted tokens on irrelevant tool calls.

• Incorrect responses that break user trust.

• Sessions that derail because of "tool confusion."

I have been in situations where my local Ollama either times out or gets confused by the number of tools available. This has led to suboptimal performance and frustrating user experiences.

Guardrails for Agent Tools

Managing an agent's toolset is as important as managing its memory or context window. Without the right guardrails, even the most powerful model can collapse under its own options.

There are three main approaches teams are trying today:

1. Manual Coding (Static Guardrails)

You hardcode the tool list in the agent logic. Simple, predictable, but rigid. If you need to add or swap tools, you will be shipping code changes.

Good for: Proof-of-concept agents. Bad for: Anything you want to scale.

2. Specialized Agents (Semi-Automatic)

Instead of one agent with 50 tools, you spin up multiple agents with smaller, curated toolsets. Each agent is specialized in a specific domain—think "Customer Support Agent" VS "Analytics Agent."

This gives you flexibility, but you now have agent sprawl—managing dozens of specialized agents becomes its own problem.

A variation on this is to use tool categories—grouping similar tools together and allowing the agent to choose from a category rather than a long list. This can reduce decision fatigue while still providing flexibility. You get an agent with a more focused toolset, tailored to specific tasks.

3. Dynamic Tool Selection (Runtime Guardrails)

Here's where things get interesting. Instead of hardcoding or duplicating, you let the agent query for the tools it needs at runtime.

For example, with ChatMCP, the agents are defined by their context with filtered tools. Based on the conversation, the model is dynamically fed with only the relevant tools that meet the conversation's semantic needs. This keeps the toolset lean, relevant, and avoids overwhelming the LLM.

Beyond Guardrails: Multi-Headed Specialization

What if one server could serve multiple toolsets, on demand?

That's where solutions like a HAPI Server in "hydra mode" come in—letting you define an MCP Server with multiple "heads" (each head being an API server). Instead of juggling dozens of servers, you present a single entry point that flexibly exposes the right tools at the right time.

This keeps your architecture clean while still giving your agents flexibility.

Dynamic tool selection or specialized agents is the best approach for most use cases. Whatever strategy you choose, the key is to keep the toolset relevant and manageable.

Why This Matters

The number of tools you give your agent directly impacts:

• Performance (more tools = slower calls).

• Reliability (fewer mistakes if tool choice is clear).

• Cost (fewer wasted tokens on irrelevant tool calls).

Getting this wrong isn't just a technical detail—it's a business problem. If your agent burns through context windows or calls the wrong APIs, you're losing both time and money.

Closing Thought

Building more intelligent agents isn't about giving them all the tools; it's about giving them the right tools at the right time.

The future of agent design lies in dynamic guardrails—systems that adapt toolsets to context, not static lists that overwhelm the model.

If you're exploring MCP-based architectures and want to see what runtime guardrails look like in practice, check out the HAPI Stack. With features like hydra-mode, it makes managing agent tools simpler, faster, and more scalable.

👉 Question for you: How are you managing the tool list for your agents today—manual, specialized, or dynamic?

Please let me know in the comments or reach out to me directly. Always happy to chat about building better AI systems!

Go Rebels! ✊🏽

When I first discovered MCP in late November 2024, I was immediately intrigued by its potential. It seemed like the missing piece in how we communicate with systems using natural language—a problem I was already trying to tackle with my CLI tools gyat and hapi. I created a blog to help others understand these tools and make API interactions more human-friendly. However, these tools worked algorithmically with deterministic workflows; they couldn't systematically interact with AI models.

Anthropic's MCP caught my attention because it appeared to offer a solution—a way to standardize natural language communication with systems, benefiting both developers and users. Initially, I saw MCP as a protocol that could bridge the gap between human language and machine comprehension.

My Journey with MCP

I immediately began experimenting with MCP, integrating it into my tools and workflows. The simplicity of adding tools to Claude's desktop interface was compelling—it felt like a natural evolution beyond traditional APIs and protocols.

However, there was a catch. The initial learning curve was steep, and troubleshooting was a challenging task. I wanted to help others facing similar struggles by making MCP more accessible without requiring deep technical understanding.

Through writing about my experiences and sharing practical tips, my understanding evolved in tandem with the specifications. A pivotal moment came when MCP introduced Streamable HTTP (Protocol Revision: 2025-03-26) as a transport method. This shift helped me realize that MCP isn't purely a protocol—it's fundamentally a contract that emphasizes interaction semantics rather than just data transfer mechanics.

This revelation clarified how MCP could function at a higher level. Since my gyat and hapi CLI tools were designed to be API-first, and MCP fits seamlessly into that approach—not just defining how systems communicate, but how they should behave.

The LSP Connection: Understanding MCP's Roots

To understand what MCP truly is, let's examine its foundation. Do you recognize this JSON structure?

Content-Length: ...\r\n
\r\n
{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "textDocument/completion",
    "params": {
        ...
    }
}

What about these TypeScript interfaces?

interface RequestMessage extends Message {
    /**
     * The request id.
     */
    id: integer | string;

    /**
     * The method to be invoked.
     */
    method: string;

    /**
     * The method's params.
     */
    params?: array | object;
}

interface ResponseMessage extends Message {
    /**
     * The request id.
     */
    id: integer | string | null;

    /**
     * The result of a request. This member is REQUIRED on success.
     * This member MUST NOT exist if there was an error invoking the method.
     */
    result?: LSPAny;

    /**
     * The error object in case a request fails.
     */
    error?: ResponseError;
}

No, it is not MCP. This is the Language Server Protocol (LSP)—a protocol that standardizes how development tools communicate with programming language servers. LSP enables editors and IDEs to provide features such as code completion, linting, and refactoring across different languages without implementing language-specific logic in each tool.

The lifecycle message flows of LSP and MCP are strikingly similar:

sequenceDiagram
  participant Client
  participant Server

  Client->>Server: Initialize
  Server->>Client: Initialized
  Client->>Server: Register Capability
  Client->>Server: Unregister Capability
  Client->>Server: Set Trace
  Client->>Server: Log Trace
  Client->>Server: Shutdown
  Client->>Server: Exit

Why LSP Matters for Understanding MCP?

LSP revolutionized software development by solving a critical integration problem. Before LSP, supporting code intelligence across multiple programming languages meant writing M × N integrations—M tools for N editors. Each language had its peculiarities, and each editor had its API, resulting in expensive, fragile, and inefficient custom integrations.

LSP introduced a universal interface for language servers. Instead of each editor implementing custom logic for every language, they could all speak the same protocol. Once a language server was built, any LSP-compliant editor could use it.

Sound familiar? This is precisely what MCP aims to achieve for AI model interactions. Once an API implements an MCP Server, any compliant client can interact with it without needing custom logic for each client.

The Strategic Launch: Lucky or Smart?

Timeline:

• MCP SDK made public on GitHub: October 23rd, 2024

• Claude desktop released: October 31st, 2024

The buzz around MCP is largely thanks to Claude desktop—the first MCP client. Anthropic made a brilliant move by recognizing LSP's potential and applying similar principles to AI model interactions.

Despite the controversial choice of using stdio as the initial transport layer, it was strategically sound, providing a lightweight and efficient communication method that made it easier for developers to build AI-powered tools locally.

Why not use HTTP? HTTP is a heavyweight protocol with built-in features that aren't always necessary for simple interactions. stdio is simpler, faster, and more direct—ideal for local applications where both client and server are on the same machine, which was the case for Claude desktop and the initial MCP implementations.

Understanding STDIO

STDIO (Standard Input/Output) is defined by the C runtime and inherited by UNIX-like systems, consisting of three standard file descriptors:

• stdin (0): input stream

• stdout (1): output stream

• stderr (2): error stream

These are simply file streams, often attached to terminals, pipes, or redirected. STDIO serves as the transport layer for higher-level protocols.

Analogy: If HTTP is like postal mail, STDIO is like hand-delivering messages through a tube—simpler, faster, and ideal when sender and receiver are in close proximity.

The community's push toward HTTP as a transport layer makes sense—it's familiar, widely supported, and includes built-in features like headers, status codes, and content negotiation. For me, the introduction of Streamable HTTP transport in version 2025-03-26 was transformative, making MCP more accessible and easier to integrate into existing systems.

MCP as Contract, Not Protocol

This brings us to the core insight: MCP is not just another protocol; it's a semantic layer that enables intelligent API interactions. It allows agents to understand not only the data, but also the intent and context behind it.

Consider this question: Where do tools like Swagger/OpenAPI Specification (OAS) fit into networking architectures such as the OSI model?

They don't fit neatly, and that's perfectly fine. Swagger/OAS isn't a protocol in the traditional sense—it's a contract that defines how systems should interact.

Why Swagger/OAS Doesn't Fit the OSI Model

The OSI model describes how data is transmitted across networks—from physical wire (Layer 1) to applications (Layer 7).

Swagger/OAS, by contrast:

• Doesn't handle transport (Layer 4)

• Doesn't define sessions (Layer 5)

• Isn't concerned with encoding (Layer 6)

• It isn’t a runtime application (Layer 7)

Instead, it:

• Describes APIs—endpoints, parameters, responses, and authentication

• Acts as metadata for client-service interactions over HTTP

This is meta-communication—a contract, not transmission itself.

The "Layer 8" Concept

I would place Swagger in Layer 8: "People, Policies, and Planning"—where developers, product managers, and architects live. It's about human agreement, specification, and negotiation of service interfaces.

Analogy: If the OSI model is a road system:

• Layers 1–4 are asphalt, traffic rules, intersections, and cars.

• Layers 5–7 are comprised of drivers, GPS, and mobile apps, which send and receive instructions.

• Swagger/OAS is the roadmap and city planning documentation telling drivers and managers how roads should be used.

MCP Operates in the Intent Layer

In intent-based systems (like MCP or autonomous agents), specifications like Swagger or gRPC play crucial roles:

• Declaring intent

• Providing machine-readable contracts

• Powering automation, code generation, testing, and governance

In modern cloud-native and AI-centric architectures, these tools reside in the intent/control plane—often referred to as Layer 8+ or "Layer 9: Governance/Compliance."

Summary: Contract vs. Protocol

Key Insight: Swagger/OAS is what developers and machines use to agree on how to communicate, but it doesn't do the communicating itself.

Similarly, MCP lives in "Layer 8"—the realm of contracts, conventions, and collaboration. It's not a limitation; it's evolution from "transporting data" to "understanding and automating intent."

Why This Matters: MCP's Real Value

Anthropic's genius was leveraging this intent-layer understanding to create a more intuitive interface for AI model interactions. MCP wasn't just another specification—it was a way to make AI more accessible and practical.

The introduction of Streamable HTTP transport was my AHA moment, making integration with existing systems seamless. When I finally understood MCP as a contract rather than a protocol, everything fell into place.

Looking Forward: MCP in Enterprise

In regulated industries—such as banking, healthcare, and defense—contracts are paramount. MCP's explicit semantic layer maps directly to compliance requirements:

• Audit Trails: Each message logged with context keys

• Policy Enforcement: Only approved message types pass through

• Version Control: Upgrade contracts without breaking consumers

With modern deployment stacks, you can deploy MCP servers using GitOps, ensuring every revision is tracked, tested, and approved.

Conclusion

What began as curiosity about a new protocol evolved into a deeper understanding of how AI systems can better serve human needs. MCP isn't just about data exchange—it's about creating meaningful, contextual interactions between humans and AI.

By recognizing MCP as a contract that operates in the intent layer, we can build more reliable, maintainable, and robust AI integrations. It's not about the transport mechanism; it's about the semantic agreement that enables intelligent automation.

I have been working with the HAPI Stack for MCP, which aims to provide a comprehensive framework for building and deploying API-first MCP-based applications. It simplifies the integration and deployment of MCP-based applications, allowing developers to focus on creating intelligent systems without getting bogged down in low-level details.

Please review the HAPI Stack documentation to learn how it can help you build robust, intent-driven applications using MCP.

Further Reading

• LSP Specification

• Language Server Protocol

• Model Context Protocol (MCP)

• MCP as Contracts documentation

This post was brought to you by someone who once thought MCP was just another protocol—and is now convinced it's a contract that unlocks smarter, more reliable AI integrations.

Go Rebels! ✊🏽

Many developers initially assume that "MCP server" means writing new adapter code, but that's a misconception. Just as in OpenAPI a servers section is metadata (not code), in MCP the "server" entry in the spec merely points to the implementation. You don't need to hand-code a new server to satisfy the MCP spec – you only need to expose the contract, use Swagger specs to auto-generate your MCP tools. Existing RESTful APIs (with their OpenAPI/Swagger definitions) can become MCP servers on the fly by generating the MCP contract from the API spec. In practice, each REST endpoint or operation object turns into an MCP tool whose name matches the API's operationId (or path and method).

Consider a simple example. An OpenAPI (OAS) snippet might define a /users endpoint like this:

openapi: "3.0.0"
paths:
  /users:
    get:
      operationId: getUsers
      description: Retrieve a list of users.
      parameters:
        - name: limit
          in: query
          schema:
            type: integer
            default: 10

In MCP terms, this becomes a tool named getUsers with a JSON schema for its input. For instance, the equivalent MCP contract might include:

{
  "tools": [
    {
      "name": "getUsers",
      "description": "Retrieve a list of users",
      "inputSchema": {
        "type": "object",
        "properties": {
          "limit": { "type": "integer", "default": 10 }
        }
      }
    }
  ]
}

Here, getUsers (the REST operationId) is exposed as a tool name, and its query parameter limit is captured in the inputSchema (see MCP's tool definition structure). This mirrors how mcp-openapi-proxy or similar tools work: in "low-level mode" they automatically register every API endpoint as an MCP tool (e.g. mapping /chat/completions to a chat_completions() tool).

Key Misconceptions in the MCP Ecosystem

There are a few common myths about MCP that our approach clarifies:

• "You must implement an MCP server from scratch."*Reality: Any existing API can act as an MCP server contractually. You can auto-generate the MCP spec from the API's OpenAPI definition, then let the client or model call the REST endpoints directly (typically via an API gateway). In other words, you're just publishing the contract. As one expert noted, "you don't need to code MCP servers at all – any RESTful API can function as an MCP server". This is akin to Swagger: you don't write code for the "server" entry, you implement the API and reference it in the spec. Go one step further: if you have an OpenAPI spec, *your existing API becomes an MCP server on the fly. Keep reading, below we show how to do this with some magic tools.

• "MCP tools are different from API operations."*Reality: In our view, the MCP "tools" *are the API operations. In fact, the REST operationId can become the tool name. Each tool has a unique name and JSON schema for its inputs. For example, an OpenAPI path with operationId: getUsers simply yields an MCP tool named getUsers. This naming correspondence means your LLM sees familiar operations: calling a tool is just like calling the original API, but through the standardized protocol.

• "MCP adds overhead or new dependencies."*Reality: By deriving the MCP spec from existing API docs, you avoid rewriting code. Many teams in the industry are already doing this. For example, tools like [*HAPI server](https://youtu.be/RGgFJcZ_PA4) dynamically turn all endpoints in an OpenAPI spec into MCP tools. This ensures that as long as your API is documented, your MCP interface is up-to-date. You're reusing your API's security, logic, and data – not replicating it (complementing maintenance). The MCP protocol itself is a thin JSON-RPC layer, so implementation can be as lightweight as a small gateway process.

OpenAPI vs MCP: Two Faces of Integration

OpenAPI and MCP serve complementary roles. OpenAPI (OAS) has long been the de facto contract for RESTful services: it tells machines which endpoints exist and how to call them. MCP is the analogous layer for AI agents: it tells models which tools they can invoke and what arguments to pass. One observer nicely summarized this: "OpenAPI describes how machines talk to machines. MCP defines how models talk to applications".

In practice, you use both: a conventional client (or agent) can call an API with REST as usual, and an LLM-based agent can call an MCP "tool" – but under the hood it's the same endpoint. An MCP-enabled architecture might look like this: your host application (e.g. a chat UI) connects to one or more MCP servers (each backed by APIs), as shown by Edwin Lisowski's diagram. The host sends the user's query along with the list of available tools to the LLM. The model then decides which tool to use, and the host invokes that tool (via the standard REST call or via an MCP gateway). The result returns through MCP and then to the user.

This two-way flow ("host ⇄ server via MCP") is flexible: some servers might access local data, others remote services. Crucially, any API (local or cloud) can be plugged in. The protocol standardizes discovery and invocation: clients send tools/list to discover tools, then tools/call with a name and arguments to execute it. As Anthropic explains, the architecture is straightforward: developers "expose their data through MCP servers or build AI applications (MCP clients) that connect to these servers.".

Tools-First, Not Server-First

Our approach is "tools-first": we focus on providing LLMs with contractual access to backend tools, rather than building a brand-new server implementation for each. Concretely, this means:

• Generate the MCP spec from your existing API (OpenAPI). Tools like our HAPI server (Headless API) can read the OpenAPI file and emit the MCP tools schema. No new business logic is written; we simply wrap the contract. This lets the agent know, for example, that "getUsers" exists and takes an integer limit.

• Use an MCP gateway (runMCP) to manage connections. This component handles the JSON-RPC transport (stdio or HTTP) and routes calls to the real API endpoints. It also aggregates multiple tools into one logical "server" if needed.

• Invoke tools from the MCP client (chatMCP). The LLM sees a unified list of tools. When it decides to call one, the MCP client issues a tools/call request, which the gateway translates into the actual API call. The response is sent back to the LLM in structured JSON format. In practice, this is exactly what many products do: for instance, Claude Desktop, Cursor, or Cobie all connect via stdio to MCP servers that wrap REST APIs.

By contrast, the "MCP hype" often suggests building a separate software server for each data source. We challenge that: you already have servers! For example, if you have an OData or REST API for your database, that can be the MCP server. You only need to publish its OpenAPI spec so agents know how to talk to it. In short:

• If you can call the API now, you can call it via MCP.

• Each API operation is simply a tool in the MCP world.

• No new code (beyond the gateway glue) is needed to implement the business logic.

This cuts development effort dramatically. As one architect put it, MCP gives AI models a shared language for your stack. The MCP spec is generated "on the fly" from what the server already exposes – so maintaining your APIs automatically maintains your AI contract.

Example Conversion: OpenAPI → MCP

To make this concrete, imagine a typical user service with an OpenAPI spec (a small excerpt is shown above). In the OAS we have:

• GET /users?limit=10 with operationId: getUsers

• POST /users with operationId: createUser

• GET /users/{id} with operationId: getUserById

• etc.

When we run HAPI (or another OAS-to-MCP tool), it might produce an MCP contract listing tools like:

{
  "tools": [
    {
      "name": "getUsers",
      "description": "Returns a list of users",
      "inputSchema": {
        "type": "object",
        "properties": {
          "limit": { "type": "integer", "default": 10 }
        }
      }
    },
    {
      "name": "createUser",
      "description": "Create a new user",
      "inputSchema": {
        "type": "object",
        "properties": {
          "body": { 
            "type": "object",
            "properties": {
              "name": { "type": "string" },
              "email": { "type": "string", "format": "email" }
            },
            "required": ["name", "email"]
          }
        }
      }
    },
    {
      "name": "getUserById",
      "description": "Returns a user by ID",
      "inputSchema": {
        "type": "object",
        "properties": {
          "id": { "type": "string" }
        }
      }
    }
    // ... additional tools from other endpoints ...
  ]
}

This closely follows the official MCP tool definition structure. The name field is the unique tool name (we use the OpenAPI operationId), and inputSchema is a JSON Schema object for the tool's parameters. The description helps the LLM understand its purpose. The MCP server (gateway) would advertise these tools via tools/list, and the LLM can pick one by name. Then the gateway performs the underlying REST call, sends the response back as MCP content, and the model incorporates it.

By keeping the tool definitions in sync with the OpenAPI, teams ensure that every change to the API automatically updates the MCP interface. In our experience, architects are often pleasantly surprised at how minimal the extra work is: it's essentially just publishing the API spec over a standard channel. Many open-source proxies (like mcp-openapi-proxy) operate this way out of the box.

📊 OAS vs. MCP – Contract-Level Feature Comparison

Here's a side-by-side comparison table showing the similarities between OpenAPI Specification (OAS) and Model Context Protocol (MCP). This focuses on their structural parallels, especially in how OAS defines contracts vs. how MCP defines intents, tools, and context, helping technical product managers and architects bridge the conceptual gap:

🔍 Interpretation

• OAS is to APIs what MCP is to Agents — both define contracts, but for different execution contexts.

• operationId ≈ tool.name – this is the most precise analog between the two: both uniquely identify callable logic units.

• Request/response schemas are equally critical in both — they define the expected structure, enabling validation and introspection.

• Security and extensibility are evolving in MCP, much like OAS has matured over time.

• UI tooling, such as Swagger UI, is analogous to chatMCP that in MCP, providing a user-friendly interface for interacting with the defined contracts.

• Versioning and extensibility are handled similarly, allowing both OAS and MCP to evolve without breaking existing contracts.

• Primary use cases differ: OAS focuses on API design and documentation, while MCP enables AI agents to interact with tools and data sources.

• Tools ecosystem is growing for MCP, similar to how OAS has a rich set of generators and clients.

• Source of truth for both is the contract file itself, whether it's an OpenAPI spec or an MCP JSON file.

• Both OAS and MCP are about contracts, not implementations – they define how to interact with services, not how those services are built.

Benefits and Metrics of a Contract-First MCP Approach

This tools-first strategy yields measurable benefits for technical teams. Here are some key metrics (KPIs) that improve under this approach:

• Integration Speed: Onboarding a new data source is much faster. Instead of weeks of adapter coding, you generate the MCP contract from the existing API in minutes.

• Developer Productivity: Engineers spend less time writing boilerplate. The MCP gateway handles the JSON-RPC plumbing. Developers can focus on adding real value to the API itself.

• Reuse and Consistency: By leveraging the OpenAPI spec, you ensure one source of truth. There's no risk of the MCP interface drifting from the actual API. Consistency can be measured by coverage: e.g., what percentage of endpoints are exposed as tools.

• Scalability: As your API surface grows, the tooling scales automatically. More endpoints automatically become available tools without additional coding. A possible KPI is the number of integrated tools per quarter, which should climb rapidly.

• Maintainability: Fewer moving parts (no custom MCP servers) means easier upkeep. An MCP contract auto-generated from OAS reduces maintenance cost. One could track time spent on MCP-related bugs dropping.

• Security and Governance: Standard contracts enable uniform policies. For example, you can apply the same authentication rules across all tools. Metrics here include compliance checks passed or auditable traceability of tool calls.

• User Adoption: Finally, from the product perspective, a consistent protocol can drive usage. One could survey developers or product managers for satisfaction – an important KPI in itself – or measure number of agent use-cases enabled.

All these KPIs are founded on sound principles. For instance, using the well-known OpenAPI spec leverages existing developer skills, reducing training time. Relying on a standardized JSON-RPC protocol means better compatibility between different LLM platforms. In aggregate, we expect metrics like "time to market" and "number of connected services" to improve when the team adopts this contract-first MCP approach.

Introducing the Happy MCP Stack

To put these ideas into practice, we've built a small MCP "stack":

• HAPI Server (Headless API and MCP Gateway): A CLI tool that reads an OpenAPI spec and instantly serves an MCP contract. Think of it as "Swagger + MCP" without writing code. Under the hood HAPI generates the tools definitions from your paths/operationIds and launches a JSON-RPC endpoint. This way you can make any REST service MCP-ready on the fly.

• runMCP (MCP Control Plane): This component manages multiple MCP server instances. It acts like your control plane: you configure which HAPI instances (i.e. which specs) to run, and runMCP ensures they're reachable by the agent. It handles routing calls from the LLM to the right MCP server and can also aggregate tools across servers. It's our answer to "How do I host and scale MCP servers?" without heavy infrastructure changes.

• chatMCP (MCP Client Agent): This is a user-friendly client for interacting with the MCP tools from a conversation or automation. Imagine a WhatsApp-like interface between you and an AI agent: chatMCP lets a human ask the AI for something, the AI uses the MCP tools behind the scenes, and the result flows back in chat. It leverages the standard MCP client libraries to manage the request/response loop. In demos we show how an agent can "chat" with these MCP tools as if they were part of its own language.

Together, this stack embodies our "contract-first" philosophy. You don't code custom servers; you just plug existing APIs into MCP via HAPI Servers, orchestrate with runMCP, and interact with chatMCP.

The Path Forward

MCP is indeed poised to be a new standard in AI integration, but we emphasize simplicity over hype. The core insight is this: if your API is RESTful and documented, it can be an MCP service. You only need to publish the contract. In other words, we are not creating a new backend; we are exposing the existing one. This shifts the focus from "building servers" to "publishing tools".

For architects and product managers, that means reusing what you have: existing microservices, databases, and SaaS APIs become immediately LLM-ready. The only code you write is for joining pieces (the gateway), not for implementing domain logic twice. This reduces cost and risk while opening up your tools to powerful AI agents.

As MCP matures, we'll see even more marketplaces and integrations (Anthropic's ecosystem, Community repos, etc.). Our hope is that by clarifying these misconceptions – and measuring impact with solid KPIs – teams will adopt the simplest successful strategy: tools already exist; just give models the contract.

In summary, MCP is a contract standard, not another platform framework. Think of it as a language for agents, built on familiar foundations (OpenAPI, JSON, HTTP). By focusing on the contract, we demystify MCP, avoid reinventing servers, and speed up AI integration. As one developer put it: MCP simply "replaces one-off hacks with a unified, real-time protocol". That's a future where AI agents can do work with the tools we already have – and we believe that's exactly what technical architects and product managers need.

Curious about how to get started? Check out our Happy MCP Stack documentation for a quick guide on turning your OpenAPI specs into MCP tools. Or, if you want to see it in action, try our chatMCP and runMCP or watch our demo videos to see how easy it is to integrate AI agents with existing APIs using MCP. You can also join our community on Discord to experience the power of AI agents using MCP tools directly.

Drop us a line if you have questions or want to collaborate on MCP projects. We're excited to see how the community will leverage this protocol to build innovative AI applications.

Let's build the future of AI integration together! Go Rebels! ✊🏽

Additional Resources

• Model Context Protocol (MCP) Official Site

• HAPI Server GitHub Repository

• runMCP GitHub Repository

• chatMCP GitHub Repository

• Happy MCP Stack Documentation

• MCP Quickstart Guide

• HAPI Server Demo Video

• MCP Community Forum

Many developers, at least at first glance, think that MCP is overrated and just another way to refer to APIs. That’s partially correct, but it is much more than that. It standardizes how LLMs communicate with applications; it is the "Natural Language" of models and makes them more accessible to developers.

That's precisely why I want to discuss it. MCP is a protocol that allows developers to integrate AI models into their applications in a standardized way, making it easier to build and maintain AI-powered applications. It provides a common language for models to communicate with applications, enabling developers to focus on building features instead of worrying about the underlying model implementation.

Swagger, or OpenAPI Specifications, is familiar to most people. The OpenAPI and MCP specifications are two sides of the same coin. Both define how APIs should be designed and documented, but serve different purposes. OpenAPI focuses on RESTful APIs, while MCP centers around LLMs integration.

I have implemented a holistic solution called hapi (headless API) to facilitate the implementation of both OpenAPI and MCP specifications. Let me show you how to use it with a practical example.

My VM instances run on Contabo (affiliate link), a VPS provider. Using the hapi CLI tool, I will demonstrate how to integrate MCP without writing a single line of code.

First, download or save your OpenAPI specification file. In this example, it's contabo.json, which describes the API of the Contabo VPS provider. You can find it in the Contabo API documentation.

The file must be saved in the $APICOVE_HOME/specs, which by default is the user's home directory: ~/.apicove/specs/contabo.json, or in your current working directory (where you run the hapi command). With the list argument, the tool shows the available specifications using the hapi CLI tool:

$ hapi list
List of APIs
- petstore
- contabo
- oci-registry
- agentico
- petstore-oasv2

In a Greenfield project, you can create a new project using the hapi init command:

$ hapi init contabo

This command will use the Swagger specification file contabo.json (or contabo.yaml) to generate the controller’s scaffolding and save the file in the $APICOVE_HOME/src/contabo directory.

There are two ways to run the hapi command: using the "headless mode" or the "MCP mode."

In the "MCP mode", you can run the command as follows:

$ hapi run contabo --mcp

This command prints some API stats, like the number of endpoints and models. Then, it starts a web server with the entire MCP implementation, including the OpenAPI specification, the MCP specification, and the controllers scaffolding. If you test the endpoints using a tool like Postman or the built-in Swagger UI, you will see that the endpoints are already implemented and ready to use, without any business logic yet. You can then implement the business logic in the controllers located in the $APICOVE_HOME/src/contabo directory.

The "headless mode" is intended for brownfield projects, where you already have an existing backend application and want to integrate the MCP part. The "head" part is the current backend application, and the server defined in the OpenAPI specification consumes its business logic.

In this mode, you can run the command as follows:

$ hapi run contabo --headless

This command will start a web server with the MCP implementation but will not use the controller scaffolding. Instead, it will consume the business logic using the existing backend application at https://api.contabo.com/.

In the demo video, you can see how I use the hapi CLI tool to run the MCP implementation in both modes and test the endpoints using Postman and Swagger UI. I retrieve the list of VPS instances via MCP and finally show the actual Contabo Admin Panel, where I list the same VPS instances, to prove that the MCP implementation is working correctly.

Would you like to see more examples of how to use hapi MCP? Or do you have any questions about the implementation? Let me know in the comments below!

Connect with me on Twitter or LinkedIn to stay updated on the latest developments by "La Rebelion".

Want to download the hapi CLI tool? Comment on LinkedIn or Twitter, and I will send you the link to download it.

Be “HAPI” and Go Rebels! ✊🏽

CLI Design Patterns: Action vs. Resource

Command-line interfaces (CLIs) are the backbone of DevOps workflows. However, not all CLIs are built the same. Some group commands by resource type, like Cloudify's cfy, while others, like Kubernetes' kubectl, group commands by action (or verb: get, delete).

If you are a DevOps engineer, and you are building a CLI to automate your workflows or you are a user of a CLI and you are wondering why some commands are grouped by resource type and others by action, you might be wondering:

Which approach is better? Why do some tools favor one over the other? And how does this impact usability and automation? In this post, we'll break down the differences, explore a hybrid approach, and discuss how I applied these principles in designing my CLIs for the "La Rebelion" community: gyat, hapi, and agentico.

Grouping by Resource Type (Cloudify CLI Style)

Cloudify's cfy CLI organizes commands based on what you are working with.

Example:

cfy blueprint upload my-blueprint.yaml
cfy deployment create my-deployment
cfy execution start -d my-deployment

Here, the blueprints, deployments, and executions are first-class citizens, and all related actions are nested under their resource type.

✅ Pros:

• Intuitive for users who think in terms of domain objects.

• Reduces ambiguity when working with complex resources.

• It is more straightforward to document and organize.

❌ Cons:

• It can be verbose, requiring more typing.

• Users must remember different command structures for each resource type.

• It is harder to generalize across different resource types.

Grouping by Action (Kubernetes CLI Style)

Kubernetes' kubectl CLI flips the approach—users start with what they want to do, followed by the resource type.

Example:

kubectl get pods
kubectl delete service my-service
kubectl apply -f deployment.yaml

The focus here is on the actions (get, delete, apply), which are reusable across many resource types.

✅ Pros:

• More consistent and predictable across different resource types.

• Easier for automation and scripting.

• Reduces cognitive load since users only need to remember actions, not different resource structures.

❌ Cons:

• It may feel unnatural to those used to object-oriented workflows.

• Resource types must be specified explicitly every time.

• Some commands can become longer and harder to read.

Hybrid Approach: Terraform CLI Style

Terraform uses a hybrid approach, mixing action-first and resource-first paradigms.

Example:

terraform apply
terraform state list

In the example, terraform apply is action-first, while terraform state list is more resource-focused.

This approach provides flexibility, allowing users to interact with high-level actions and granular resources. It's ideal for tools that have a mix of static and dynamic resources.

Why Choose One Approach Over the Other?

The choice between these approaches depends on your tool's use case, target audience, and design goals. Here are some factors to consider:

• Resource Nature: A resource-first approach (cfy style) is intuitive if your tool deals with well-defined domain objects. If it works with dynamic or API-driven resources, an action-first approach (kubectl style) keeps things predictable.

• User Experience: Consider how users will interact with your tool. If they think in terms of objects, a resource-first approach is better. If they think about actions, an action-first approach is more suitable.

• Automation: If your tool needs to be easily scriptable, an action-first approach (kubectl style) is more flexible.

• Complexity: A hybrid approach (terraform style) offers the best of both worlds for tools with a mix of static and dynamic resources.

Examples of CLI Design Patterns in Action

Based on their command structure, here's a classification of popular CLI tools in the Cloud (CNCF) and DevOps space.

This should give a solid overview of how different cloud and DevOps CLIs structure their commands and give you a good idea of which approach to use for your tooling.

Comparing CLI Design Patterns 🔍

Let's compare these approaches side by side:

The table above provides a quick overview of each approach's pros and cons. The best choice depends on your specific use case and user base, but understanding these trade-offs can help you make an informed decision.

The action-resource approach (kubectl style) is more complex to implement, document, and organize but more consistent and predictable across different resource types. The resource-action approach (cfy style) is more intuitive for users who think in terms of domain objects, but it can be harder to generalize across different resource types. The hybrid approach (terraform style) provides flexibility, allowing users to interact with high-level actions and granular resources.

Tree-like Representation of the Commands

Here’s a tree-like representation of the command structures for kubectl (action-first), cfy (resource-type-first), and argocd (hybrid) using a Linux command-style layout:

Action-First command structure

kubectl
├── get
│   ├── pods
│   ├── services
│   ├── deployments
│   ├── nodes
│   └── configmap
├── describe
│   ├── pod mypod
│   ├── service myservice
│   ├── deployment mydeployment
│   └── node mynode
├── apply
│   ├── -f myapp.yaml
│   ├── -f service.yaml
│   └── -f ingress.yaml
├── delete
│   ├── pod mypod
│   ├── service myservice
│   ├── deployment mydeployment
│   └── namespace mynamespace
└── logs
    ├── pod/mypod
    └── deployment/mydeployment

Resource-Type-First command structure

cfy
├── blueprint
│   ├── upload myblueprint.yaml
│   ├── delete myblueprint
│   └── list
├── deployment
│   ├── create mydeployment -b myblueprint
│   ├── delete mydeployment
│   ├── outputs mydeployment
│   └── list
├── execution
│   ├── start myworkflow -d mydeployment
│   ├── cancel myexecution
│   ├── list
│   └── resume myexecution
└── tenant
    ├── create mytenant
    ├── delete mytenant
    ├── list
    └── set-default mytenant

Hybrid Approach command structure

docker
├── # Action-First Commands (Hides Resource Type)
│   ├── run nginx
│   ├── pull nginx:latest
│   ├── push myrepo/myimage:v1
│   ├── login myregistry.com
│   ├── logout myregistry.com
│   ├── search nginx
│   ├── build -t myimage .
│   ├── tag myimage myrepo/myimage:v1
│   ├── inspect mycontainer
│   └── exec -it mycontainer bash
│
├── # Resource-First Commands (Explicit Resource Type)
│   ├── container
│   │   ├── ls
│   │   ├── start mycontainer
│   │   ├── stop mycontainer
│   │   ├── rm mycontainer
│   │   ├── inspect mycontainer
│   │   └── logs mycontainer
│   │
│   ├── image
│   │   ├── ls
│   │   ├── prune
│   │   ├── rm myimage
│   │   ├── save -o myimage.tar myimage
│   │   ├── load -i myimage.tar
│   │   └── history myimage
│   │
│   ├── network
│   │   ├── ls
│   │   ├── create mynetwork
│   │   ├── connect mynetwork mycontainer
│   │   ├── disconnect mynetwork mycontainer
│   │   └── rm mynetwork
│   │
│   ├── volume
│   │   ├── ls
│   │   ├── create myvolume
│   │   ├── rm myvolume
│   │   └── inspect myvolume
│   │
│   ├── compose
│   │   ├── up -d
│   │   ├── down
│   │   ├── logs
│   │   ├── ps
│   │   └── restart
│   │
└── # System Commands
    ├── system prune
    ├── system df
    ├── version
    └── info

Key Takeaways

• kubectl (Action-First): Commands start with verbs (get, apply, delete) and then specify the resource.

• cfy (Resource-Type-First): Commands start with the resource type (blueprint, deployment, execution), followed by actions.

• docker (Hybrid): A mix—some commands are resource-type-first (container, image, network, volume), while others follow an action-first structure (run, pull, build, tag, login).

This tree representation helps visualize how commands are structured and grouped in each CLI.

Look at the tree representation of the Action-First command structure for the kubectl command. Do you see any pattern? Yes! It is a structure with verbs as the root nodes and resources as the leaf nodes, similar to Swagger API specifications' verb-object structure.

API-First to CLI Commands Mapping

API-first design is widely used for creating CLIs, particularly for tools that interact with APIs. This approach involves directly linking CLI commands to API endpoints, facilitating the automation and scripting of workflows. Both action-first and resource-first CLIs can adapt this strategy to their command structures.

Action-First Mapping

For simplicity (because the Kubernetes and Cloudify APIs are huge), let's take the Petstore API (or Petstore v2) as an example and map it to the kubectl CLI style based on the HTTP verb-object structure of the API to the action-resource structure of the kubectl CLI, we get the following command structure:

GET     /pets
POST    /pets
GET     /pets/{petId}
PUT     /pets/{petId}
DELETE  /pets/{petId}

GET     /orders
POST    /orders
GET     /orders/{orderId}
DELETE  /orders/{orderId}

GET     /users
POST    /users
GET     /users/{username}
PUT     /users/{username}
DELETE  /users/{username}

Just replace pets with kubectl get pets or kubectl get pets 10, orders with kubectl get orders, and users with kubectl get users.

Resource-First Mapping

On the other hand, if we map the resource-action structure of the cfy CLI to the verb-object structure of Swagger API specifications, we get the following command structure:

openapi: 3.0.0
# ...
paths:
  /pets:
    get:
      # ...
    post:
      # ...
  /pets/{petId}:
    get:
      # ...
    put:
      # ...
    delete:
      # ...
  /orders:
    get:
      # ...
    post:
      # ...
  /users:
    get:
      # ...
    post:
      # ...

Just replace pets with cfy pets list, orders with cfy orders list, and users with cfy users list.

Takeaways from the Mapping

• Action-First Mapping: The HTTP verb-object structure of the API maps directly to the action-resource structure of the CLI.

• Resource-First Mapping: The paths structure of the API maps directly to the resource-action structure of the CLI.

This mapping helps visualize how API-first design can be applied to action- and resource-first CLIs.

👨🏽‍💻 How I Applied These CLI Design Patterns

When designing gyat (Go-through-your-API-tool), hapi (Headless-API), and agentico, I had to choose between the action-resource (kubectl style) and resource-action (cfy style) approaches based on the nature of the resources and the target audience. Here's how I made my decisions:

This decision aligns with how users interact with each tool. In gyat, users frequently deal with unknown APIs, so an action-first structure keeps things predictable. In agentico, users work with well-defined domain objects, making a resource-first approach more intuitive.

Final Thoughts: Choosing the Right CLI Style

So, which approach is best?

The answer depends on the nature of the tool:

• If your CLI works with fixed resources, a resource-type-first approach (like cfy) makes sense.

• an action-first approach (like kubectl) is better if your CLI needs to handle dynamic or API-driven resources.

• a hybrid approach (like terraform) might be ideal if your tool requires high-level operations and granular control.

Understanding these design principles helps create CLIs that are intuitive, scalable, and efficient. What's your take on CLI design? Have you encountered a CLI that does things differently? Let me know in the comments!

If you want to learn more about what libraries and tools I use to build these CLIs, let me know in the comments, and I will write a follow-up post. 📝

Until next time, happy coding, and never stop learning and challenging the status quo!

Go Rebels! ✊🏼

The same applies to Kubernetes and Helm. While developers can easily build and test applications locally, DevOps teams face a different reality when deploying to enterprise environments, particularly those in Zero Trust Networks (ZTN), introduce strict controls, approval bottlenecks, and rigid security policies that make integration a serious challenge. Airgap restrictions, security policies, and compliance requirements introduce a new layer of complexity that local development can't solve alone. But, what about a hybrid approach?

This post explores these two parallel challenges - the AI enterprise gap and the DevOps enterprise gap - and how teams can bridge them. A practical use case example is the challenge of orchestrating AI and Kubernetes workflows in enterprise environments, where visibility, compliance, and automation are key. Let's dive in.

AI's Biggest Challenge Isn't AI

AI has made incredible strides in recent years, from transforming customer service to optimizing supply chains; every industry is exploring AI applications in marketing, healthcare, and finance. The rise of Large Language Models (LLMs) has opened up new possibilities for natural language processing, chatbots, and content generation. But the biggest challenge isn't building AI models—it's integrating them into enterprise IT systems.

The AI-Enterprise Disconnect

While AI models have made remarkable strides, most enterprises struggle with:

• Data integration: AI is only as good as the data it can access, but enterprise data is often siloed, locked behind security policies, or tied to legacy systems.

• IT approvals and security: Enterprises operate in regulated environments where introducing new tools requires rigorous vetting. An AI model that needs full access to internal systems is often a non-starter.

• Scalability and operationalization: Developing an AI model in a lab is easy; deploying and maintaining it at scale is the real challenge. Organizations need MLOps pipelines to manage retraining, versioning, and observability.

• End-user adoption: AI adoption isn't just about technical implementation - it's about trust. Employees need confidence in AI recommendations, and organizations must navigate explainability, bias, and compliance challenges.

Solution: Making AI Work in Enterprise IT

To bridge this gap, enterprises need to stop thinking of AI as an isolated project and start integrating it into their workflows:

• Agentic AI systems: AI needs to interact with enterprise data, APIs, and security policies while complying with existing access controls. This is where Agentico.dev (a discovery platform for agentic AI tools) can help navigate solutions.

• Infrastructure-aware AI: AI applications should know enterprise constraints, security rules, and compliance requirements rather than assuming open access. QBot, your Kubepilot, can help with this; it is an AI-powered assistant for cloud-native environments.

• Context-aware workflows: AI needs human-in-the-loop processes to ensure reliable and trustworthy decision-making. Agentico.dev works with QBot to provide these smart autonomous workflows for cloud-native environments.

Kubernetes and Helm in Enterprise Zero Trust Environments

Why Local Development is Not Enough

Developers can set up Kubernetes and Helm applications locally, but real-world enterprise deployments are different:

1. Tooling restrictions: Enterprises enforce strict approved toolsets - introducing a new CLI tool or automation script is often impossible. ⚠️

2. Airgap and Zero Trust: Many enterprise environments (finance, defense, telecom) restrict internet access, preventing direct downloads of images, charts, or dependencies.

3. Configuration drift: Deploying across multiple environments (dev, test, staging, production) leads to inevitable drift - how do you detect and manage it?

4. Version mismatches: Helm charts and Kubernetes manifests may work in one cluster but fail in another due to different Kubernetes versions, security policies, or RBAC restrictions.

5. Approval and compliance bottlenecks: Even minor changes (e.g., modifying a Helm chart) require approvals, slowing down iteration cycles.

How to Solve It: Enterprise Kubernetes Best Practices

To navigate these challenges, enterprise teams must adopt a structured approach:

• Pre-approved package formats: Instead of raw Helm charts or YAML files, enterprises should distribute Kubernetes manifests as OCI artifacts, making them easier to verify and deploy.

• Airgap-friendly tooling: Solutions like K1s Airgap help move container images and Helm charts across restricted environments without breaking security policies.

• Automated drift detection: Implement GitOps workflows (ArgoCD, FluxCD) to monitor and correct drift between environments continuously. Or even better, use QBot to automate this process.

• Enterprise-grade observability: Tracing deployments and workflows is crucial. Use tools like OpenTelemetry, Loki, and Prometheus to capture granular logs and metrics. Agentico's AI tools can help with this out of the box; with mcp-create-tool, you can enable OpenTelemetry in your AI tools.

• Standardized scaffolding: Automate directory and scaffolding creation with templates, ensuring that every project starts with a consistent structure. This is how QBot DevOps init and scaffold actions work; they create a new project with a consistent structure, either the CLI or the MCP Tools.

The Common Thread - Process Orchestration and Visibility

Managing and Monitoring Workflows in AI and AIOps

Both AI Workflows and DevOps pipelines suffer from the same hidden complexity - a lack of visibility into all the inner steps involved in deployment, integration, and execution. Now, AI and Kubernetes, need to be orchestrated and monitored to ensure compliance, security, and reliability.

Questions Enterprises Need to Ask:

• Where do bottlenecks occur in AI integration or DevOps deployments?

• How do we track dependencies across teams and environments?

• Can we audit every step of an AI decision, including the DevOps pipeline or Kubernetes deployment?

• How do we validate that an AI-generated result or a Kubernetes manifest is compliant before deployment?

Solutions for Monitoring Inner Steps in AI & Kubernetes

1. End-to-End Observability

   • AI: Use AI observability tools to track model performance and bias.

   • Kubernetes: Implement tracing (Jaeger, OpenTelemetry) for complete visibility.

2. Automated Compliance Checks

   • AI: Governance tools for tracking AI outputs, bias, and ethical considerations.

   • Kubernetes: Policy engines (Kyverno, OPA) to enforce security rules.

3. Self-Healing Workflows

   • AI: Auto-retrain models when accuracy drops below a threshold.

   • Kubernetes: Auto-rollbacks when a deployment fails.

Bridging the Gap: AI and Airgap in Enterprise IT

A Strategic Framework for Prioritizing Enterprise-Oriented Solutions

Enterprises operate in complex IT landscapes where adopting new technologies - like AI or cloud-native DevOps tools - is never as simple as plugging them in. The real challenge lies in aligning these solutions with security policies, compliance requirements, and existing IT infrastructure.

The strategic framework illustrated above highlights how different solutions fall into one of four quadrants based on:

• Integration Level: How well a solution fits within the existing enterprise tech stack.

• Enterprise Policy Alignment: How naturally a solution adheres to corporate security, governance, and compliance requirements.

By mapping solutions across these dimensions, enterprises can make informed decisions about AI, DevOps, and automation strategies. If a solution doesn't fit within the enterprise's existing policies or tech stack, it's likely to face resistance or fail to deliver the expected value, but you can always bridge the gap with tools like Agentico.dev and QBot, designed to work within enterprise constraints.

Conclusion: AI and Kubernetes Need Enterprise-Ready Orchestration

The problem isn't AI. The problem isn't Kubernetes. The problem isn't the workflows. The problem is integration, security, compliance, and scaling adoption in enterprises.

To succeed, organizations need to:

✅ Design AI with enterprise constraints in mind - not as an isolated tool.
✅ Ensure Kubernetes workflows are airgap- and ZTN-compatible.
✅ Automate monitoring, drift detection, and compliance validation.
✅ Adopt tools that work within enterprise policies rather than fighting against them.

By addressing the big integration challenge, enterprises can truly unlock the potential of AI and Kubernetes at scale.

Are you ready to bridge the gap? Let us know in the comments below!

Do you have questions? Contact us at La Rebelion Labs or Agentico.dev for more insights on bridging the AI and DevOps enterprise gap.

Be Rebel, be Innovative, be Agile, be Agentico! Go Rebels! ✊🏻

With MCP, you can integrate AI-driven automation directly into your air-gapped workflows. Claude for Desktop acts as your user-friendly interface, enabling natural language interaction with AI tools running locally on your PC. Imagine being able to automate scripts, manage deployments, and even perform drift detection; all while staying within the confines of a secure environment.

Let's dive into why this approach is a game changer and how you can get started with a simple example.

Why MCP and Claude for Desktop Are Perfect for Zero Trust and Air-Gapped Use Cases

Simplified Automation: Claude for Desktop allows you to run scripts, including bash scripts, directly from your PC. Whether you're deploying applications or performing repetitive tasks, this setup eliminates the need for constant manual intervention.

Enhanced Security: Data flowing to external Large Language Models (LLMs) can be a concern. By using Local LLMs, you can encapsulate sensitive data and still benefit from natural language processing and semantic orchestration. This ensures that no sensitive information leaves your secure environment.

Bridging Gaps Between Systems: Claude's ability to communicate with both cloud and air-gapped environments makes it a versatile tool for hybrid setups. This is particularly beneficial in ZTNA environments where strict security policies might otherwise limit operational flexibility.

Customizability: With MCP tools, you can build deterministic workflows and gradually enhance them by adding memory and sequential learning capabilities. This enables your system to grow smarter over time, adapting to your specific needs.

A Simple Example: Echoing Messages with MCP and Claude

To demonstrate how easy it is to get started, let's set up a simple MCP tool that echoes a message. While basic, this example highlights the potential of MCP and Claude for automating workflows in air-gapped environments.

Step 1: Install Required Tools

• Download Claude for Desktop: Claude for Desktop

• Install Node.js: Node.js Official Website, as MCP tools require Node.js to run. Python is also supported, but not covered in this example.

Step 2: Create an MCP Tool

Use the Agentico MCP Create Tool to generate a new project:

npx @agentico/mcp-create-tool my-agentico-tool -t Echo -d "Echo a message from MCP server to the client"
cd my-agentico-tool
npm install && npm run build

This command creates a TypeScript project with all the necessary files, including an example configuration file for Claude. It's designed to simplify the onboarding process for DevOps practitioners who may not be familiar with TypeScript. ⭐ Star the MCP Create Tool on GitHub if you find it helpful!

Step 3: Update Claude’s Configuration

Ensure Claude's configuration file is updated automatically, the mcp-create-tool adds an entry with the path to your MCP tool.

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%\Claude\claude_desktop_config.json

Here's an example:

{
  "mcpServers": {
    "my-agentico-tool": {
      "command": "node",
      "args": [
        "/path/to/project/my-agentico-tool/build/index.js"
      ]
    }
  }
}

Please refer to the Claude user guide for detailed instructions if you need anything.

Step 4: Test the Setup

Open Claude for Desktop and type the following message in the chat:

echo hello

Claude will respond with:

hello

This interaction demonstrates how the MCP tool processes a message and returns a response. You can review the code in src/index.ts and customize it to handle more complex tasks.

You can test with different messages and observe how Claude interacts with your MCP tool to execute the desired actions.

I know, it's a simple example, but it showcases the power of MCP and Claude for Desktop in automating workflows within air-gapped environments. Your imagination is the only limit to what you can achieve with these tools.

Future Possibilities

The potential for MCP and Claude for Desktop extends far beyond simple tasks. Imagine using these tools to:

• Automate application deployments: Seamlessly manage builds and rollouts without internet access.

• Perform drift detection: Compare the desired and actual states of your systems to identify configuration issues.

• Integrate with Local LLMs: Enhance security while leveraging AI capabilities for smarter workflows.

Stay tuned for an upcoming post where we'll cover how to use Claude for Desktop to automate deployments and detect drift in air-gapped environments. The possibilities are endless, and this is just the beginning.

Conclusion

The combination of MCP and Claude for Desktop offers a groundbreaking way to tackle the challenges of ZTNA and air-gapped environments. By enabling natural language interaction with local AI tools, this approach simplifies workflows, enhances security, and empowers DevOps practitioners to achieve more with less effort.

Ready to revolutionize your DevOps workflows? Start exploring MCP with Agentico and Claude for Desktop today. And remember: your imagination is the only limit.

Go Rebels! ✊️

In this article, we'll explore the power of Agentic tools, the role of MCP Server in simplifying AI workflows, and how you can leverage these tools to build your own AI applications. Let's dive in!

The Rise of Agentic AI

At the heart of this evolution lies the Model Context Protocol (MCP), a framework developed by Anthropic. MCP introduces a standard protocol for AI applications to communicate seamlessly with one another, and with the rest of the world. While MCP opens doors to powerful integrations, getting started can feel daunting, especially for those new to Agentic AI.

That's where La Rebelion's MCP Server comes in. We are in the quest to simplify the process of creating and managing Agentic tools, by building a server facade that acts as a bridge between your tools and MCP we are on track to achieve it! Our approach is inspired by the simplicity and effectiveness of microservices and containers: each tool does one thing and does it exceptionally well.

Why Agentic Tools Matter

Agentic tools are to AI what microservices are to cloud architecture—modular, efficient, and purpose-driven. Each tool focuses on a specific task, ensuring precision and reliability. However, building these tools from scratch can be cumbersome. You need to handle communication protocols, input validation, and execution logic. That's a lot of complexity for something that should be simple.

Enter MCP Server, our server facade that eliminates the grunt work. You focus on crafting the core logic of your tool, and we handle the heavy lifting—like communication with MCP, input/output validation, and orchestration. It's like giving your tools a backstage crew to ensure the show runs flawlessly.

From Complex to Seamless: Building with MCP Server

Let's look at how effortless it is to create and deploy an Agentic tool using La Rebelion's MCP Server. Here's an example where we build a simple Echo Tool:

// src/index.ts
// Create a new instance of the MCPServer
import { EchoTool } from "./EchoTool.js";
const myServer = new MCPServer('My MCP Server', '1.0.0');

async function main() {
  // Register tools
  myServer.registerTool("echo", new EchoTool());
  await myServer.run();
}

In this example:

1. You define the logic of your tool (e.g., Echo Tool).
2. You register it with the server facade (myServer.registerTool).
3. MCP Server takes care of the rest—communicating with MCP, validating inputs/outputs, and executing the tool seamlessly.

Here's a visual breakdown of the architecture leveraging Anthropic's Model Context Protocol:

References:

MCP Server@GitHub
MCP Server@npm

Build Your Own Agentic Tools Today

Whether you're optimizing a workflow, automating a process, or enhancing an existing operation, Agentic AI tools can help you achieve your goals. By leveraging the power of MCP Server, you can build and deploy tools that communicate seamlessly with other AI applications, creating a robust ecosystem of intelligent agents. La Rebelion's MCP Server empowers you to focus on what matters most: building tools that deliver real value. By simplifying the complexities of MCP integration, we make it easier for developers to dive into the world of Agentic AI.

Agentic AI is revolutionizing the way we build, deploy, and manage AI applications. With tools like MCP Server, developers can create intelligent agents that communicate effortlessly, streamlining workflows and enhancing productivity.

Ready to start? Explore the MCP Server on GitHub or check out the npm package to get started.

At La Rebelion, we believe that tools, like microservices, should be small, focused, and powerful. With our MCP Server, you can bring your AI ideas to life without sweating the details. Let's build something incredible, together.

What will you create with Agentic AI and MCP Server? Let us know in the comments below!

Go Rebels! ✊🏻

And here's the best part: MCP is not limited to a single language model like Claude. You can leverage any LLM (Large Language Model) to power your agents, providing unmatched flexibility for developers.

What Makes Agentic AI Different?

AI agents are evolving beyond simple chat interfaces. They can now reason through complex problems, plan and execute tasks, and collaborate with other agents. This "agentic" capability makes them more than assistants - they're powerful tools for augmenting human potential.

Core Components of AI Agents:

According to Armand Ruiz, VP of AI product at IBM, AI agents typically consist of four key components:

1. Agent Core: The brain of the agent, managing integrations and processes.

2. Memory Module: Keeps track of past interactions and data for better context and continuity.

3. Tools: APIs or other external systems that the agent can use to perform tasks.

4. Planning Module: Enables advanced problem-solving by analyzing and strategizing to achieve goals.

These features align closely with MCP's concepts in the core architecture, where Servers act as the agent core, Tools extend functionality, Resources provide context, and Prompts guide workflows.

MCP: The Backbone of Agentic AI

With MCP, developers can create agents equipped with powerful primitives:

• Tools: Let agents execute actions, interact with external systems, and perform computations.

• Resources: Provide structured data or content to enhance the agent's decision-making process.

• Prompts: Create reusable templates to guide workflows, chain interactions, and surface user-friendly commands (e.g., slash commands in a UI).

This modular approach ensures that agents remain adaptable and powerful, capable of solving specific tasks or collaborating with other agents in a multi-agent framework.

With MCP Inspector, the developer experience is enhanced, allowing developers to easily debug and test their agents.

My Journey: Building an Agent to Deploy Microservices

I'm currently working on an AI agent designed to deploy microservices on Kubernetes. By leveraging MCP, I've created an agent capable of:

• Using Tools to interact with Kubernetes APIs and manage deployments.

• Accessing Resources to gather configuration files, cluster states, and deployment histories for better context.

• Employing Prompts to streamline user interactions, enabling developers to input dynamic arguments or chain workflows effortlessly.

This agent, named QBot, is a DevOps "SME" (Subject Matter Expert) that assists users through deploying microservices, managing Kubernetes environments, and troubleshooting deployments. By combining the power of AI with the flexibility of MCP, QBot simplifies complex tasks and empowers developers to focus on innovation.

Why MCP and AI Agents Matter?

1. Simplifies DevOps: Newcomers can overcome the steep learning curve of Kubernetes with an agent guiding them through deployments.

2. Empowers Experts: Experienced engineers can focus on higher-value tasks by automating repetitive processes.

3. Scales Seamlessly: MCP allows for using multiple LLMs, meaning agents can adapt to different models or languages as needed.

4. Enhances Collaboration: Agents can work together, sharing resources and tools to tackle complex workflows that no single agent could handle alone.

5. Boosts Efficiency: By automating tasks, agents reduce human error and speed up processes, leading to faster deployments and more reliable systems.

The challenge is was to connect your data and APIs to LLMs, but with MCP, that problem is solved. You can have everything in your PC or AirGap environment and connect your data and APIs to LLMs.

Now, the developers can focus on building agents tailored to their needs, leveraging the power of AI to streamline operations and push boundaries.

How You Can Get Started

This is just the beginning of a journey to transform automation. By replicating my approach, you can adapt this methodology for other workflows, from testing pipelines to automating IT operations.

Want to build an agent tailored to your needs? Here's what to do:

1. Explore MCP: Familiarize yourself with its architecture and concepts here.

2. Identify Tasks: Start with a specific, repetitive task that could benefit from automation.

3. Design Your Agent: Use MCP's primitives to define your Tools, Resources, and Prompts.

   1. Break down the task into smaller tasks that the agent can handle. These are your Tools.

   2. Identify the data or context needed to complete these tasks. These are your Resources.

   3. Create a workflow that guides users through the task. These are your Prompts.

4. Iterate and Scale: Test your agent, refine its capabilities, and expand it to handle more tasks.

I am going to guide you through this framework in future posts, sharing insights and tutorials to help you build your own AI agents.

The Road Ahead

The future of AI is agentic. As these technologies mature, we'll increasingly collaborate with AI agents to streamline operations and push boundaries. MCP provides the framework to start building these agents today, with the flexibility to use any LLM that suits your project.

I'm thrilled to share my journey and help you apply these concepts to your automation projects. Together, we'll explore how AI agents can revolutionize workflows.

Subscribe and follow "La Rebelion" for updates, tutorials, and insights as we navigate this exciting landscape. Let's enjoy the ride!

Take a look at our YouTube channel and subscribe to stay updated with our latest videos, I will be sharing more about AI agents, MCP, and how to build your own AI agents.

Let's simplify the complex, automate the mundane, and unlock the full potential of AI agents with MCP.

Go Rebels! ✊🏻

Update - Agentico

Agentico, where AI meets simplicity. I am working on this new amazing idea to solve some of the problems due to the proliferation of AI tools, and if you like me are asking:

• What tools already exist?

• Which tools fit my needs?

• How do I find tools across diverse environments?

Identifying the right tools across multiple environments feels like finding a needle in a haystack. Agentico Tools discovery will help you tackle these problems.

Stay tuned!

Let’s face it: writing scripts in Python or Bash isn’t everyone’s cup of tea. But what if I told you that those days might be over? Anthropic's Model Context Protocol (MCP) is here to change the agentic field, the innovation that’s leveling the playing field in AI.

MCP flips the script on the traditional barriers to AI adoption. You no longer need to wrestle with setting up complex environments or mastering niche programming languages to make AI work in your local setup. All you need is the right MCP Server, and you’re off to the races.

Scripts, Simplified: Plain English for the Win 🚀

Imagine writing a script not in code, but in natural language. Yeah, you read that right. Something like:

"Deploy the retail microservice ACME 1.1 in our Dev Kubernetes cluster."

That’s it. No loops. No syntax errors. Just plain, simple instructions. MCP handles the heavy lifting, translating your request into action. It’s like magic but powered by AI.

Why Does This Matter? 🧐

Because it puts the power of AI into everyone’s hands—not just developers. Take a Product Manager, for example. Sure, they’re not the ones deploying microservices (and they probably shouldn’t be 😅). But if they can, then so can:

• A marketer running a campaign analysis.

• A data analyst pulling metrics.

• You, tinkering with your side hustle on a Sunday afternoon.

It’s accessibility at its finest, and it’s making tech more inclusive.

Ready to See MCP in Action? 🎥

In another post, I’ll walk you through a live demo of MCP in action. I’ll show you how to deploy a microservice in a Kubernetes cluster using nothing but natural language “commands” (prompts) with Anthropic's Claude for Desktop and QBot MCP Server by La Rebelion.

No coding. No fuss. Just results. The sky is the limit!

If this sounds like something you don’t want to miss (and trust me, you don’t), hit that follow button. Let’s take this journey together, one natural-language script at a time.

Do you have someone in mind who could be interested and benefit from this? Share the love, and send them the article link, I will appreciate it. 🥰

Go Rebels! ✊🏻

CSAR focus on how to deploy and manage applications, while SBOM secures what is in them. What if we combined both to orchestrate securely across public, private, and airgapped environments?

DevOps and Kubernetes in airgap environments are challenging, and in this post, we'll explore some ideas of strategies for deploying cloud-native apps in Kubernetes in airgap environments. One of the bigger challenges I've noticed is still moving images to private registries; it's a roadblock that continues to trip people up, especially in airgapped environments. Security is another big concern in these environments, and it's important to have a strategy in place to ensure that your Kubernetes cluster is secure.

I aim to explore how we can leverage the strengths of different tools and frameworks to avoid creating from scratch and use well-known standards and frameworks to solve this problem. I'll be looking at how we can combine the strengths of CSAR and SBOM to extend them and create a new approach to move images to private registries in airgapped environments. I'll also explore some of the alternatives available today and how they can be used to solve this problem.

• Why the tools we have today are not enough to solve this problem?

• What are the challenges, what alternatives do we have to move images to private registries in airgapped environments?

These are some of the questions I'll be exploring in this post. I'll also be sharing some ideas on how we can leverage the strengths of different tools and frameworks to create a new approach to move images to private registries in airgapped environments. Keep reading to learn more!

The Challenge of Moving Images to Private Registries in Airgapped Environments

While we have amazing tools to deploy cloud-native applications, the process of moving images to private registries is still a challenge; think about it: before, on bare-metal environments, or VMs, managing RPMs or DEBs was (is) also a challenge, I faced this problem in the past, when I was working in a project that required to install a Vanilla Kubernetes cluster in a private network, I had to install a lot of packages in a lot of servers, and the servers were in a private network, so we had to download the packages in a server with internet access, then move the packages to the private network, and install the packages in the servers. Well, we live in cycles, right? Now, the story is the same, but with containers, we have to download the images from a server with internet access, then move the images to the private network, and then deploy the images to the servers.

In fast-paced and agile enterprises, where business agility drives multiple value streams, each with unique requirements, dependencies, and security demands, managing Kubernetes or containerized clusters across teams can feel overwhelming. The more projects and clusters, the more time-consuming and error-prone the process becomes. Worse, moving images across networks can expose your systems to serious security threats. Now imagine doing all of this in airgapped environments—no internet access, and even tougher challenges. You need a solution to move images to private registries seamlessly, without compromising security. The stakes are high, and it's time to rethink how we tackle this.

We can summarize the challenges of moving images to private registries in airgapped environments as follows:

• The first challenge is moving images to private registries. In airgapped environments, you can't pull images from public registries like Docker Hub or Quay.io. You need to move images to a private registry in the airgapped environment.

• The second challenge is security. In airgapped environments, security is a top priority. You need to ensure that your Kubernetes cluster is secure and that you're not exposing your cluster to security risks.

• The third challenge is orchestration. In airgapped environments, you need to orchestrate and manage dependencies. You need a way to track dependencies and vulnerabilities and ensure that your deployments are secure.

What alternatives do we have to move images to private registries in airgapped environments?

Alternatives to Move Images in Airgapped Environments

In modern enterprise environments, particularly airgapped and hybrid ones, efficient package management and secure software distribution are critical. I was wondering, how could some of the frameworks and tools that we have today help us to solve this problem. CSAR, SBOM, Docker Compose, Helm, Kustomize, ArgoCD, and many other, each of these tools has unique strengths, addressing various aspects like dependencies, vulnerabilities, orchestration, and inventory management.

These cannot help us to tackle the problem of moving images to private registries in airgapped environments. But what if we could combine the strengths of these tools to create a new approach to move images to private registries in airgapped environments?

Why the tools we have today are not enough to solve this problem?

Why Helm, Kustomize, and ArgoCD are not enough?

Restricted environments like airgapped or high-security ones require a different approach to conventional software deployment. Firstly, standard tools like Helm, Kustomize, or Docker Compose are not designed to handle the complexities of airgapped environments. They cannot move images to private registries in airgapped environments, track dependencies, and vulnerabilities, and orchestrate deployments across multiple environments. They are focused only on defining and deploying applications, not on managing the complexities of airgapped environments.

Secondly, the alternatives on top of current solutions are not enough to solve this problem. Tools like Crane, and Skopeo provide ways to move images between registries, but they cannot track dependencies and vulnerabilities, orchestrate deployments, and manage software packages securely in airgapped environments. Tools like Hauler, and Zarf are focused on packaging and distributing assets in airgapped environments, these are great alternatives but are tightly focused on specific non-standard package formats that may not be suitable for all use cases.

Thirdly, the lack of transparency and security in the software supply chain, combined with the absence of a unified solution presents a significant challenge. With mandates like the White House’s push for enhanced Software Supply Chain Security, organizations need a way to securely move images to private registries in airgapped environments, track dependencies, and vulnerabilities, and orchestrate deployments across multiple environments. A comprehensive solution that ensures security, transparency, and compliance—while managing software packages seamlessly and securely in airgapped setups—is essential.

CSAR and SBOM: Two Frameworks, Two Solutions

The Cloud Service Archive (CSAR) and Software Bill of Materials (SBOM) frameworks are two solutions aimed at solving different problems. CSAR focuses on orchestrating deployments of network functions, while SBOMs, like CycloneDX and SPDX, ensure security and transparency by providing a detailed inventory of components. But as organizations move toward stricter security practices, airgapped environments, and hybrid clouds, a new approach is needed; one that blends the strengths of both.

CSAR packages simplify orchestration and deployment in NFV environments, but they don't track dependencies or vulnerabilities. SBOMs (CycloneDX/SPSX) excel at security and compliance, listing components and vulnerabilities. But they don't provide a way to orchestrate the inventory and dependencies for deployments. CSAR's role is about how to deploy, while SBOM's role is what is deployed and how to manage its risks. A new approach is needed to combine the strengths of both frameworks. This approach should provide a way to manage and set up a private registry, move images to it, and orchestrate deployments while tracking dependencies and vulnerabilities. It should also support airgapped environments and hybrid clouds.

An inventory of components and orchestration to move images to private registries in airgapped environments has become a necessity and is a must-have for modern enterprise projects. I was thinking about how to solve this problem, with either a tool or a service, and I came up with the idea of building a tool that can help with this. The tool is part of the K1s project, and it's called K1s Airgap SABOR (Software Airgap Bill of Materials Resolver). K1s' SABOR is a tool that helps you move images to private registries in airgapped environments. It's a simple tool that you can run on your local machine, and it will help you move images to private registries in airgapped environments.

Before we dive into the details of SABOR, let's take a look at the challenges of deploying Kubernetes in airgap environments, and what options you have.

Alternatives to Move Images to Private Registries in Airgapped Environments

There are several alternatives to move images to private registries in airgapped environments. Here are some of the most common ones:

• Docker Save and Load: You can use the docker save and docker load commands to save images to a tarball and then load them into a private registry (as demoed in my video here). This is a manual process and can be time-consuming.

  • If you don't have or don't want to install Docker (or any other tool) you can do it with curl! Yes, check this video demo I made here.

• Crane and Skopeo: Crane "is a tool for interacting with remote images and registries". Skopeo is a tool that helps you copy images between registries. You can use Crane or Skopeo to move images to private registries in airgapped environments.

• Hauler: Hauler is a tool "designed and built to solve the challenges of collecting, packaging, and distributing assets in airgapped environments".

• Zarf: Zarf is a tool that "provides the ability to package necessary components from the internet and securely deliver all of the files and dependencies needed to run an application in a disconnected environment" (airgapped).

I ordered this list by the complexity of the tool, from the simplest to the most complex (based on my experience). Additionally, on enterprise projects, you may need to use a combination of these tools to move images to private registries in airgapped environments; in these kinds of projects, due to the security restrictions the ISV (Independent Software Vendor) will probably share with you a set of images that you will have to move to your private registry, or in self-service projects, the ISV and System Integrators will have to move the images to the private registry, but they may have restricted access to the Kubernetes cluster, so they will not be able to use tools that require cluster role permissions, some of the tools mentioned above require cluster role permissions, to deploy operators, or add CRDs.

There is this other project incubating in the Linux Foundation, called Sigstore, that aims to provide a way to sign and verify software artifacts. Singing and verifying software artifacts is a must-have in airgapped environments.

Another great initiative is BOM (Bill of Materials), a Kubernetes Special Interest Group (SIG) that aims to provide a way to track dependencies and vulnerabilities in Kubernetes deployments.

Also, Zarf is a great project leveraging the power of the SBOM framework, but I found it a bit complex to use and would be hard to integrate into a pipeline already in place in enterprise projects, it is focused on packaging and delivering assets in airgapped environments.

As I said, why not leverage the different strengths of these tools to create a new approach to move images to private registries in airgapped environments?

SABOR: A New Approach Extending SBOM and CSAR to Move Images in Airgapped Environments

Recognizing the strengths of both CSAR and SBOM, the airgap tool I'm building takes a hybrid approach.

SBOM strengths:

SBOMs, like CycloneDX and SPDX, address these limitations by providing a transparent view of software composition. They focus on the what; tracking all software components, their versions, dependencies, and potential security vulnerabilities. In airgapped or high-security environments, knowing exactly what's inside each software package is critical for managing risks and maintaining compliance.

• Security Focus: SBOMs shine when it comes to identifying vulnerable components and managing risk. With increasing software supply chain attacks, having this transparency is crucial.

• Compliance and Auditability: SBOMs help organizations meet regulatory and industry standards by providing detailed insight into software components.

Limitations of SBOM:

• Lack of Orchestration: SBOMs track what is inside a package but don't help deploy or manage the how or where of that package across cloud environments.

• Not Built for Distribution: SBOMs don't inherently provide mechanisms to package and distribute software effectively, particularly in complex, hybrid, or airgapped environments.

CSAR: The Orchestration Powerhouse with Limitations

CSAR packages are a solution designed to simplify the deployment and lifecycle management of network services, especially in NFV (Network Function Virtualization) environments. They bundle everything needed for deploying these services; service descriptors, configuration files, and scripts; making it easier to orchestrate and deploy complex systems like Virtual Network Functions (VNFs) across cloud environments.

However, CSAR has limitations:

• Deployment Focused: While it's excellent at managing the how and where of deployments, CSAR doesn't track the what; it doesn't list or manage software components, dependencies, or vulnerabilities.

• Limited Security Insight: CSAR doesn't provide a detailed breakdown of software components, leaving gaps when it comes to tracking software risks or ensuring compliance.

How does SABOR extend all of these strengths?

Recognizing the strengths of both CSAR and SBOM, the airgap tool I'm building takes a hybrid approach. By leveraging SBOM data, the tool will provide a full breakdown of components while allowing users to securely package and distribute software without internet access. This is particularly vital for industries like telecom or defense, where security and compliance are paramount.

SABOR will:

• Extend SBOMs by not just tracking the what but also leveraging that information to create secure, compliant packages for airgapped and hybrid cloud environments.

• Focus on Distribution: This tool will handle the how and where by orchestrating package distribution across public clouds, private clouds, and airgapped environments. This addresses CSAR's strength in orchestration while extending SBOM's transparency to a more practical application.

• By leveraging SBOM data, the tool will provide a full breakdown of components while allowing users to securely package and distribute software without internet access. This is particularly vital for industries like telecom or defense, where security and compliance are paramount.

• Extend CSAR's orchestration capabilities to include SBOM data, providing a comprehensive solution for managing software packages across multiple environments.

Future Enhancements: Orchestrating Across Multiple Environments

Looking ahead, this tool will not only package and secure software components but also orchestrate their distribution:

• Multi-Cloud Compatibility: It will support deployment in public and private clouds, allowing organizations to seamlessly move packages between environments.

• Hybrid Cloud Orchestration: Enterprises working with a mix of cloud and airgapped environments will benefit from centralized orchestration, ensuring that the right packages are deployed in the right places, with full transparency and control over their contents.

As software supply chains become increasingly complex, and as organizations move toward hybrid cloud and airgapped solutions, there's a growing need for tools that offer both security and orchestration. CSAR helps with orchestration, but it lacks transparency and security insights. SBOMs provide transparency but don't manage how or where packages are deployed.

BONUS: Recipies on Current Tools in Action

Let's explore a hypothetical example of how we could use CSAR and SBOM to move images to private registries in airgapped environments and orchestrate deployments.

CSAR: Orchestrating Deployments

CSAR packages simplify orchestration and deployment in NFV environments, but they don't track dependencies or vulnerabilities. They focus on the how of deployments, not the what. CSAR intentionally leaves out software composition details, focusing instead on orchestrating deployments. This makes it easier to manage complex network services but leaves gaps in security and compliance.

You could deploy containers with CSAR using a specific VNFM (Virtual Network Function Manager) that supports containers, but it is not the best tool for that because of the complexity, we want to get stick to Kubernetes, hence it is better to use Helm, or Kustomize for that.

How could we leverage the strengths of CSAR to move images to private registries in airgapped environments? Again, this is not the focus of CSAR, but it is a common problem that we face in enterprise projects, let's walk through a simple hypothetical example where you're deploying a web application using a CSAR package with a TOSCA template. The web app needs two things:

• A database.

• An application server that connects to the database.

TOSCA Template Breakdown

This template example will describe:

• Node templates: The components (like the database and app server).

• Relationships: How these components connect.

• Dependencies: The order in which things need to happen.

Here's what the TOSCA template might look like in a simplified version:

topology_template:
  node_templates:
    my_database:
      type: Database
      properties:
        db_name: my_app_db
        db_user: user123
        db_password: pass123
      interfaces:
        Standard:
          create: db_setup_script.sh # This script sets up the database

    my_app_server:
      type: WebApplication
      properties:
        app_name: my_web_app
        app_port: 8080
      requirements:
        - database_connection:
            node: my_database # This tells the app to connect to the database
      interfaces:
        Standard:
          create: app_setup_script.sh # This script installs and starts the app

What Happens When the Orchestrator Follows This Template

Orchestrator reads the TOSCA template: It starts by identifying the two components: my_database and my_app_server.

Step 1: Set up the database:

• The orchestrator sees that the database (called my_database) needs to be created first.

• It runs the db_setup_script.sh (defined under the create interface) to set up the database with the right name and credentials (my_app_db, user123, pass123).

Step 2: Set up the application server:

• Next, the orchestrator looks at the my_app_server node and sees that it needs the database to be ready before the app can be set up.

• The template says the app server should connect to the database (my_database), so the orchestrator knows to establish that link.

• After the database is ready, the orchestrator runs the app_setup_script.sh to install and start the web application.

How the Orchestrator Knows the Sequence

The orchestrator knows:

What to do first because the app server depends on the database (defined in the requirements section: database_connection: my_database). How to do it because the TOSCA template specifies the exact scripts to run for each component (like db_setup_script.sh for the database and app_setup_script.sh for the application).

Summary of the Orchestrator's Process:

1. Deploy the database first.

2. Wait for the database to be ready.

3. Deploy the application server after the database is up.

4. Make sure the application server can connect to the database.

This sequence is clearly laid out in the TOSCA template, and the orchestrator follows these instructions step by step to ensure everything works properly.

You may be wondering, "hey, this looks like a Helm chart or Docker Compose file!" Yes, it is similar, you can think of TOSCA in CSAR as a more complex and cloud-native version of Docker Compose. Both tools help you define and orchestrate multiple services, but they operate at different levels. Docker Compose focuses on containers, while TOSCA/CSAR works at a higher level, including virtual machines, networks, and cloud services.

One advantage of TOSCA VNF packages is that they can be deployed across different cloud environments, and you can package everything you need for a network service in a single package, including your container images. If you ned to move images from different registries in airgapped environments, you will need to extend the logic of the TOSCA template to move the images to the private registry in the airgapped environment, and this is the problem we are trying to solve.

To extend the TOSCA template to include the necessary components for moving images between registries, we can add node templates representing the source and destination registries, as well as the logic to move the images. This approach allows us to define relationships between components and orchestrate the movement of container images in a declarative way.

Here's how we could extend the TOSCA template to include image transfer:

Extended TOSCA Template Example

topology_template:
  node_templates:
    # Application Deployment Node
    web_application:
      type: tosca.nodes.WebApplication
      properties:
        name: "MyWebApp"
        version: "1.0"
        container_image: "myrepo/webapp:1.0"
      requirements:
        - host: web_server
        - registry_pull: source_registry
        - registry_push: destination_registry

    # Source Docker Registry
    source_registry:
      type: tosca.nodes.Registry
      properties:
        name: "Source Docker Registry"
        url: "https://source-registry.com"
        credentials: 
          username: "source_user"
          password: "source_password"
      interfaces:
        Standard:
          operations:
            pull_image:
              description: "Pull the image from source registry"
              implementation: scripts/pull_image.sh
              inputs:
                image_name: { get_property: [web_application, container_image] }

    # Destination Docker Registry
    destination_registry:
      type: tosca.nodes.Registry
      properties:
        name: "Destination Docker Registry"
        url: "https://destination-registry.com"
        credentials: 
          username: "dest_user"
          password: "dest_password"
      interfaces:
        Standard:
          operations:
            push_image:
              description: "Push the image to destination registry"
              implementation: scripts/push_image.sh
              inputs:
                image_name: { get_property: [web_application, container_image] }

    # Web Server
    web_server:
      type: tosca.nodes.Compute
      properties:
        os: "linux"
        instance_type: "t2.medium"
      interfaces:
        Standard:
          operations:
            configure:
              implementation: scripts/configure_web_server.sh

We can now define the logic for pulling the image from the source registry and pushing it to the destination registry in the pull_image.sh and push_image.sh scripts. These scripts can use tools like docker or skopeo to interact with the registries and move the images between them.

This extended TOSCA template allows us to define the entire deployment process, including moving the container image between registries, in a single declarative file. The orchestrator can then follow this template to deploy the application and manage the image transfer process automatically.

You can even extend this a little more:

Dedicated Image Transfer Node:

Instead of having the pull_image and push_image operations on the registries, we could define a dedicated node for transferring images between registries. This node would represent the transfer logic and could be scaled independently if needed.

Integrating with Helm:

If you're using Helm to manage Kubernetes deployments, you can integrate Helm hooks to trigger operations to validate the image transfer had been done before deploying a new version of the application. This way, you can ensure that the image is available in the destination registry before starting the deployment process.

SBOM Generation:

You could further enhance the template by adding SBOM generation after the image pull to capture and document all dependencies and vulnerabilities before moving to the destination registry.

By extending the TOSCA template with SBOM generation, you can ensure that your deployments are secure and compliant by tracking all dependencies and vulnerabilities in your container images.

SBOM: Tracking Dependencies and Vulnerabilities

While SBOMs (like CycloneDX or SPDX) aren't designed to manage orchestration, steps, or dependencies, they provide valuable metadata about software components, their licenses, and their relationships. SBOMs help with security, compliance, and tracking of software assets, but they don't handle deployment.

SBOMs, like CycloneDX and SPDX, provide a detailed inventory of components and vulnerabilities in software packages. They focus on the what—tracking all software components, their versions, dependencies, and potential security vulnerabilities. This transparency is crucial for managing risks and maintaining compliance in modern enterprise environments.

Extend SBOMs for Orchestration

Since SBOM focuses on describing the "what" (i.e., the components that make up an application or system), we can think of a way to extend SBOMs by adding "how" information to include dependencies and steps. Here's how we could theoretically extend SBOM for orchestration:

1. Component Description in SBOM:

   • Use existing SBOM structures to describe software components (e.g., web app, database, libraries).

   • Extend it by adding fields for deployment order and dependencies between components.

2. Define Relationships:

   • Introduce a new "orchestration" section in SBOM, similar to TOSCA's relationships or Docker Compose's depends_on. This section would define how different components rely on each other (e.g., app server depends on the database).

3. Deployment Steps:

   • Extend SBOMs to include execution scripts or commands for deploying components, similar to what CSAR or Docker Compose does with their create and run steps.

By doing this, SBOM could theoretically handle some orchestration tasks, though it's primarily designed for tracking components rather than deploying them.

Example of an Extended SBOM for airgap deployments:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:123e4567-e89b-12d3-a456-426614174000",
  "version": 1,
  "metadata": {
    "timestamp": "2024-10-28T12:34:56Z",
    "component": {
      "name": "MyWebApp",
      "version": "1.0",
      "type": "application"
    }
  },
  "components": [
    {
      "type": "container",
      "name": "webapp",
      "version": "1.0",
      "properties": [
        {
          "name": "image",
          "value": "myrepo/webapp:1.0"
        }
      ]
    },
    {
      "type": "platform",
      "name": "registries",
      "version": "1.0",
      "components": [
        {
          "type": "application",
          "name": "source_registry",
          "version": "1.0",
          "supplier": {
            "name": "docker hub",
            "url": [
              "https://source-registry.com"
            ]
          },
          "properties": [
            {
              "name": "username",
              "value": "myuser"
            },
            {
              "name": "password",
              "value": "mypassword"
            }
          ]
        },
        {
          "type": "application",
          "name": "destination_registry",
          "version": "1.0",
          "supplier": {
            "name": "quay.io",
            "url": [
              "https://destination-registry.com"
            ]
          },
          "properties": [
            {
              "name": "username",
              "value": "myuser"
            },
            {
              "name": "password",
              "value": "mypassword"
            }
          ]
        }
      ]
    }
  ],
  "externalReferences": [
    {
      "type": "formulation",
      "url": "https://orchestrator.com/wf/1234",
      "comment": "Workflow for deploying the web application"
    }
  ],
  "formulation": [ {
    "workflows": [
      {
        "taskTypes": ["deploy"],
        "uid": "0f8fad5b-d9cb-469f-a165-70867728950e",
        "bom-ref": "urn:k1s:webapp",
        "name": "deploy",
        "description": "Deploy the web application",
        "steps": [
          {
            "name": "pull",
            "description": "Pull the web application image",
            "commands": [
              {
                "executed": "pull",
                "properties": [
                  {
                    "name": "image",
                    "value": "myrepo/webapp:1.0"
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  }
  ],
  "dependencies": [
    {
      "ref": "webapp",
      "dependsOn": [
        "database"
      ]
    }
  ]
}

Here, the components are described as they normally would be in an SBOM. We've added a new "formulation" section to describe the deployment workflow, including steps like pulling the image from the source registry. The "dependencies" section specifies that the web application depends on the database component.

By extending SBOMs with orchestration information, we can create a more comprehensive view of software components and their deployment steps. This can help organizations manage complex deployments more effectively, especially in airgapped environments where transparency and control are critical.

Adding the Spices to Add Flavor to the Recipe: SABOR

The Proof Of Concept (POC) that I have in mind is to create a tool that can help you move images to private registries in airgapped environments. This tool will leverage the strengths of standard tools like CSAR and SBOM to provide a comprehensive solution for managing software packages in airgapped environments, as the catalog of images grows, the complexity of managing them increases, and the risk of security vulnerabilities grows. It will help you set up multiple private registries or environments, move images between them, and orchestrate deployments while tracking dependencies and vulnerabilities. See this as a tool that can help you to eliminate the burden of moving and packaging images in airgapped environments.

In your big enterprise projects, have you noticed that multiple teams or providers are duplicating the same work and breaking a standardization that could help to manage the software packages more efficiently? This tool will help you to centralize the work and make it easier to manage and update software packages.

How many images of the same software package do you have in your private registry? Commonly, in enterprise projects, you will have multiple images of the same software package in different "tenants" in the same registry, SABOR will help you to remove all the fat and keep only the necessary images, the perfect recipe!

Airflow in airgapped environments - secure, controlled, efficient

The starting point for SABOR is the SBOM. By leveraging the SBOM data, SABOR will provide a full breakdown of components while allowing users to securely package and distribute software without internet access. This is particularly vital for industries like telecom or defense, where security and compliance are paramount. Also, you can start from the bottom up, SABOR will help you generate the SBOM from the list of images that you define.

Demo: https://youtube.com/shorts/4ElqY-0Vtuc?feature=share

I decided to go with SBOM as the final solution because it provides a detailed inventory of components and vulnerabilities, making it easier to manage and update software packages. It also helps identify and manage vulnerabilities in software components, ensuring that organizations can address security risks proactively. SBOMs can be generated automatically as part of the software build process, ensuring that organizations have up-to-date information on software components. They can also be integrated with other tools and processes, such as vulnerability scanners and compliance tools, to provide a comprehensive view of software security and compliance.

By including orchestration metadata (like dependencies and deployment workflows) in the SBOM itself, you would allow users to not only track and verify components but also orchestrate them across multiple environments (public cloud, private cloud, and airgapped environments) securely and efficiently.

Conclusion

In this post, we explored the challenges of moving images to private registries in airgapped environments and discussed some of the alternatives available today. We looked at the strengths and limitations of CSAR and SBOM frameworks and how they could be extended to create a new approach to move images to private registries in airgapped environments. We also discussed the idea of combining the strengths of different tools and frameworks to create a comprehensive solution for managing software packages in airgapped environments.

What do you think about this approach? Do you think it could help solve the challenges of moving images to private registries in airgapped environments? I'd love to hear your thoughts and feedback on this idea!

Would you give it a try to SABOR? Let me know in the comments, and if you have any questions or suggestions, feel free to reach out. Go, Rebels! ✊🏼

Be curious, be rebellious, and keep learning! Subscribe to the newsletter for more content on Kubernetes, DevOps, and cloud-native technologies.

What is an Airgap Environment?

An airgap environment refers to a network that is physically isolated from the public internet or other external systems. This setup is typically used in industries with strict security requirements, such as telecom, healthcare, and government, to safeguard sensitive data and critical infrastructure.

While airgap environments provide enhanced security, they also impose restrictions on workflows, updates, and communication, making efficient Kubernetes operations more complex. These limitations can lead to anti-patterns—common pitfalls that can make your systems less effective and harder to manage over time.

1. The Siloed Operator

In a traditional Kubernetes setup, collaboration between DevOps and development teams is key to maintaining seamless operations. However, in airgap environments, operators often end up working in isolated silos, managing configurations, deployments, and updates without input from other teams. This creates bottlenecks and a lack of visibility across the organization; big projects usually require the collaboration of multiple teams, and environments, the ownership and accountability of each environment is usually distributed among different teams, often leading to miscommunication and misalignment.

In enterprise environments, the siloed operator anti-pattern can manifest in several ways:

• Lack of Communication: Operators work in isolation, leading to misaligned priorities and inconsistent configurations.
• Slow Deployment Cycles: Without cross-team collaboration, deployments take longer, leading to delays and missed opportunities.
• Security Gaps: Siloed operators may overlook critical security updates or misconfigure settings, exposing the system to vulnerabilities.
• Operational Inefficiencies: Manual handoffs and lack of automation result in inefficiencies and errors that could be avoided with better collaboration.
• Knowledge Gaps: Teams miss out on valuable insights and best practices when working in isolation, leading to suboptimal solutions and missed opportunities for improvement.

Solution

Cross-functional teams must be formed, ensuring that all members—from developers to security engineers—are involved in the Kubernetes lifecycle. Using tools like GitOps, teams can maintain consistency and improve communication across silos, even within the constraints of an airgap environment.

But how can you foster collaboration in an airgap environment? Build bridges between them, don't break the silos, break the walls. Silos are not the problem, the walls are. Silos are a natural way to organize teams and responsibilities.

Here are some strategies to consider:

• Cross-Training: Encourage team members to learn about each other's roles and responsibilities, fostering a culture of collaboration and shared ownership.
• GitOps: Implement GitOps practices to manage configurations and deployments in a version-controlled, collaborative environment. By using Git repositories as the source of truth, teams can work together to maintain consistency and transparency across the organization.
• Regular Syncs: Schedule regular meetings or stand-ups to discuss progress, challenges, and upcoming tasks. This ensures that everyone is on the same page and can address issues proactively.
• Automated Workflows: Use automation tools to streamline workflows and reduce manual handoffs between teams. By automating repetitive tasks, teams can focus on higher-value activities and improve efficiency.

2. Over-engineered Security Layers

Security is paramount in an airgap environment, but over-complicating it can result in convoluted workflows. Often, teams stack unnecessary layers of security tools and processes, leading to cumbersome configurations that slow down operations and increase the risk of misconfiguration.

Solution

Leverage Kubernetes' built-in security features like RBAC (Role-Based Access Control), network policies, and secrets management. Regularly audit your security layers to eliminate redundancy, ensuring that the environment remains secure but manageable.

3. Inconsistent Image Management

One of the biggest challenges in an airgap environment is managing container images. Teams often face discrepancies between development and production due to inconsistent versioning or missing dependencies in airgap bundles. This leads to deployment failures or time-consuming troubleshooting.

Solution

Adopt SBOMs (Software Bill of Materials) to track every component of your container images. Use tools like CycloneDX or SPDX to create detailed manifests of the software and dependencies required.

Here are some strategies to improve image management in airgap environments:

• Automate the bundling and distribution process using Kubernetes Operators to ensure that all dependencies are accounted for before deployment.
• Implement a registry proxy to cache images and dependencies locally, reducing the risk of missing components during deployment.
• Utilities like Kaniko or Buildah can help you build images in airgap environments without requiring a Docker daemon, streamlining the image creation process.
• Kubernetes BOM can help you track dependencies and vulnerabilities in your container images, ensuring that you have a complete picture of your software stack.
• K1s airgap is a package manager for Kubernetes that simplifies the installation and management of Kubernetes components in airgap environments. It provides a CLI and user-friendly interface for downloading and installing Kubernetes components without internet access. Allows you to orchestrate the installation of Kubernetes components in airgap environments, ensuring that your clusters are up to date and secure.

4. The Update Lockdown

Airgap environments typically delay software updates to ensure stability, but this can become an anti-pattern if critical security patches or updates are missed. Over time, this creates a backlog of necessary changes that may compromise the security and functionality of your Kubernetes clusters.

Solution

Establish an automated, selective update system that allows you to prioritize critical patches without exposing your system to unnecessary risks. Implement automated pipelines for downloading and applying updates from trusted internal sources, ensuring that your system remains up to date without disrupting operations.

Here are some strategies to consider:

• Automated Patch Management: Use tools like K1s airgap to automate the installation of updates and patches for your applications and Kubernetes clusters. This ensures that your system remains secure and up to date without manual intervention.
• Selective Updates: Prioritize critical security patches and updates, ensuring that your system remains secure without introducing unnecessary risks.
• Internal Package Repositories: Set up internal package repositories to host trusted updates and patches, allowing you to control the source of your software components. Build a pipeline that automatically checks individual components or packages for vulnerabilities and updates them as needed.
• Common Vulnerabilities and Exposures (CVE) Monitoring: Regularly monitor CVE databases to stay informed about security vulnerabilities and apply patches promptly to mitigate risks.
• Common Image Scanning Tools: Use image scanning tools like Trivy or Clair to identify vulnerabilities in your container images and take action to remediate them before deployment.

5. Manual Process Reliance

Without internet access, many teams revert to manual processes for deploying applications or making configuration changes in Kubernetes clusters. While this may work initially, it quickly becomes unsustainable and prone to errors, leading to inconsistent configurations and system drift.

Solution

Automate as much as possible. Use tools like Helm for package management, Argo CD for continuous delivery, and Kustomize for managing configuration layers. Even in an airgap environment, you can automate many aspects of your workflow to maintain consistency and reduce errors.

6. Undocumented Workarounds

In the heat of solving problems, teams often develop quick workarounds to navigate the unique constraints of airgap environments. However, without documentation, these ad-hoc solutions create technical debt, leaving the system brittle and difficult to troubleshoot.

Solution

Ensure that every workaround and process change is properly documented. Use tools like Docusaurus or MkDocs to create and maintain internal documentation that can be easily shared across teams. This makes your airgap Kubernetes system more resilient and easier to manage in the long run. Prepare SOPs (Standard Operating Procedures) for common tasks and procedures, ensuring that every team member has access to up-to-date documentation for troubleshooting and maintenance.

Here are some strategies to consider:

• Runbook Automation: Create runbooks for common tasks and procedures, ensuring that every team member has access to up-to-date documentation for troubleshooting and maintenance.
• Knowledge Sharing: Encourage team members to share their knowledge and best practices through internal wikis, chat channels, or other collaboration tools. This helps prevent silos and ensures that everyone has access to the information they need to be successful.
• Documentation as Code: Treat documentation as code, storing it in version-controlled repositories alongside your source code. This ensures that documentation is always up to date and aligned with your system's configuration. Use tools like GitBook, Docusaurus, MkDocs, or Read the Docs to create and maintain documentation in a collaborative, version-controlled environment.

7. Lack of Testing Parity

Testing in airgap environments can often be overlooked due to the infrastructure limitations. Without proper testing environments that mimic the production airgap conditions, teams can end up deploying untested code, leading to costly failures.

Solution

Set up mirrored environments that simulate the airgap restrictions as closely as possible. This includes restricted access, isolated networks, and offline testing capabilities. You can also consider using tools like Minikube, K0s, K3s, or microk8s to create lightweight Kubernetes clusters for local testing before deploying to the airgap environment or Vanilla Kubernetes clusters in airgap environments.

Use simulation tools like Kind or K3d to create lightweight Kubernetes clusters or virtual clusters for local testing. These tools allow you to simulate airgap conditions and test your applications in a controlled environment before deploying them to production.

8. Overburdened DevOps Teams

In airgap environments, the responsibility for managing Kubernetes often falls entirely on the DevOps team. This can lead to burnout, delays, and increased errors as the team becomes a bottleneck for every deployment or update.

Solution

Empower your development teams to take on more responsibility by adopting a self-service model for Kubernetes management. This can be achieved by providing clear guidelines, templates, and automation tools that allow developers to handle deployments without requiring constant oversight from the DevOps team.

Culture is key. Encourage a culture of collaboration and shared responsibility, where every team member is empowered to contribute to the success of the project. By fostering a culture of ownership and accountability, you can distribute the workload more evenly and prevent burnout among your DevOps team.

9. Misaligned Metrics

In an airgap setup, teams may focus on the wrong metrics, such as deployment speed, rather than more critical factors like uptime, security, and system stability. This misalignment leads to poor decision-making and missed opportunities for improvement.

Solution

Reevaluate your success metrics to align with the specific needs of your airgap environment. Focus on operational resilience, security compliance, and system availability, rather than speed of deployment or other metrics that might be more applicable in non-airgap setups.

Here are some strategies to consider:

• Service Level Objectives (SLOs): Define clear SLOs for your Kubernetes clusters, focusing on availability, performance, and security. Use these metrics to guide your decision-making and prioritize improvements that align with your organization's goals.
• Key Performance Indicators (KPIs): Identify KPIs that reflect the health and performance of your Kubernetes clusters, such as uptime, response time, and security compliance. Regularly monitor these metrics and use them to inform your decision-making and improvement efforts.
• Create chaos: Use tools like Chaos Mesh, Litmus, or Gremlin to simulate failures and test the resilience of your Kubernetes clusters. By introducing controlled chaos into your environment, you can identify weaknesses and improve your system's reliability and availability.

10. Forgotten Dependencies

In an airgap environment, it's easy to overlook key dependencies when creating containers for deployment. Missing a crucial library or package can lead to significant downtime, especially when updates or patches need to be applied manually.

Solution

You can use detailed manifests and dependency management tools to make sure every required library and package is bundled with your container images. Creating comprehensive SBOMs and automating the packaging process ensures that nothing is left out of your airgap environment.

Use tools like K1s airgap to manage dependencies and ensure that your container images are complete and up to date. By automating the bundling and distribution process, you can reduce the risk of missing dependencies and improve the reliability of your deployments.

Airgap Challenges Are Solvable

While airgap environments present unique constraints, these challenges are surmountable with the right approach. By identifying common Kubernetes anti-patterns and adopting targeted solutions, your team can avoid the pitfalls that often slow down progress and lead to security vulnerabilities. It's time to rethink how you approach Kubernetes in airgap environments; streamlining workflows, improving security, and automating processes will make all the difference in ensuring your operations run smoothly and efficiently.

What anti-patterns have you experienced in airgap environments? Share your thoughts and solutions below—let's keep the conversation going!

Go Rebels! ✊🏻

Containers are all about efficiency—small, lightweight, and quick to start. But this focus on minimalism comes with trade-offs. One of the most significant challenges that often catches people off guard is the complexity of performing simple tasks, like transferring files between pods or external systems that are not part of the container orchestration. Examples include logs, generated data files for machine learning models or troubleshooting, or configuration files that need to be shared across multiple pods.

Lightweight Containers, Heavy Frustrations

When you're working with virtual machines (VMs), transferring files is usually a breeze. Tools like scp or ftp are readily available and make it easy to move data from one place to another. But in the world of containers, especially those built with minimalistic images, these conveniences are stripped away.

Why? Because these tools add weight to the container. And in a containerized environment, size matters—a lot. Every extra megabyte can slow down the startup time, increase the attack surface, and make scaling more cumbersome. So, in the name of efficiency, many container images leave out non-essential utilities, including those that make file transfers easy.

But what happens when you need to transfer files between pods? This is where the frustration sets in. Without scp or similar tools, you're often left scratching your head, trying to figure out how to get your files from point A to point B without compromising the lightweight nature of your containers.

The Common Workaround: A Two-Step Process

One common workaround involves copying the file from the source pod to your local machine, and then from your local machine to the destination pod. It's a clunky, time-consuming process that feels like a step backward in a world where automation and efficiency are king.

But this two-step process quickly becomes a bottleneck, adding unnecessary complexity and slowing down your pipeline.

A Solution: Streamlining Pod-to-Pod Transfers

Fortunately, there are solutions to this problem that allow you to maintain the efficiency of your containers without sacrificing functionality.

1. Using Kubernetes Volumes: One of the most straightforward solutions is to leverage Kubernetes volumes. By attaching a shared volume to multiple pods, you can enable them to read and write to the same storage, effectively bypassing the need for direct pod-to-pod transfers. While this approach works well for certain use cases, it might not be ideal for temporary or small-scale transfers.

2. Kubernetes Jobs and Init Containers: Another approach is to use Kubernetes Jobs or Init Containers. You can create a Job or Init Container with the necessary tools for the file transfer, perform the transfer, and then clean up afterward. This method ensures that your main application containers remain lean, while still allowing for more complex operations when needed.

3. Custom Scripts and Tools: If you need a more dynamic solution, consider writing custom scripts that use kubectl cp or even third-party tools designed for this purpose. These scripts can be triggered as part of your pipeline, automating the transfer process while keeping your containers streamlined.

4. Service Mesh Integration: For those looking to go a step further, integrating a service mesh like Istio can help manage and automate communication between pods, including secure file transfers. This approach requires more setup and knowledge of service mesh architectures but offers a robust solution for complex environments.

The Path Forward - A Simple Solution with curl and tar

Are these solutions still too complex for your needs? I got you covered. Here's a simple solution that can help you transfer files back and forth to external systems with SSH access without additional tools or complex configurations, by simply using curl and tar.

Step 1: Create a Tarball

First, create a tarball of the files you want to transfer. You can do this by running the following command in the source pod:

tar -czf - /path/to/files > files.tar.gz

This command creates a compressed tarball of the files you want to transfer, zipping is optional but recommended to reduce the size of the transfer.

Step 2: Transfer the Tarball - Achieving SFTP-like functionality with curl

Here's how you can upload and download a file using SFTP with curl:

Uploading a File with SFTP

curl -u <USERNAME>:<PASSWORD> -T <PATH_TO_FILE> sftp://<SFTP_SERVER>/<REMOTE_DIRECTORY>/<TARGET_FILE_NAME>

• -u <USERNAME>:<PASSWORD>: Your SFTP credentials.

• -T <PATH_TO_FILE>: The file you want to upload.

• sftp://<SFTP_SERVER>/<REMOTE_DIRECTORY>/<TARGET_FILE_NAME>: The SFTP server URL, along with the remote directory and the target file name where the file will be uploaded.

Downloading a File with SFTP

To download a file using SFTP with curl, use the -O option.

curl -u <USERNAME>:<PASSWORD> -O sftp://<SFTP_SERVER>/<REMOTE_DIRECTORY>/<FILE_NAME>

• -u <USERNAME>:<PASSWORD>: Your SFTP credentials.

• -O: Saves the file with its original name.

• sftp://<SFTP_SERVER>/<REMOTE_DIRECTORY>/<FILE_NAME>: The SFTP server URL and the path to the file you want to download.

Example Commands:

• Upload Example:

curl -u user:password -T /local/path/to/file.txt sftp://example.com/remote/path/file.txt

• Download Example:

curl -u user:password -O sftp://example.com/remote/path/file.txt

Notes:

• Make sure the curl version you are using is built with SFTP support, as not all curl versions support SFTP out of the box.

• If you need to specify a different port (other than the default port 22 for SFTP), you can do so by appending :port_number to the server address like sftp://example.com:2222/path/to/file.txt.

This approach lets you handle basic SFTP operations directly from the command line using curl. While it might not be as feature-rich as dedicated SFTP clients, it provides a simple and efficient way to transfer files without the need for additional tools or complex configurations.

Embrace the Challenge

It's easy to get frustrated when something as seemingly simple as transferring a file becomes a challenge. But it's important to remember that the limitations of containerization are a byproduct of its strengths. The very reason containers are so powerful—lightweight, efficient, scalable—is also why they sometimes feel restrictive.

In the container world, size truly does matter, but so does creativity. The limitations you face today are opportunities to innovate and streamline your processes. By understanding the pain points and exploring the solutions available, you can keep your containers lean, mean, and ready to scale—without getting bogged down by the small stuff.

So, the next time you're faced with the challenge of transferring files between pods, remember: there's always a solution that keeps your containers efficient and your workflow smooth. Embrace the challenge, and you'll find that even in the smallest containers, you can pack a powerful punch.

Happy containerizing, Go Rebels! ✊🏽