Skip to content
OpenBindings
Open Standard · v0.1.0

One contract for your REST API, gRPC service, MCP tools, GraphQL endpoint, and whatever comes next.

OpenBindings doesn't replace your OpenAPI doc, proto file, or MCP server. It's a thin contract layer above them that describes your operations once and references your existing specs as bindings. Nothing to rewrite. Nothing to migrate.

OpenBindings
Interface
RESTOpenAPI
MCPTools
gRPCProtobuf
AsyncAPIChannels
GraphQLIntrospection
YoursAny format
Get Started Read the Spec Get the CLI

One file. Any protocol.

{
"openbindings": "0.1.0",
"name": "Task Service",
"tasks.create": {
"input": { "type": "object", "properties": {
"title": { "type": "string" },
"priority": { "type": "integer" }
}},
"output": { "type": "object", "properties": {
"id": { "type": "string" },
"title": { "type": "string" }
}}
}
}
}

Toggle bindings to grow the document.

What you can do today

The ob CLI works with OpenBindings interfaces. Same operation, any protocol:

$ ob op exec https://api.example.com getMenu
{ "items": [{ "id": "latte", "name": "Schema Latte" }, ...] }
$ ob op exec https://api.example.com --binding getMenu.grpc
{ "items": [{ "id": "latte", "name": "Schema Latte" }, ...] }
# same operation, different protocol, same result

Try the demo

A coffee shop across six protocols. One interface.

brew install openbindings/tap/ob ob demo ob op exec localhost:8080 getMenu
Getting started guide

Wrap your existing API

Already have an OpenAPI spec? Get an interface and MCP tools.

ob create openapi.json ob mcp ./interface.json
CLI reference

Generate a typed client

Point at any service, get a typed client in TypeScript or Go.

ob codegen https://api.example.com \ --lang typescript -o client.ts
Codegen docs

How it works

1

Define operations

Describe what your service does: inputs, outputs, schemas. Protocol-free.

2

Add bindings

Reference your existing specs as binding sources. Each binding maps an operation to a ref in an external artifact.

3

Execute anywhere

Clients work with operations. Binding executors handle the transport. The developer never writes protocol-specific code.

Separate meaning from access

Operations define what a service does. Bindings define how you reach it. Change one without touching the other.

Works with any protocol

Binding formats are community-driven. Anyone can create a format token and a binding executor. No gating, no spec changes required.

Deterministic compatibility

Schema-based checks verify two interfaces agree. Tool-independent, CI-friendly, spec-defined. No runtime required.

Shared interfaces

Publish interfaces as roles, like traits in Rust or protocols in Swift. Services declare which roles they satisfy. Clients target the role, not a specific service.

Before and after

Without OpenBindings
  • OpenAPI, proto, and MCP describe the same operations independently
  • Schemas drift silently between specs with no way to verify agreement
  • Client code coupled to a specific transport; switching protocols means rewriting call sites
  • Delegating to another service requires knowing its wire format up front
With OpenBindings
  • Operations defined once as the authoritative contract above your existing specs
  • Spec-defined compatibility checking catches drift in CI
  • Clients target operations; binding executors handle the transport at runtime
  • Define the contract at the boundary, resolve the transport at runtime

See six protocols in one interface.

brew install openbindings/tap/ob && ob demo
Get Started Star on GitHub Join the Discussion