Ikanos — Comparison¶
How Ikanos relates to the adjacent tools teams reach for when they want an AI agent to use their APIs. For a feature inventory see Features; for the bigger picture see Spec-Driven Integration.
The three bets¶
Every tool that lets an AI agent reach your APIs makes one of two bets — write code or generate code. Ikanos makes a third: declare a capability in YAML. That reframing is the whole point. The neighbours fall into three segments, each with a different unit of work:
- Agentic coding frameworks — LangChain, LangChain4j, LlamaIndex, Spring AI. You hand-write tools, retrievers, and orchestration in Python/Java.
- MCP server frameworks — FastMCP, Spring AI MCP, the official MCP SDKs. You hand-write an MCP server and its tool handlers.
- MCP proxy generators — Stainless, APIMatic, Speakeasy, Mintlify. One OpenAPI document in, one mechanical 1:1 SDK or MCP server out.
The coding frameworks make you write integration logic, the server frameworks make you write protocol plumbing, and the proxy generators give you a thin mirror of a single existing API. Ikanos collapses all three into a single declarative artifact — and, unlike a proxy generator, one capability can consume and compose several upstream APIs at once (e.g. join a customer from one service with their orders from a second and open tickets from a third), exposing the curated result as one domain-shaped, multi-protocol, governed capability rather than code or a flat passthrough.
Side-by-side¶
| Dimension | Coding frameworks | MCP server frameworks | MCP proxy generators | Ikanos |
|---|---|---|---|---|
| Unit of work | Hand-written code | Hand-written MCP server | OpenAPI → generated wrapper | YAML capability |
| Integration glue (auth, mapping, pagination) | Hand-coded per API | Hand-coded per API | From spec (passthrough only) | Declared once in YAML |
| Output protocols | In-process tool | MCP only | SDK or MCP (1:1) | MCP + Skill + REST from one spec |
| Upstream APIs per unit | Many (you wire them) | Many (you wire them) | One (one spec → one wrapper) | Many — composed in one capability |
| Domain aggregation | Manual | Manual | ❌ endpoint mirror | ✅ DDD aggregate flows across APIs |
| Reviewable as a contract | ❌ code | ❌ code/annotations | partial (the OpenAPI) | ✅ YAML diff + Polychro lint |
| Agent-authorable safely | ❌ fragile code | ❌ fragile code | n/a | ✅ YAML against a stable schema |
| Tool-sprawl control | Manual curation | Manual curation | ❌ 1:1 explosion | ✅ coarse-grained capabilities |
| Survives protocol revisions | Re-write on each MCP change | Re-write on each MCP change | Re-generate on each MCP change | ✅ engine bump — YAML unchanged |
| Cloud-native ops (health, metrics, traces) | DIY | DIY | n/a | ✅ Control Port, OTel, Prometheus, RED |
Interoperate, don't contest¶
Ikanos doesn't try to win every lane — it interoperates with all three:
- it imports OpenAPI (the proxy generators' input),
- it exposes MCP (the server frameworks' output), and
- it plugs into LangChain4j as in-process tools (the coding frameworks' runtime).
The migration story is "keep your runtime, replace your hand-written glue."
Why owning the spec beats owning the server¶
MCP is not standing still. A major, largely stateless revision of the transport is expected to land soon — the kind of change that breaks the wire contract every current server was built against. For anyone holding a hand-built or generated server, that release triggers a forced-march upgrade: the framework ships a new major, and then every custom server on it must be regenerated or hand-migrated, re-tested, and re-deployed — one migration per server.
Ikanos inverts this. The artifact you own is a YAML capability — what you consume, what you expose, what the domain logic is. The MCP transport is an implementation detail of the engine, not of your spec. When the transport revises, the upgrade path is:
Bump the Ikanos engine. Your YAML is unchanged.
One engine release upgrades an entire fleet of capabilities at once, because
nowhere in the spec did the author write transport-level session handling — they
wrote consumes, aggregates, and exposes: type: mcp. Each future MCP
revision is a crisis for whoever owns a server and a non-event for whoever owns
a spec.
When another tool is the better pick¶
Scoping the wedge honestly:
- Reach for a coding framework when you need arbitrary, cyclic agent orchestration in code.
- Reach for a server framework when you need a tiny bespoke MCP server with exotic MCP features.
- Reach for a proxy generator when you genuinely want an exhaustive 1:1 typed SDK of one clean, well-specified API.
Ikanos is the right call when you need governed, multi-protocol domain capabilities that compose several upstream APIs into one capability, stay reviewable as a versioned artifact, and can be safely authored by AI agents.