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 |
| 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."
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.