Model Context Protocol server

Your AI, fluent in every Avonni component

Components are the words your AI builds UI with. The Avonni MCP is the dictionary: real attributes, events, styling hooks and interactions, served to Claude, Cursor and any MCP client.

Get the serverExplore LWC Components
8
MCP tools
4
toolsets
Every
component documented
avonni-mcp · session
$list_components
→ avonni-avatar · avonni-dd-datatable · avonni-dd-kanban · avonni-dd-scheduler …
$get_component_docs "avonniAvatar"
→ attributes · events · methods · slots
$get_component_styles "avonniAvatar"
→ CSS styling hooks + default values
✓ real component APIs, nothing invented
The toolkit

Eight tools. The whole component API.

Everything your AI needs to write Avonni code against the source of truth.

Components
4 tools
list_components
Every component in a package, with what it does.
↳
get_component_docs
Attributes, events, methods, and slots for one component.
↳
get_component_styles
The CSS styling hooks a component exposes.
↳
get_type
Resolves complex attribute types down to every key.
Interactions
2 tools
list_interactions
Every no-code interaction for Dynamic and Flow components.
↳
get_interaction_docs
Full properties for a single interaction.
Utilities
2 tools
list_utils
The utility functions shipped with the LWC package.
↳
get_util_docs
Signature and usage for one utility function.
a·von·ni (noun): the vocabulary your AI builds UI with.
Coverage

Rich vocabulary. Rich UI.

Each product line is exposed as its own toolset. Point your AI at the one you build with, or at all of them.

toolset: "lwc"

LWC Components

55+

Code-first components your AI can compose in custom LWC.

Learn more →
toolset: "dynamic"

Dynamic Components

85+

No-code components built in the Component Builder.

Learn more →
toolset: "flow"

Flow Screen Components

70+

Screen components for guided processes in Salesforce Flow.

Learn more →
toolset: "experience"

Experience Cloud Components

40+

Drag-and-drop components for branded Experience Cloud sites and portals.

Learn more →

Also documented: 50+ no-code interactions, CSS styling hooks, and complex attribute types.

Why it matters

Real APIs in, real code out

The headline feature
0

invented attributes

Left on their own, assistants invent words: attributes and events that don't exist. The Avonni MCP hands yours the dictionary instead: real attributes, real events, real styling hooks.

8

MCP tools

The full component API surface, callable by your AI.

50+

interactions documented

Navigate, open flows, update records, all specced.

4

toolsets

One server covers every toolset.

Compatibility

Works with the AI tools you already use

$get_component_docs"avonniAvatar"
→ attributes · events · slots
✓ writing avonni-avatar…
In your terminal or IDE

Claude Code

Add the server and Claude Code writes Avonni markup against the real docs.

Add an Avonni data table
<avonni-dd-datatable>
Using real attributes from the docs
In conversation

Claude.ai & Claude Desktop

Connect the MCP and ask for components, docs, or styling in plain language.

✦Build a pipeline board
avonni-dd-kanban
In the Salesforce toolchain

Agentforce Vibes

Connect the server and Vibes builds Salesforce UI against the real Avonni docs.

1<avonni-dd-kanban
2group-field="Stage"
3>
Everywhere else

Cursor & any MCP client

MCP is an open standard; any client that speaks it can use the server.

FAQ

Questions, answered

What is the Model Context Protocol?

MCP is an open standard that lets AI assistants call external tools. The Avonni MCP server exposes eight tools that document every Avonni component.

Which AI tools can use it?

Any MCP client: Claude Code, Claude.ai, Claude Desktop, Cursor, and more. If it speaks MCP, it can use the server.

What does it cover?

Four toolsets: LWC Components (lwc), Dynamic Components (dynamic), Flow Screen Components (flow), and Experience Cloud Components (experience), plus their interactions, styling hooks, and complex attribute types.

Why not just let the AI write the code?

Without documentation, assistants tend to invent attribute names and events that don’t exist. The server keeps generated code aligned with the real component APIs.

Does it write code for me?

No. It documents. Your AI assistant does the writing; the server makes sure it writes against real APIs.

Why a library in the AI era

One line, not a thousand

If an assistant can write any component from scratch, why buy a component library at all? Because generated code is owned code.

AI from scratch

Ask an AI for a Kanban board and it produces thousands of bespoke lines: markup, drag-and-drop logic, CSS, edge cases. It may even work on day one. But now your team owns a codebase nobody wrote, debugs it, keeps it accessible, and re-adapts it three releases a year. Multiplied across an org, AI velocity quietly turns into ungoverned technical debt.

AI + Avonni

The same request resolves to one line: a reference to the Avonni Kanban component, plus its configuration. The thousands of lines still exist, but they live inside the managed package: built, tested, accessibility-checked, security-reviewed through AppExchange, and upgraded with every release.

Give your AI the Avonni docs

Connect the MCP server and ship Avonni UIs with code that references real components.

Explore LWC ComponentsRequest a Demo