Why OpenBindings?
Every service does things. OpenBindings gives those things a name, a shape, and an identity that's independent of how you access them. That's the foundation for everything else: discovery, compatibility, interoperability, and tooling that works across protocols.
Services don't have identities
An OpenAPI spec describes a REST API. A proto file describes a gRPC service. An MCP server describes tools. Each format knows one protocol. None of them answer the question: what does this service do?
Without a protocol-independent identity, services can't be compared, discovered, or composed generically. Two services that do the same thing look completely different because one is described in OpenAPI and the other in protobuf. A tool that works with REST APIs has to be rewritten for gRPC. An AI agent that can call MCP tools can't call a REST endpoint without custom glue code.
This isn't just a multi-protocol problem. Even a single-protocol service benefits from having an identity that tools can discover, check for compatibility, generate clients from, and expose through other interfaces without protocol-specific logic.
What OpenBindings does
OpenBindings gives every service a portable identity: its operations. An operation is a named unit of capability with input and output schemas. Operations are protocol-independent. They describe what a service does, not how.
Bindings connect operations to protocols. createOrder is
a POST /orders in OpenAPI, a CreateOrder RPC in gRPC, and a create_order tool in MCP. The bindings reference the spec files you
already have. OpenBindings doesn't replace them; it unifies them under one contract.
Once a service has an OpenBindings interface, it becomes discoverable
(/.well-known/openbindings), comparable (structural compatibility
checking), composable (role interfaces that any service can satisfy), and instantly
accessible from any tool that speaks the protocol-agnostic execution model.
What you get
Discovery
Any service can serve its interface at /.well-known/openbindings.
Tools discover what a service does without prior configuration or documentation.
Compatibility
ob compat compares two interfaces structurally. Two services that
have never heard of each other can be checked for compatibility automatically.
Interoperability
Role interfaces like openbindings.host define shared contracts.
Any service that conforms to a role is interchangeable with any other. Duck
typing for services.
Protocol-agnostic execution
ob op exec interface.json getMenu works whether the binding is
REST, gRPC, MCP, or GraphQL. Same command, any protocol.
Typed client generation
ob codegen generates TypeScript or Go clients with a typed method
per operation. One interface, one client, any transport.
Instant MCP
ob mcp ./interface.json exposes every operation as an MCP tool.
Any API becomes available to AI agents without writing adapter code.
How it compares
| OpenAPI | Protobuf/gRPC | MCP | AsyncAPI | OpenBindings | |
|---|---|---|---|---|---|
| Describes REST APIs | Yes | No | No | No | Via binding |
| Describes gRPC services | No | Yes | No | No | Via binding |
| Describes MCP tools | No | No | Yes | No | Via binding |
| Describes event streams | Partial | Partial | No | Yes | Via binding |
| Standardized discovery | No | No | Partial | No | Yes |
| Structural compatibility checking | No | No | No | No | Yes |
| Role-based interoperability | No | No | No | No | Yes |
| Multiple protocols in one doc | No | No | No | No | Yes |
OpenBindings doesn't replace these specs. It references them. Your OpenAPI doc, proto files, and MCP server definitions stay exactly as they are.
When it matters most
OpenBindings is useful any time you want services to be discoverable, comparable, or composable. That includes single-protocol services: a REST API with an OBI gets discovery, compatibility checking, typed codegen, and instant MCP exposure for free.
It matters most when services need to interoperate across teams, protocols, or ecosystems without prior coordination. If two teams independently build services that satisfy the same role interface, those services are interchangeable. No shared code, no shared deployment, no shared anything except the contract shape.