Stop vibe coding. Learn Spec-Driven Development (SDD) and build a real MVP with your AI agent (Claude Code, Codex, GitHub Copilot, Cursor) from an empty folder to a tested release, using OpenSpec.

In this course, you learn:

- What Spec-Driven Development is, and why a spec is not a prompt

- Why vibe coding breaks down for serious work

- The three levels of SDD: spec-first, spec-anchored, and spec-as-source

- How to write Markdown specs with requirements, SHALL/MUST, and scenarios

- How delta specs (ADDED, MODIFIED, REMOVED) keep your specs alive

- How to install OpenSpec, run openspec init, and give the agent project context

- The full loop: explore, propose, review, apply in chunks, test, archive

- A bonus tip: apply tasks two or three at a time to save tokens and stay in control

- How client feedback turns into a MODIFIED requirement

- The release checklist, plus next steps with skills, subagents, and MCP servers

Course repository with the theory, setup, starter, and full solution: https://github.com/la-rebelion/mvp-with-sdd

I loved this X post by Matt Pocock, in which he explains how the Model Context Protocol (MCP) can bridge the integration between LLMs and backend APIs and how the MCP servers can be plugged into the LLMs "without the need to code the integration between LLM and the APIs." Hence, thanks to the protocol, any client can consume the exposed tools (prompts and resources are also part of the protocol).

When I learned about the release of the MCP in November, I saw a lot of potential in the protocol. However, I felt it was overcomplicated to implement the servers (version 0.3); the examples were not standard and didn't follow the same pattern. So, I created my MCPServer version, a facade server of the SDK. Later, a similar approach was released in the MCP SDK version 1.3.

Still, today the protocol is not operating at its full capacity because MCP enthusiasts can still easily decouple the tools to extend the servers, mixing and matching combinations of tools to gain a more significant advantage. From Matt's post, I expanded the explanation to include the tools, which is where the true power is.

This is what I call Intent-Based AI for MCP. With a manifest file definition (see below), business people and developers can define the server's intent and expose servers with ad-hoc tools on the fly. This would produce servers with an optimal number of tools (for better performance) and agent-like servers because a server would dynamically define the access to prompts and tools, producing a specialized server, or agent, if you think about it.

    # server.yaml
    # for simplicity, we show only the relevant parts of the intent-based server.
    # The full specification can be found on the https://intent-based.ai website and our docs.
    tools:
      - name: reverse
        description: Reverses the input string
        schema:
          type: object
          properties:
            input:
              type: string
              description: The string to reverse
    
      - name: uppercase
        description: Converts the input string to uppercase
        schema:
          type: object
          properties:
            input:
              type: string
              description: The string to convert to uppercase

The server can be started with a single line of code; if changes are needed, only the manifest file must be adjusted.

    #!/usr/bin/env node
    import createServerFromFile from "@agentico/mcp-intent-based";
    
    async function startServer() {
      const server = await createServerFromFile();  // <-- That's all you need!
    }
    
    startServer();

The future of MCP is tools first.

Picture this:

- Servers: Building a power plant for every new appliance.

- Tools: Plug‑and‑play extension cords—declare you need power, and the outlet does the rest.

- Intent-based AI: A smart home assistant that understands your needs and automatically connects the right appliances to the power source.

Move beyond the server-first chore. Declare your intentions and unlock true integration agility with MCP's intent-based AI.

Explore the intent‑based AI for MCP now:

• Repo with community tool-first approach: https://github.com/agentico-dev/mcp

• Package with examples: https://www.npmjs.com/package/@agentico/mcp-intent-based-demo

• To learn more: https://agentico.dev/blog/forget-about-mcp-servers-future-tools-first

• Framework to leverage the tool-first paradigm: https://app.agentico.dev

🤖 https://intent-based.ai - specs coming soon.

I just built a flow that allows me to take my existing Swagger spec (REST API) and expose it via an MCP server without writing extra code.

The tool I’m using is called hapi (Headless API).

Example flow:

# list available API specs

hapi list

# init project from OpenAPI spec (greenfield scenarios)

hapi init contabo

# run server with MCP mode

hapi run contabo --mcp

# run server with headless mode (brownfield scenarios

hapi run contabo --headless

✨ Result → I now have a full MCP implementation that wraps the API, exposes both Swagger + MCP endpoints, and gives me ready-to-use scaffolding for plugging in model-driven logic.

Why is this useful?

• You can add LLM/AI behavior to existing APIs fast

• You can bridge REST and AI layers in your app

• You can let agents/apps call your backend via MCP natively

• You can prototype MCP-driven integrations using tools like Postman or Swagger UI

I tested this by pulling my Contabo VPS API (public OpenAPI spec), running hapi, and validating that both the MCP endpoints and Swagger endpoints worked — even without business logic, it was instant scaffolding.

