Architecture context for your AI-DLC
Give your agents context about your architecture.
In the AI-driven development lifecycle (AI-DLC), agents plan, design and write your software. Without context, they don't know what a change touches, who owns it or why it was built that way. EventCatalog gives them that context.
Works with
Claude
OpenAI
Cursorany MCP client
ClaudeEventCatalog connectedEventCatalogshowResource
Orders Service accepts PlaceOrder and listens for PaymentTaken. It publishes OrderCreated and OrderCancelled, which Fulfilment and Notifications consume.
Trusted by teams at
Ask how it works. See it in the chat.
Ask Claude how a service works and EventCatalog draws it right in the conversation: the same interactive diagram your catalog shows, built from your docs, not guessed by the model.
Clients that support MCP Apps render the EventCatalog visualiser inline. Others get the diagram as Mermaid.
Click a service or message to ask about it. The question goes back to the chat, and the agent answers from your catalog.
Ask for a message's schema and it opens in the same viewer as the Schema Explorer, with the source and a searchable list of properties.
Open the same diagram in EventCatalog to explore the docs, schemas and owners behind it.
ClaudeEventCatalog connectedEventCatalogshowResource
Orders Service accepts PlaceOrder and listens for PaymentTaken. It publishes OrderCreated and OrderCancelled, which Fulfilment and Notifications consume.
One MCP server. Every agent grounded in your architecture.
Every EventCatalog ships with an MCP server. Agents get tools that understand your architecture, so answers come from real relationships, not guesses.
Find anything
getResourcesServices, messages, flows, domains and ADRsfindResourcesByOwnerEverything a team or person ownssearchCustomDocsFull-text search across your own guides and runbooksFollow the relationships
getConsumersOfMessageEvery service that consumes a messageexplainBusinessFlowA business flow, step by stepshowArchitectureDiagramAn interactive diagram, right in the chatChange safely
analyzeChangeImpactWho breaks if a message changesgetSchemaForResourceOpenAPI, AsyncAPI and other schemasexplainUbiquitousLanguageTermsThe language each domain usesGive each team’s agent its own domain.
Connect an agent to a single domain or system. It gets that part of your architecture and everything it connects to, and nothing unrelated. Copy the URL from any domain or system page.
The agent reasons over one team’s part of the architecture, not the whole map, so there is less noise and less to get wrong.
Give a team, a partner or a contractor one domain or system instead of the entire catalog.
The URL tracks the latest version of the domain, or pins the version you are viewing.
Use this URL to connect an MCP client to this domain: Payments.
https://your-catalog.com/docs/mcp/domains/paymentsCopyCopiedThe agent sees
Payments domain
PaymentService and FraudService
Every message they send and receive
The Refunds flow
Decision records for Payments
Left out
Marketing, Identity and Search
Services Payments never talks to
Agents that know why, not just what.
Diagrams and schemas show what your architecture is. Architecture decision records show why it is that way. Link each decision to the services, messages and domains it affects, and agents read it before suggesting a change that undoes it.
Confirm payments with events, not callbacks
Context. Checkout waited on the payment provider and failed whenever the provider was slow.
Decision. PaymentService publishes PaymentTaken. Checkout reacts to the event instead of waiting for a callback.
Consequences. Checkout stays up when the provider is slow. Payment status is eventually consistent.
›Can Checkout call PaymentService directly to confirm a payment? It would be simpler.
EventCatalog MCP · reading decision records for PaymentService
That would reverse an accepted decision. Confirm payments with events, not callbacks applies to PaymentService and PaymentTaken: Checkout used to fail whenever the payment provider was slow.
If a direct call is still the right move, it needs a new ADR that supersedes this one. Want me to draft it?
›Yes, draft it.
+ adrs/direct-payment-confirmation/index.mdx
status: proposed · supersedes: confirm-payments-with-events
Agents that write your docs, too.
Install the EventCatalog skills and your coding agent learns how a catalog is structured. Ask it to document something and it writes the files the way EventCatalog expects, ready for you to review.
›
- Scanned src/: 3 services, 7 message handlers
- Asked you 3 questions about domain boundaries
- Wrote a plan for you to review
- Handed off to catalog-documentation-creator
›Ask your agent to document something…
your-catalog/3 changed
domains/
Shipping/+
index.mdx+
services/ShipmentService/+
index.mdx+
events/ShipmentDispatched/+
index.mdx+
EventCatalog Agent works out which docs a code change affects, updates them, and opens a pull request to your catalog for review.
Ask questions inside the catalog.
EventCatalog Assistant is AI chat built into your catalog, so anyone can ask how something works without leaving the docs or waiting on a Slack thread.
It answers from the catalog you have documented and links back to the pages it used.
Connect Anthropic, OpenAI or another provider through the AI SDK.
Give it live data, like service health or on-call rotas, alongside the docs.
Your architecture stays yours.
Your catalog, your infrastructure, your model. Nothing about your architecture has to leave your network for agents to use it.
The MCP server and Assistant run inside your EventCatalog, on your infrastructure.
Use Anthropic, OpenAI or another provider. Your keys, your choice.
Put the MCP server behind your identity provider before agents can connect.
Connect your first agent today.
Point Claude, Cursor or any MCP client at your catalog in a few minutes. Free for organisations under $10M.