MCP tools reference
When an AI tool connects to UI Rules over MCP, it gets a set of tools. Most read your brand. A few write to it, and each of those needs its own scope on the connection. This page lists all of them, so you can tell what an agent is doing when it reports a call, and so you can grant exactly the access you mean to.
The tools are named the way the agent sees them. You do not call them yourself.
The order the server asks agents to follow
The MCP server carries its own instructions, and a connected agent follows them without you scripting anything. The order is:
get_brand_brief, to learn which brand it is working for: the name, the description, the logo, the root areas, the component library config the brand records, and the project this connection serves.get_project_notes, to pick up what earlier sessions on this project decided.get_rules_index, which returns the map of everything the brand has rules about, with counts but no rule text.- A check on the project's component config. If the project has a
components.json, the agent callsverify_shadcn_configand reads what comes back. If your brand records a config and the project does not match it, the agent is told to stop and say so rather than build lookalikes and carry on. get_design_tokens, for the stylesheet and the canonical values.- Then, per element it builds,
get_rulesfor that area by name, orsearch_ruleswhen it has a concept but no area name. Any user-facing text it writes goes the same way: it loads your content area first.
When the work is done, the server asks for a closing loop:
check_rule_compliance, the final gate. The agent names the areas its work touched, includes the root stylesheet's full text, and reports only the rules it did not follow, each with a reason. Every other rule under those areas counts as followed. The call verifies token delivery server-side and hands back the verdict, the Required rules the agent claimed to follow, and the closing report to give you.report_usage, a self-check of what was applied and what was skipped.save_project_notes, so the next session starts where this one stopped.
The custom instruction the v0 and Lovable guides ask you to paste is that opening order in a sentence, because those tools do not read the server's instructions on their own.
Reading tools
These need only a read scope. A Delivery only key carries all of them.
| Tool | What it does |
|---|---|
get_brand_brief | Who the brand is: its canonical name, description, and logo, the root areas its rules are organized under, the component library config recorded on the brand, and the project this connection serves. No rule text and no counts. The agent calls it when a session starts, and again after a long conversation has pushed the brand out of its context. |
get_rules_index | The index of every area the brand has rules about: each area's exact name, its rule count, and how many are Required. No rule text, so the agent reads it as a table of contents. It can also open one branch to its full depth, listing that branch's rule groups with a count each, and a branch small enough to fit comes back with its rules included. |
get_rules | One area's rules in full, named exactly as the index printed it. A top-level name such as Components serves the whole section, capped. If the project is set to use a saved version, the tool returns that version; live: true reads the latest edits instead. |
search_rules | Rules for a concept the agent cannot name an area for: a focus ring, dark mode, the tone of an error message. Ranked, capped, and honest when nothing matches. |
get_rule | One rule by its id or key, when the agent already has it. |
get_design_tokens | The project's design tokens: the compiled stylesheet first, ready to paste, then the canonical values for reference. The agent has to say which dialect the project uses, css, tailwind-v4, or tailwind-v3, and it is told to read that from the project's own package.json rather than guess. |
check_rule_compliance | The closing gate. The agent declares the files it changed, the areas those files touch, the stylesheet it wrote, and the rules it did not follow with a reason for each; everything else under those areas counts as followed. The call checks token delivery against the canonical export, returns the Required rules the agent claimed to follow, and ends with the report to hand you, which names every departure. Anything left out comes back stamped as unchecked. |
verify_stylesheet | Checks a stylesheet the agent just wrote against the canonical export and returns the exact lines to add or fix. On tailwind-v3 it takes the tailwind.config text too, or only half the delivery is checked. |
verify_shadcn_config | Compares the project's components.json, field by field, against the config recorded on your brand: style, base, base color, icon library, RTL, menu color, and menu accent. It reports the mismatches and says plainly that it has not repaired anything and has not looked at the generated component files. With no config recorded it compares nothing and says so rather than assuming a default. |
export_ruleset | The whole effective ruleset as one Markdown document, for dropping into a repo or reading end to end. |
list_brand_assets | The brand's logo, fonts, icons, images, and documents, each with a permanent URL. This is the only tool that serves the logo. The URLs are download sources: the agent is told to save each file into the project and reference the local path, so the site it builds serves its own copy. Assets belong to the brand, so every project shares them. |
Session tools
These let an agent keep its own working state on a project. They write to UI Rules' own storage, never to your rules or tokens. The Agent sessions scope group grants them.
| Tool | What it does | Scope |
|---|---|---|
get_project_notes | The notes saved by earlier sessions on this project: checklist, conventions, files, memory. | notes:read |
save_project_notes | Saves a note of one kind. Each entry holds the current state of its kind rather than a session log: the newest entry of each kind comes back first, and older ones drop out. | notes:write |
report_usage | A self-check after compliance: what was applied, what was skipped, and why. | usage:write |
send_feedback | A free-text message to whoever runs the design system, for a rule that was ambiguous or a token that was missing. Changes nothing else. | feedback:write |
Without these scopes the session tools fail closed and everything else keeps working.
Writing tools
These change your design system. Each needs its own scope from the Authoring group. A connection made by signing in, or with a key made in one click, carries rule:write, rule_group:write, and token:write; only the one-click key also carries token:import. Every one of them tells the agent to confirm with the user before it writes, because the change takes effect immediately and there is no undo from the tool side (though Version history still has you covered).
Four of them go further and will not write without a confirm code. set_design_token, update_rule, and both imports answer the first call with a preview of exactly what would change and a short code. The agent is told to show you the preview and send the code back only once you approve. The code matches only that exact change: if the arguments differ, or the value it would replace has moved since the preview, nothing is written and the agent gets a fresh preview instead. A code from a project preview does not work for a brand import, which needs its own preview and its own yes.
| Tool | What it does | Scope |
|---|---|---|
add_project_rule | Adds a rule to this project, attached to the node the agent names. It cannot change the brand's own ruleset, and no other project sees it. | rule:write |
update_rule | Changes an existing rule for this project: a different Guidance, Importance, title, or body. A rule the project owns changes in place; an inherited one is customized for this project only, and the brand keeps its own. Withdrawing a field on an inherited rule puts the brand's own value back. Previews each changed field first and needs the confirm code. | rule:write |
add_rule_group | Adds a rule group to this project: a heading that organizes rules within one area, such as Button > Accessibility. It is not an area of its own, and it holds only rules and nested groups. Name an existing group as the anchor to nest one inside it. | rule_group:write |
set_design_token | Sets one token's value for this project, as an override. The brand keeps its own value. Previews the current and proposed value first and needs the confirm code. | token:write |
import_design_tokens | Takes a block of CSS the user pasted and previews the exact writes; writes nothing until the confirm code comes back with the same CSS and scope. Defaults to project overrides. | token:write for the project, token:import for the brand |
import_design_tokens_from_site | Reads a website's tokens into the project (the default) or the brand. Reads only the page at the URL the user gave, unless asked to read more, up to 6 pages on the same site. Previews first and writes nothing until the confirm code comes back; writing scans the site again, and the code matches only while that scan gives the same writes. Scans are rate-limited per organization. | token:import, plus token:write for a project write |
Writing to the brand rather than a project is deliberately the bigger grant. token:import is what lets an import rewrite the canon every project inherits, and it is separate from token:write for that reason.
Granting scopes
In the Connect your AI tools dialog, Create API key makes a key with Full access in one click. Choose permissions offers presets first: Full access, Read only, Delivery only, and None. Signing in instead of pasting a key uses your own key for the project, or makes one with every scope except token:import. Delivery only is enough for serving. Add the Agent sessions group when you want the agent to remember work between sessions, and Authoring only when you want a tool to be able to change things.
A tool a key is not allowed to use is simply not offered to the agent, so a read-only key never sees the writing tools at all.
Limits
Two limits apply to every connected tool:
- A per-minute rate limit on the endpoint. Past it, calls get a
429with a retry-after and the message "Rate limit exceeded. Slow down and retry shortly." - The plan's MCP calls per month. Past it, calls get "Plan limit reached" and stop until the meter resets. A call denied over the limit still counts. See Usage for where you stand.
Renamed tools
If a saved instruction names a tool that is not on this page, it is probably an earlier name. The old names are not served: an agent that calls one gets an error saying what the tool is called now, and is told to let you know so you can update the instruction. That matters most for the text pasted into v0's Instructions or Lovable's Workspace knowledge, which nothing on the server can update for you.
A few arguments were renamed too. Those are handled quietly: an old spelling, such as root_area on search_rules or noteType on save_project_notes, is rewritten to the current name before the call runs, so older instructions keep working.
| Old name | Current name |
|---|---|
get_notes | get_project_notes |
get_ruleset | get_rules_index |
list_rule_areas | get_rules_index |
list_rule_nodes | get_rules_index |
get_tokens | get_design_tokens |
validate | check_rule_compliance |
add_rule | add_project_rule |
set_token | set_design_token |
import_tokens | import_design_tokens |
scan_site | import_design_tokens_from_site |
list_assets | list_brand_assets |
save_note | save_project_notes |
export_markdown | export_ruleset |
override_rule | update_rule |