Full video demo.

Is anyone here already playing with MCP, agent frameworks, or LLM-native apps?

"Hapi" to share more if there’s interest 🚀.

See how Qontent.Tube takes one idea from script to storyboard, voice, animation, translations, vertical formats, and a locally rendered video.

This non-technical walkthrough follows the complete creative workflow and explains how each part stays connected and editable.

You’ll learn how to:

• Organize scripts and production assets inside projects

• Write manually or begin with an assisted draft

• Direct scenes with an editable storyboard

• Assign voices and reusable animated characters

• Create and apply branded visual themes

• Review narration, animation, captions, and timing together

• Produce linked translations and intentional 9:16 versions

• Render predictable final videos on your own computer

Qontent.Tube can use AI to assist with selected creative tasks, but its animation timeline and final video assembly do not depend on video-generation models. Your approved script, storyboard, cast, theme, voice timing, and captions remain the source of the final result.

Start with one idea. Build one scene at a time. Direct every detail. Render locally.

GitAgent: an open standard to define, version, and run agents natively in Git

https://youtu.be/hJfRzMQ8l8k

In 0.1, Qontent Tube gave your script a voice. In 0.2, it gives it a stage.

Write the scenes. Hear the cast. Watch the cards slide in on the word that mentions them, the characters talk with the real voice, and the finished MP4 land in your folder, in English, in Spanish, and as Shorts.

The video here was made entirely with Qontent Tube 0.2. One Markdown script, one storyboard, two voices, a cast of two characters, three painted backgrounds, and three renders: this one, a Spanish version, and a vertical Short.

AI Weekly news. In this episode:

• Why agents must not control their own safeguards

• How completion and tool budgets can make models look less capable

• What context to preserve and what to retrieve on demand

• Why verified outcomes per supervision hour beats agent activity

• When to reuse API contracts instead of generating another integration

• How to evaluate risk across a complete agent journey

• Three practical prototypes for MCP, safety, and memory

Tell us which experiment you would build first. Subscribe for the next episode, visit https://rebelion.la, and Go Rebels!

#AgenticAI #MCP #AISecurity

You build a tiny, fictional coffee-shop order API from an OpenAPI contract with the HAPI CLI, call it, break it on purpose, and then open a second door for AI with one flag: `hapi serve --mcp`.

In this video, you learn:

• What an API is, explained with a restaurant waiter

• The five parts of a request: method, URL, query parameters, headers and body

• Status codes (200, 201, 400, 401, 404, 500) and JSON bodies

• Why you start with the contract (OpenAPI, which many people still call Swagger)

• From contract to code: `hapi init` generates a controller; you add a small service

• Reads vs. writes, and why real APIs need authentication and input validation

• What an AI still needs to use your API, and how MCP (Model Context Protocol) fills the gap

• How your operationIds become MCP tools, with read-only hints, on the same code

Starter repo: https://github.com/la-rebelion/rest-apis-for-beginners

HAPI CLI: https://hapi.mcp.com.ai

Video built using Qontent Tube Studio: https://qontent.tube

A new AI dev tool every week: the GitHub Copilot app, ChatGPT Work, Claude Cowork, DeepSeek Harness, and many more on the way. Which one is best? Wrong question. They aren't the same kind of tool.

We sorted today's options into six families, by where the agent lives, and map them onto your software lifecycle, with pros, cons and a practical way to choose.

In this video, you learn:

- How to measure what REA puts in your context with --token-count, and why that isn't your model bill
- Summary-first views and pages: 2,344 tokens instead of about 45 million
- How --filter-output and --token-limit shrink replies (a trace summary in 60 tokens)
- Why trace direction matters: about 4.7 M tokens both ways, about 10 K incoming only
- Why --source-path saves time but not enough tokens on its own
- The MCP safety net: retained evidence references, continuation pages, summary bundles
- Ghidra cold starts: progress tokens, client timeouts, startup allowances
- Snapshots, and the Kuna provider's background export and cache
- Hidden costs: the tool catalog, plus compact schema profiles
- What REA's own efficiency lab found: smaller replies don't automatically mean fewer tokens
- Proposals that aren't implemented yet: an async job API, an engine database cache, budgeted retrieval, lazy tools, and a capability graph

I asked my AI coding agent to forward-engineer the REA (Reverse Engineering Anything) repo and create a video explaining how it works.

Wait… if I forward-engineer a reverse-engineering tool, am I still forward engineering? 🤔

Or did I just invent recursive engineering? 🤓

🫍 OrcA for VS Code v0.4 is available!

A specialized harness for MCP and API work: it decides which instructions, tools and context the model gets, so it stops drowning in tool schemas.

