The Salesforce UI layer your AI can actually use

Describe the UI. Ship the real thing.

Point your AI tools at the Avonni MCP server and they generate real components with documented attributes, not markup that looks right and breaks on save.

85+
components documented
8
MCP tools
0
invented attributes
claude
$ claude "add a kanban view of open cases to the service console"
Calling the Avonni MCP server...
→ get_component_docs "dcKanban"
Found real attributes: keyField, groupFieldName, query, actions
Generated a dcKanban configured on Case, grouped by Status.
Every attribute exists. Nothing invented.
Why AI plus Avonni works

AI is great at intent, bad at APIs it cannot see

Ask a general model for Salesforce UI and it will confidently invent attributes that do not exist.

The problem is never the intent, it is the reference. Avonni components ship with documented definitions, and the MCP server hands those definitions to your AI at generation time. So the model stops guessing and starts composing from real building blocks, with the exact attributes, events, and data mappings the components actually expose.

Generic AI, no reference
AI + Avonni MCP
Two ways to ship

Whether your AI writes code or clicks

Code-first with LWC
caseBoard.html
<template>
<avonni-dd-kanban
group-field-name="Status"
></avonni-dd-kanban>
</template>

Your AI writes LWC markup with attributes pulled straight from the component docs.

No-code with Dynamic Components
config.json
{
"component": "dcKanban",
"object": "Case",
"groupBy": "Status"
}

Or it produces a builder configuration your admins can open and tweak.

What the MCP covers today

Real docs for four component packages

Code

LWC Components

Documented attributes and events for the LWC package, so AI-written markup compiles the first time.

Learn more →
No-code

Dynamic Components

Component and interaction definitions your AI turns into builder-ready configurations.

Learn more →
Guided

Flow Screen Components

Screen Flow components exposed to your AI, so guided processes get real inputs and data views.

Learn more →
Portals

Experience Cloud Components

Experience Cloud components documented for your AI, so branded portals and sites get built from real, supported building blocks.

Learn more →
Works with your stack

One server, any MCP client

Claude Code

Wire the server into your terminal workflow and generate components in context.

Claude

Connect it in the Claude app and describe the UI you want in plain language.

Any MCP client

MCP is an open standard, so any tool that speaks it can connect to the server.

Four component packages are covered today: LWC, Dynamic, Flow Screen, and Experience Cloud Components.

MCP FAQ

How the MCP server works

Does it work with my AI tool?
If your tool speaks MCP, yes. MCP is an open standard, so any compatible client can connect to the Avonni server, in the terminal or in a chat app.
What does the MCP server expose?
The real documentation for the components: their attributes, events, styling hooks, and interactions. Your AI reads those definitions instead of guessing at an API.
Is my org data involved?
No. The server provides component documentation, not your records. Your AI uses it to generate markup and configuration, which you then deploy to your org yourself.
Which packages are covered?
Today the server documents four packages: LWC Components, Dynamic Components, Flow Screen Components, and Experience Cloud Components. More coverage is on the way.

Give your AI components it can trust

Connect the Avonni MCP server and let your AI build Salesforce UI from real, documented components.