Vale CMS is the hosted editor for your whole Vale project — and a hosted MCP server that hands the same engine to your AI assistant. Rules get checked as they are written, by you or by it, so one that silently never fires can't reach your repo.
Vale itself stays free, open source, and MIT licensed. Vale CMS is the authoring layer on top.
The optional RB is why the first match includes carefully.
A sequence rule matching a "be" verb, an optional adverb, and a past participle — with the token sequence the engine resolved it to, and the alerts it produces, live.
One engine. Two ways to reach it.
Both run Vale's engine itself — the twelve check types, the same regex compilation, the same scopes. Whoever writes the rule, it is a linter that decides whether it works, not a model's opinion of whether it looks right.
Your whole Vale project in the browser — config, rules, vocabularies, dictionaries, filters, templates. The engine lints every keystroke and refuses to ship a rule that does not compile.
What you can editThe same engine, exposed as tools your assistant can call. It writes a rule, the engine tells it whether that rule compiles and what it actually matches, and it fixes its own mistake before you ever see one.
See it catch an errorNothing about a rule depends on which way in you took. A rule the assistant proves compiles is the same rule the editor lints with, in the same file your CI already reads.
Both are included on every paid plan.
Models already know Vale. What they can't do is check.
Ask any assistant for a Vale rule and it will write you plausible YAML. Whether it compiles, whether the regex matches anything, whether the config still loads — it has no way to find out, so you find out later, in CI. A hosted MCP server gives it the real engine to check against, so a rule that doesn't work never reaches you.
Two mistakes, neither of which reached you: one the rule would not compile, one it compiled and silently matched nothing. The second is the kind CI does not catch either — a rule that never fires looks exactly like a rule with nothing to report.
One token, pasted into your client's config. Nothing to install and nothing to run locally.
The tools your assistant calls run Vale's engine in process — not a reimplementation of it, and not a search over its documentation. A rule it says compiles, compiles. A rule it says fires, fires — on the text you gave it, with the severity you'll actually see.
Included on every paid plan, because one developer with one client is exactly who it's for.
26 tools, and every one of them can say “no”
An assistant with a documentation search can tell you what Vale should do. These tools run the engine, so they answer what it does. Open any of them — every panel is a real call and what actually came back.
Start from something that already compiles — not a blank file and a guess at the schema.
The half generation cannot do for itself: does it compile, does it fire, and does it fire on the right things.
Answers about the engine, from the engine — the tags, blocks, and scopes a rule will actually see.
Editing a rule already in use is the risky edit. Compiling proves it is valid; these prove the change is safe.
test_rule VerifyLint each input against the rule alone and check whether it should match — unit tests for one rule.
test_rule
rule: "tokens: ['\\b[1-9]\\b']"
tests:
- input: "Select 3 options."
expectMatch: true
- input: "Use version 1.2.3 of the CLI."
expectMatch: false[
{ "pass": true, "matched": true, "count": 1 },
{ "pass": false, "matched": true, "count": 3,
"matches": [
{ "match": "1", "span": [13, 13] },
{ "match": "2", "span": [15, 15] },
{ "match": "3", "span": [17, 17] }
]}
]\b treats a dot as a word boundary, so one version number matched three times. Nothing in the YAML tells you that.
Every one of the 26 carries a real call and its real output · full reference →
A text editor opens these files. It can't tell you what they do.
A mature Vale setup is an editorial system — rule logic, exceptions, package dependencies, scopes, ignore patterns, dictionaries. Vale CMS edits every part of it, and for each one it answers the question the file itself can't.
.vale.ini Config.yml Rules.dic · .aff Dictionariesaccept.txt Vocabulariesfilters Filtersviews Views.tmpl TemplatesType a word into a Hunspell dictionary and the affix classes that actually apply to it light up — conditions checked, not guessed — with a preview of the forms each flag buys. If a shorter stem already derives it, it offers that instead.
deploy/D looks fine and never produces "deployed". The condition excludes it.
Given a word, which dictionary entry generates it — and through which affix? A reverse lookup across the whole dictionary, including imported ones large enough that nothing precomputes an index for them.
The fastest way to find out why the spell-checker accepts something it should not.
A rule is not the YAML you typed — it is the pattern the engine compiles out of it, word boundaries, alternation, wrapper and all. That compiled source is on screen, highlighted, with each construct explained on hover.
Most rules that "look right and never fire" are wrong in the part you never see.
Styles, per-rule toggles and format sections cascade. The visualiser shows the state each rule ends up in, per glob, after all of it — beside a grounded preview of what your ignore patterns actually swallow.
The .vale.ini text cannot tell you which rules run in this file, at what level.
A filter expression evaluated against your resolved rules, showing exactly which survive. A view run over a sample, showing what each scope extracts. A template rendered against real alerts — or the error it fails with.
All three are the kind of asset you otherwise write blind and debug in CI.
Every field of an alert is machine-made — the check, the severity, the line and column nobody can predict without running. So you run the rule and accept the alerts it produced, and the suite tells you when a later edit changes them.
The edit that silently stops a rule firing is the one no one writes a test for.
Author, preview, and ship — without leaving the browser
Connect GitHub or GitLab, or open a local folder. Your content stays the source of truth — none of it is stored on our servers.
The real Vale engine runs on every keystroke: each alert, its severity, and the rule that fired. The same output your CI will produce.
Before anything ships, the engine confirms the config parses, references resolve, and every rule compiles. No broken style guides.
Write changes straight back to your branch, or propose them as a pull request. Enforcement stays with the Vale CLI and your CI.
A new rule gets read carefully. A one-word change to a rule that has been fine for a year gets waved through — and it is the one that quietly starts flagging a word inside another word, in files nobody re-reads.
Every edit is run against a corpus both ways, and you see the alerts it adds and removes before it lands.
We don't keep the things worth keeping safe.
Vale CMS has to open your project and write changes back to it. Your credentials stay in your browser and your writing is forgotten as soon as it is linted, so the parts that matter never pile up on our servers in the first place.
Read the full security pageThe column on the left is the reason the column on the right is short.
Vale CMS edits your repository directly. There is no second copy of your style guide living somewhere else, and nothing to migrate out of if you stop paying.
The access token stays in your browser. We hand it to GitHub or GitLab when you ask for something, then drop it. We never store it.
Your content is checked and forgotten. The engine holds it just long enough to lint it and writes none of it down.
Every script is fingerprinted before it ships, so anything injected later simply will not run — and if it somehow did, it could not send your data anywhere we have not listed by name.
Explore free. Author on Pro.
Vale stays free and open source. Vale CMS is the hosted authoring layer on top of it.
A real linting tool, in the browser, with no account.
The full editor and your own repositories, for one person.
Everyone at your domain, and everything they automate.
Pro and Site unlock the same product. Site buys coverage for a whole domain instead of one person — every colleague and every automated account, on one invoice, with no seat to run out of.
The questions we'd ask too
A month of the full editor and the MCP server, on your own repository. If it hasn't caught something your CI would have missed, cancel and keep using Vale for free.
Cancel anytime · the sample needs no account · Vale itself stays free and MIT licensed