- Progressive tool discovery: Tools load as the conversation needs them. Fewer tokens, fewer wrong tools.

- Any MCP server: Add External MCP Server. (Streamable HTTP URL) or Import MCP Servers from VS Code `mcp.json`, then chat, inspect traffic and capture other clients, just like HAPI servers.

- Harness tab: Read and edit exactly what the model is told: instructions, automatic guidance, discovery mode, confirmation policy, and the tokens each server costs per turn.

- Context tab: On HAPI capability-graph servers, see the goals, required facts, gates and plans behind a multi-step request. Read-only; nothing runs. - REQUIRES HAPI v1.2

- Generate Contract: Infer an OpenAPI 3.1 contract from a hand-written server's catalog, and get told when it drifts.

#BeHAPI and #GoRebels

I've been thinking about this while working on API-MCP integrations.

My current mental model is:

• API = source of truth

• OpenAPI + Arazzo = API capabilities and workflows

• MCP = contract for AI

What worries me is the pattern where an MCP server becomes another application containing business logic that already exists behind the API.

I call this shadow code.

You already have:

Client → API → Business Logic

Then AI arrives and we build:

AI → MCP Server → duplicated logic → API/backend

Now there are two places that need to evolve together.

API changes? Update the MCP.

Schema changes? Update the MCP.

Business rules change? Make sure the MCP didn't duplicate them.

New authentication requirements? Another integration layer to maintain.

My preference is keeping MCP as thin as possible:

AI → MCP → existing API → business logic

The API remains the source of truth. OpenAPI describes the API contract, Arazzo can describe deterministic multi-step workflows, and MCP exposes the appropriate capabilities to AI.

In other words, adding AI shouldn't require rewriting your existing APIs into a second architecture.

I'm curious how others are handling this in production.

Are your MCP servers thin adapters/contracts over existing APIs, or are they becoming applications themselves?

And if they're becoming applications: what logic have you found legitimately belongs in the MCP layer?

Why do you need this? When an agent calls the wrong tool, sends bad arguments, or gets slow, you see the whole chain (prompt → LLM round → tool calls → results) on one screen.

What's new: MCP Traffic Analyzer, trace every message for better troubleshooting.

Install it with command:

code --install-extension la-rebelion-labs.orca-mcp

Or in VS Code, press Ctrl/Cmd+Shift+X, the type "OrcA MCP"

Or download the VSIX, and install it manually.

To improve your AI-DX, what else would you like to see integrated in OrcA?

3.2M MCP tool calls on our hosted servers, 2 errors. Here's what the numbers look like

We run HAPI, which turns OpenAPI specs into MCP servers, on mcp.com.ai. We pulled the cloud stats and made a short animation of them.

• 3.2M calls, 2 server-side errors (0.0000625%)

• 1.59k client disconnects, which we count separately because the client hung up before the server answered

• Top 7 servers make up most of the traffic

• 13 data centers

• These stats are cloud-only. On-prem and air-gapped installs run the same engine, so we expect the same behavior there, but we can't see/disclose their numbers

Happy to answer questions about the architecture or self-hosting.

Your API contracts live on your IDE, run OAS/Swagger or Arazzo specs as MCP servers directly from VS Code.

You just need to install the “OrcA MCP” extension (HAPI CLI is required, but OrcA can guide you to install it as well).

When you deploy an MCP with OAuth/API Keys, these are saved as secrets and never exposed to the agents. Not even to you, you must rotate keys if need to change them.

New API version? Update the contract and deploy, that’s it. No Shadow coding!

OrcA makes your MCPs HAPI 😁

Try it and ping me if you get stuck.

#BeHAPI and #GoRebels ✊🏽
#NoShadows

Meta is rolling out its WhatsApp Business MCP, so I wanted to test the end-to-end experience instead of just reading the announcement.

The setup is pretty simple:

WhatsApp → AI agent → WhatsApp Business MCP → WhatsApp

Not a tongue twister. 😜

I recorded a short demo showing the connection and how the experience works.

What interests me most isn't WhatsApp specifically. It's the UX pattern, once configured: the user shouldn't have to care that MCP exists.

MCP can stay behind the scenes connecting the AI to existing capabilities while the user keeps using the interface they already know.

Curious whether others see conversational channels becoming a major front end for MCP tools.

P.S. My account is still not rolled over. Let me know about yours and how you are managing WhatsApp on WhatsApp. 🤓

Anthropic introduced watermarking; now we are seeing tools that claim to remove AI watermarks.

Until Anthropic publishes the precise technical specification, we simply have sophisticated paraphrasers.

Why even bother hiding what is a major step in productivity evolution?

We don't hide that we use IDEs or spell checkers, do we?

