There’s a gap in how AI development actually works, and nobody talks about it enough.

You build something that works. A summarizer, a classifier, an extractor. The model behavior is good, the prompt is tuned, the output is reliable. And then you spend the next two weeks answering questions that have nothing to do with any of that:

  • How do we call this from the frontend?
  • Can Claude Desktop use this as a tool?
  • Can we run this in a batch pipeline?

The AI part is done. The infrastructure part isn’t. And this infrastructure looks almost identical across every AI project. It just gets rebuilt from scratch each time.

That’s the problem Launchpad is trying to fix.

Define Once, Deliver Anywhere

Launchpad is built around one idea: what if you only had to define an AI capability once?

You write a capability with typed Pydantic inputs and outputs, give it a name and version, and Launchpad handles how it gets delivered. The same capability can be a REST API, an MCP tool that AI agents call natively, or anything else the framework supports—without touching the delivery code.

from pydantic import BaseModel
from launchpad import Capability, capability

class SummarizeInput(BaseModel):
    text: str
    max_length: int = 200

class SummarizeOutput(BaseModel):
    summary: str

@capability(name="summarize", version="1.0")
class Summarize(Capability[SummarizeInput, SummarizeOutput]):
    def run(self, input: SummarizeInput) -> SummarizeOutput:
        ...

From there, serving it over HTTP or as an MCP tool is a one-liner:

from launchpad.adapters.http import HttpAdapter
from launchpad.adapters.mcp import McpAdapter

HttpAdapter(Summarize).serve()   # POST /summarize, GET /docs, GET /health
McpAdapter(Summarize).serve()    # native tool for Claude Desktop, Claude Code, etc.

The request/response schema is derived from the Pydantic models automatically. No duplication.

Configuration via Manifest

Rather than hardcoding adapter settings in code, Launchpad uses a launchpad.yml manifest:

metadata:
  version: "1.0"

spec:
  interfaces:
    http:
      enabled: true
      host: 0.0.0.0
      port: 8080
      route_prefix: /v1

    mcp:
      enabled: true
      transport: stdio

Both adapters read from the same file:

HttpAdapter.from_manifest(Summarize, "launchpad.yml").serve()
McpAdapter.from_manifest(Summarize, "launchpad.yml").serve()

The capability stays untouched. Delivery is just config.

Why This Matters Now

graph TD A[Your Capability\nTyped input + output contract] --> B[HTTP Adapter\nREST API + OpenAPI docs] A --> C[MCP Adapter\nNative AI agent tool] A --> D[gRPC / CLI / Queue\ncoming soon] E[launchpad.yml\nManifest config] --> B E --> C E --> D

The way AI capabilities get consumed is fragmenting fast. A year ago, shipping an AI feature meant wrapping it in a REST API. Today teams are expected to support REST endpoints, MCP tools for AI agents, async queues for batch pipelines, and more.

It’s not the first delivery mechanism that’s expensive—it’s the second and third. The moment someone asks “can we also expose this to Claude Code?”, you’re back to writing plumbing.

Launchpad’s bet is that the infrastructure patterns here are stable enough to standardize. The same way web frameworks abstracted away HTTP routing and connection pooling, there’s an opportunity to abstract away the operational scaffolding that every AI team is rebuilding.

Where It Is Today

Launchpad is at v0.1.2, available on PyPI as launchpad-ai under Apache 2.0. HTTP and MCP adapters are working, with gRPC, CLI, and queue adapters on the roadmap.

If you’re spending more time on delivery infrastructure than on the actual AI work, it’s worth a look. The repo is at github.com/sankalpshekhar14/launchpad.

pip install launchpad-ai
pip install 'launchpad-ai[http]'   # REST adapter
pip install 'launchpad-ai[mcp]'    # MCP tool adapter