Findings Changelog Read Spec
Two steps. That's it.

Document your API.
Let AI agents use it.

After you build an API, tell Claude Code to document it using Markdown API format and publish it. For any project that needs to use the API, point Claude Code at the published MAPI page. That's the whole workflow.

Spec (HTML) Spec (Markdown)

How it works

Step 1

Document & Publish

You built an API. Tell Claude Code: "Document this API using Markdown API format and publish it." Your API is now described in a format that both humans and AI agents can read.

Step 2

Point & Use

In any project that needs the API, point Claude Code at the published MAPI page. The agent reads the spec, understands the capabilities, auth, and constraints, and starts making calls.

Example: Acme Payments API
In the API project:

"Read the MAPI spec at https://markdownapi.org/specs/mapi-specification-v0.95.md, then document the Payments API in /src/api/ using that format."

In any project that needs to call it:

"Read the published MAPI doc at https://acme.dev/acme-payments.md — we'll use it for payments calls later."

Now with Messaging Support

MAPI isn't just for HTTP. Describe APIs built on NATS, MQTT, AMQP, Kafka, Redis Streams, and other message bus infrastructure—all in the same format. One spec covers REST endpoints, WebSockets, and message queues together.

•
Structured lifecycle definitions for message-oriented protocols
•
Envelope schemas and messaging delivery metadata
•
NATS, MQTT, AMQP, Kafka, Redis Streams, and more

Why Not Just Feed It OpenAPI?

You can. But your agent will burn tokens on verbose JSON Schema, miss the intent behind endpoints, and still guess wrong on edge cases. MAPI gives agents what they actually need.

What Your Agent Sees in OpenAPI

  • Verbose JSON Schema — Hundreds of lines describing a single endpoint, burning through the context window
  • No intent signals — The agent knows the endpoint exists but not when to use it or why
  • Fragmented specs — REST in OpenAPI, events in AsyncAPI, messaging nowhere—your agent has to reconcile multiple formats
  • URL-oriented — Organized by paths, not by what the API actually does

What Your Agent Sees in MAPI

  • Lean TypeScript interfaces — Clean type definitions an agent can parse in a single pass
  • Intentions built in — Each capability explains when to use it and when not to
  • Everything in one doc — REST, WebSocket, SSE, NATS, Kafka, MQTT—one format, one context load
  • Capability-oriented — Organized by what your API does, which is how agents think

Claude Code will love you for it

Hand your coding agent a MAPI doc and watch what happens. Intentions tell it which endpoint to pick. Logic Constraints keep it from violating business rules. It stops hallucinating and starts making correct API calls.