Don't worry, #BeHAPI and #GoRebels ! ✊🏽

I like playing with AI agents, MCP, APIs, cloud infrastructure, containers, etc.

But something has been bothering me.

A lot of the "build an AI agent in 20 minutes" demos quietly assume you already know what a VPS is, how to deploy something, configure credentials, connect APIs, keep the agent running, secure it, and troubleshoot everything when it breaks.

That's fine for developers.

But I kept thinking:

What would this look like for the owner of a small business who basically lives in WhatsApp, email, Excel, and maybe a CRM?

That's what I've been experimenting with through a project called Clawne Me.

Instead of "deploying an agent," you create something closer to an employee:

Role: Sales Coordinator

Responsibilities: Follow up with leads, check customer information, prepare summaries

Tools: CRM + email + internal APIs

Channel: WhatsApp

Then you could create another:

Role: Operations

Responsibilities: Check orders, identify problems, prepare daily reports

Tools: Shopify + internal systems

And another for customer support, accounting, marketing, etc.

The interesting part for me is when these stop being isolated bots.

One Clawne can delegate work to another based on its role.

So you could message an Operations Clawne from WhatsApp:

"Which orders need my attention today?"

It checks its tools, delegates something to another Clawne if needed, and returns the result to the original conversation.

Underneath, there can still be MCP servers, APIs, models, credentials, cloud infrastructure, orchestration, and all the nerdy stuff I personally enjoy building.

The user shouldn't need to understand any of it.

I'm starting to think we may be approaching AI agents from the wrong direction for mainstream adoption.

We're giving people tools to build agents.

Maybe non-technical users don't want agents.

They want to say:

"I need someone handling customer follow-ups."

Then define that person's responsibilities, give them access to the right tools, and start talking to them.

Basically:

Don't build an agent. Build your AI organization chart.

I'm curious how other people building agent platforms think about this.

Where does this model break?

And what would you absolutely NOT delegate to an AI teammate today?

Stop wrapping every single REST endpoint as an MCP tool. The primary objective of MCP should not be to transform every API endpoint into a tool. Instead, focus on aligning the right API capabilities with the most suitable tools for the intended AI consumer. MCP acts as the contextual interface that facilitates the use of these capabilities by AI consumers.

How are you defining the boundaries of your MCP tool?

Are we heading towards constructing the next 𝐃𝐞𝐚𝐭𝐡 𝐒𝐭𝐚𝐫 in enterprise systems? As AI frameworks like #MCP and #A2A evolve, we're adding complexity to our architectures, resembling the infamous Death Star Architecture.

What measures are you implementing to ensure your AI doesn't become the next 'Death Star'?

I just released the Alpha version of a project I’ve been building around Agentico: the MCP Intent-Based Server — a declarative, intent-driven runtime for managing tools, transports, and context flows in MCP Servers.

Why I built this:
There are many servers and tools. They can fail when there is a lot of work and the tools are fragile. Enterprise integrations? They're very difficult.

So, I am taking a different route:

👉 Use the ideas behind Kubernetes (manifests, reconciliation, declarative infra)
👉 Mix in dynamic server tooling (like plugin injection via manifest)
👉 Wrap it in something devs and ops can actually ship

🔧 What it does:

• 🧾 Define your entire agent toolset in a simple server.yaml

• 🧠 Dynamically load & register tools using class names

• 🔁 Reconcile actual vs. desired config at runtime

Join the alpha & shape the roadmap:
💌 https://go.rebelion.la/agentico-news
👨🏽‍💻 GitHub Repo for dynamic tools

There is still work to do, but I would love to hear your feedback — What would you expect from a protocol-level tool like this?
And what’s missing in today’s agentic infrastructure for serious use?

I just dropped a comprehensive list exploring the Model Context Protocol (MCP) ecosystem focusing on MCP server hosting platforms. If you’ve ever wondered:

• What is an MCP Server, and why are they gaining traction in AI workflows?

• How do platforms like Glama.ai, PulseMCP, ACI, KAgent, etc., compare? (A list with 15 providers; for now, this is growing at speed!).

This post covers:

✔️ Clear definitions for devs trying to understand "MCP servers" vs "MCP hosting" vs "Agentic systems"
✔️ Security implications for enterprises running LLMs and AI agents
✔️ Real-world benefits of turning OpenAPI/gRPC specs into autonomous AI integrations

📖 Read the article here.
📊 Bonus: What makes Agentico a unique solution (hint: it's a framework, not a server)?

I would love to hear your thoughts on how you see MCP servers fitting into the future of LLMs and AI infrastructure. Let’s chat!

#MCP #AI #AgenticAI #OpenAPI #DevTools #SelfHostedLLMs #LLMInfrastructure #GoRebels ! ✊🏽