Why Charter
An API runtime built for MCP. One config file, one binary, every interface your API needs.
The problem
Most API tools make you write the same thing several times. A new resource means a database model, validation, a route for each operation, a response shape and permission rules, usually copied from the last resource and edited by hand. When a field changes, every copy has to change with it.
Those tools have taken us a long way. They were built for people writing endpoints one at a time, before agents were calling APIs too.
MCP first
Agents now read and write data through APIs as often as people do, and they work best when an API describes itself completely. So we asked what an API would look like if it were designed for agents from the start: MCP first, with REST and a CLI built on the same definition.
Charter is the answer. It is an API runtime built to be minimal and simple to use.
One config file, one binary, one artifact
You describe your resources once, in a single config file: fields, relations, validation and who can do what. Charter reads that file and serves the API. There are no generated models or controllers to keep in step.
The same binary and the same config run in development and in production, and the same artifact is what you deploy. What you test on your laptop is what runs in production.
Built on standards
Charter doesn’t invent its own formats. It follows the conventions your tools and agents already understand:
Every resource returns records, relationships and errors in the same shape.
A spec generated from your config that agents and tooling read directly.
Human-readable docs served alongside the API, for people and agents alike.
One set of resources, three ways in
Charter ships as a CLI as well as a server. MCP, the REST API and the CLI all act on the same resources, so a record an agent creates over MCP shows up in the next API response and in the CLI.
There is nothing to keep in sync, because there is only one copy of your API: the config file.