Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@circe-mcp check this text: It's not just code, it's craft."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that checks text against the Circe Editorial Standard (CES) v0.3 and returns each violation with its rule ID, line and column, severity, confidence, and a suggested fix. Every check is deterministic pattern matching. The server makes no LLM calls, so a check costs nothing to run and gives the same answer every time.
The standard catches the writing patterns that read as machine-generated: em dashes, hedges, hollow intensifiers, trailing contrast clauses, negate-then-elevate constructions, throat-clearing openers, and the rest. This server is the standard's automated reviewer. The standard is a working draft by Avalynn Circe; explain_rule carries the text of every rule the server enforces.
The server runs with npx, so there is nothing to install.
Claude Code
claude mcp add circe-mcp -- npx -y circe-mcpClaude Desktop
Add the server to claude_desktop_config.json:
{
"mcpServers": {
"circe-mcp": {
"command": "npx",
"args": ["-y", "circe-mcp"]
}
}
}Cursor, Windsurf, and other stdio clients use the same command and arguments. For a hosted deployment, npx circe-mcp http --port 3000 serves the same tools over Streamable HTTP at /mcp.
Node.js 20 or later is required.
Related MCP server: slop-guard
Tool | Input | Output |
|
| Violations with |
| optional | Every rule with its ID, name, level, and a one-line summary. Optional rules are marked. |
|
| The full rule: pattern, reasoning, replacement strategy, exceptions, a before/after example, and the tokens the checker uses. |
|
| The text with safe fixes applied, the list of edits, and the violations left for the writer. |
|
| Statistics with no verdict: sentence lengths per paragraph, rhythm, opener echo, specificity density, paragraph density, and over-enthusiasm signals. |
Each tool returns a readable report as text and the full result as structured content, so a client can show one and a model can parse the other.
Input to check_text:
It's not just code, it's craft. We built it in practice.Output:
1:6 error CES-C-008: Trailing contrast clause 'not just'. End the sentence at the positive point. (also CES-Q-001, CES-C-001)
1:45 error CES-V-007: Flourish 'in practice'. Delete it or make the claim as a plain statement.
2 error(s), 0 warning(s), 0 suggestion(s).When violations overlap, the most severe one is reported and the others are listed under related. The first sentence trips three rules in one span; the report shows it once.
Severity follows the standard's tiers. MUST AVOID rules report as error, SHOULD AVOID rules as warning. Each violation also carries a confidence level, because a token match is sometimes a guess.
Rule | Level | Default | Catches |
CES-P-001 No em dashes | error | on | The em dash character (U+2014). |
CES-Q-001 No reflexive hedges | warning | on |
|
CES-Q-002 No hollow intensifiers | warning | on |
|
CES-C-001 No negate-then-elevate | warning | on |
|
CES-C-002 No stylistic triple lists | warning | off | Three single words joined |
CES-C-003 No throat-clearing runways | warning | on |
|
CES-C-004 No trailing bows | warning | on |
|
CES-C-005 No so-what gloss | warning | on |
|
CES-C-008 No trailing contrast clauses | error | on |
|
CES-V-001 No resume cliches | warning | off | The standard's phrase list: |
CES-V-006 No chatty asides | warning | on |
|
CES-V-007 No punchy-for-punchiness'-sake flourishes | error | on | Implied inferior baselines: |
CES-V-008 No gratuitous trailing clauses | warning | on | Trailing minimizers: |
Two rules are off by default because they guess more than the others. Pass includeOptional: true to run them, or name them in rules.
The sub-forms of a rule come back in the form field. An inferior baseline reports as CES-V-007 with form: inferior-baseline, which is where the standard files it.
Pattern matching catches stock phrasing. It cannot judge whether a short declarative is a pronouncement or the one line that states a paragraph's point (CES-C-007), whether a contrast carries facts the reader needs, or whether a paragraph is vague perfection (CES-V-004). The flourish and sass detectors catch the signature phrases and will miss cases that need a reader. measure_text reports the numbers behind the judgment calls and leaves the call to the writer.
Rules that need a human stay out of check_text: the deletion test for CES-C-003 through CES-C-007 beyond their stock forms, manufactured intimacy (CES-V-002), scene-painting (CES-V-003), and the sections of the standard that cover factual accuracy, document structure, and typography.
A contrast that carries facts the reader needs is allowed under CES-C-008, such as a migration from one database to another. Mark a justified exception with an inline directive in an HTML comment, which renders as nothing:
<!-- ces ignore CES-C-008 -->
The team moved the reports from MS Access to SQL Server rather than rewriting them.
<!-- ces end -->A directive takes one or more rule IDs, in any case, separated by spaces or commas. Without an end marker it runs to the end of the text. <!-- ces end CES-C-008 --> closes one rule and leaves the others open. <!-- ces off --> and <!-- ces on --> silence every rule for a section. For a single call, pass the rule IDs to skip in the ignore parameter.
Fenced code blocks, inline code, link destinations, HTML tags, and comments are skipped. Front matter is checked, because a page description is prose. Pass checkCode: true to lint code comments too (CES-K-003). Line and column numbers refer to the original text.
fix_text applies the fixes that have one safe answer. An em dash becomes a comma, with the spaces around it absorbed. A hedge or hollow intensifier is deleted along with one adjacent space, and the next word is capitalized when the deleted word opened the sentence. A fixable word inside a larger construction is left in place, because the construction needs a rewrite, not a deletion. Review an em dash fix that joins two independent clauses; the standard allows a semicolon or a new sentence there, and the fixer cannot tell which.
Every other rule is report-only.
rules/ces.yaml is the single source of truth. Each rule carries its ID, severity, description, message, suggestion, exception, a before/after example, and its tokens with per-token severity and confidence. Heuristic rules name a detector in src/detectors.ts. The server loads the file at startup and validates every entry, so a typo in a rule fails fast with a message that names the rule and the field.
Adding a rule is one YAML entry plus a fixture with a text it flags and a text it passes. The test suite refuses a rule without a fixture and a fixture without a rule.
circe-mcp # MCP server on stdio
circe-mcp http --port 3000 # MCP server over Streamable HTTP
circe-mcp check README.md docs/ # lint files; exit 1 on an error-level hit
circe-mcp fix draft.md --write # apply the safe fixes in place
circe-mcp measure draft.md # statistics as JSONcheck takes --fail-on warning to make warnings fail too, --include-optional to run the optional rules, and --json for machine-readable output.
npm install
npm test # Vitest: fixtures per rule, positions, exceptions, fixes, MCP round trip
npm run typecheck
npm run build # compiles to dist/; the server reads rules/ces.yaml from the package root
npm run check # typecheck, test, buildEvery rule has at least one fixture that it flags and one that it passes, and its own before/after example from the standard is tested the same way. The README and the tool descriptions are checked against the standard in the test suite and in CI, so this file passes check_text with zero violations, optional rules included. A 10,000-word check completes in under 200 ms.
DECISIONS.md records the design decisions and the reasoning behind them, including where each rule's ID comes from and why two rules ship off by default.
MIT. See LICENSE.
Check text against the Circe Editorial Standard (CES) v0.3. Returns each violation with its rule ID, severity, confidence, line and column, the matched text, a message, and a suggested fix. Overlapping violations are reported once, with the others listed under 'related'.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to check. Markdown is understood: code blocks, inline code, URLs, and front matter are skipped. | |
| rules | No | Run exactly these rule IDs, such as ['CES-P-001', 'CES-C-008']. Includes optional rules when named. | |
| ignore | No | Rule IDs to skip for this call. Use it for a justified exception, such as a factual contrast under CES-C-008. | |
| severity | No | Lowest level to report. 'error' reports errors only; 'warning' adds warnings. Default: everything. | |
| checkCode | No | Lint fenced code blocks and inline code too (CES-K-003). Default false. | |
| includeOptional | No | Also run the optional rules (stylistic triples, resume cliches). Default false. |
| Name | Required | Description |
|---|---|---|
| counts | Yes | |
| rulesRun | Yes | |
| violations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, and the description adds real behavioral nuance: the CES version checked, the violation payload shape, and the dedup rule where overlapping violations collapse into one with 'related' entries. It does not cover rate limits or failure modes, but it exceeds the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the purpose front-loaded and zero filler. The second sentence partly restates what the output schema already exposes, which is the only slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full output schema and complete parameter descriptions, the description only needs to frame the tool's role, which it does, plus the CES version and dedup semantics. The one meaningful gap is routing guidance relative to fix_text/explain_rule/list_rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including rules, ignore, severity, checkCode and includeOptional is already documented in the schema. The description adds no parameter-level meaning, which is the expected baseline when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (check text against the CES v0.3) and describes the diagnostic output, which implicitly distinguishes it from fix_text. However, it never names or contrasts with any sibling, so an agent must infer the boundary between checking, fixing, and measuring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives such as fix_text for applying fixes or explain_rule for interpreting a rule ID. Usage must be inferred entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the full text of one CES rule: the pattern, why it is a tell, the replacement strategy, exceptions, a before/after example, and the tokens the checker uses.
| Name | Required | Description | Default |
|---|---|---|---|
| ruleId | Yes | A rule ID such as CES-C-008. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| rating | Yes | |
| tokens | Yes | |
| example | No | |
| category | Yes | |
| detector | No | |
| severity | Yes | |
| exception | No | |
| suggestion | Yes | |
| description | Yes | |
| enabledByDefault | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and a closed world, so the safety profile is covered. The description goes beyond that by disclosing the content shape of the result (pattern, rationale, strategy, exceptions, example, tokens), which tells an agent what this call is useful for. It stops short of saying what happens on an unknown rule ID.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and scope, followed by a compact enumeration of payload contents. No filler, no restatement of the name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, read-only annotations, and an output schema that carries the return structure, the description is nearly sufficient as written. The only omission is how an agent obtains a valid rule ID (presumably via list_rules) and behavior for an invalid ID, which is a minor gap for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single required ruleId whose format is already documented ("A rule ID such as CES-C-008."). The description adds only the implication that the ID resolves to exactly one rule; no additional format, casing, or lookup guidance is supplied. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Show") and a precisely scoped resource ("the full text of one CES rule"), then enumerates exactly what that text contains: pattern, rationale, replacement strategy, exceptions, example, and checker tokens. The word "one" implicitly contrasts with the sibling list_rules, so an agent can distinguish the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: fetching a single rule's detail versus list_rules for enumeration. There is no explicit when-to-use statement, no statement of prerequisites (e.g., needing a rule ID from list_rules), and no condition that selects this over fix_text or check_text. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply the safe fixes to a text: em dashes become commas, and reflexive hedges and hollow intensifiers are deleted. Returns the fixed text, the list of edits, and the violations left for the writer.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to check. Markdown is understood: code blocks, inline code, URLs, and front matter are skipped. | |
| rules | No | Run exactly these rule IDs, such as ['CES-P-001', 'CES-C-008']. Includes optional rules when named. | |
| ignore | No | Rule IDs to skip for this call. Use it for a justified exception, such as a factual contrast under CES-C-008. | |
| includeOptional | No | Also run the optional rules (stylistic triples, resume cliches). Default false. |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| applied | Yes | |
| remaining | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and idempotentHint=true, so the safety profile is covered. The description adds genuine context beyond that: it specifies which edits are applied, that some violations are deliberately left unfixed, and what the response contains (fixed text, edits, remaining violations).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and its concrete effects, then the return contract. No filler and no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not detail return values, yet it helpfully summarizes them. What is missing is routing guidance against the sibling tools (when to fix vs. merely check), the only real gap for a four-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents text, rules, ignore and includeOptional with examples and defaults. The description adds nothing parameter-specific, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ("Apply the safe fixes to a text") and enumerates exactly which transformations occur (em dashes to commas; reflexive hedges and hollow intensifiers deleted). This makes it clearly distinguishable from the sibling check_text, which by contrast only reports rather than applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb and by the closing clause about violations "left for the writer", which scopes the tool to non-destructive, safe fixes only. However, it never explicitly says when to prefer this over check_text or measure_text, nor when to reach for includeOptional instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the CES rules this server enforces, with ID, name, severity, and a one-line description. Optional rules are marked.
| Name | Required | Description | Default |
|---|---|---|---|
| severity | No | Only rules at this level. |
| Name | Required | Description |
|---|---|---|
| rules | Yes | |
| version | Yes | |
| standard | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds the note that 'Optional rules are marked' and lists returned fields, but the field list largely duplicates the existing output schema, so incremental behavioral value is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences: action and return payload first, then the optional-rule marker. No filler, nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and annotations covering safety, return-format detail is correctly left to structured fields, and the description covers scope and filter behavior adequately. Only a pointer to explain_rule for per-rule detail would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single severity parameter has 100% schema description coverage ('Only rules at this level') plus an enum, so the schema carries the meaning. The description adds nothing about the filter, matching the baseline 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb+resource: 'List the CES rules this server enforces', with the returned fields enumerated. It is readily distinguishable from check_text/fix_text/measure_text by activity type, though it never explicitly contrasts itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied — an agent infers this is a discovery tool to run before explain_rule or check_text. There is no explicit when-to-use statement, no preconditions, and no named alternative, so it sits at minimum-viable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report statistics about a text with no verdict: sentence lengths and rhythm per paragraph, opener echo, specificity density (CES-V-004), paragraph density (CES-S-002), and over-enthusiasm signals (CES-V-005).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to check. Markdown is understood: code blocks, inline code, URLs, and front matter are skipped. |
| Name | Required | Description |
|---|---|---|
| wordCount | Yes | |
| paragraphs | Yes | |
| exclamations | Yes | |
| sentenceCount | Yes | |
| paragraphCount | Yes | |
| meanSentenceLength | Yes | |
| stackedSuperlatives | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-open-world, so the safety profile is covered. The description adds real behavioral context beyond that: this tool produces no pass/fail judgment, and it names the specific metric families it reports (rhythm, opener echo, density, over-enthusiasm), which tells the agent how to treat the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence that names the purpose first and then the metric families, with no filler. The density of rule IDs (CES-V-004, CES-S-002, CES-V-005) is somewhat opaque without context, slightly reducing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and annotations cover safety; the description fills the remaining gap by defining the scoring intent. The only shortfall is the absent explicit routing to the sibling tools an agent would otherwise confuse this with (check_text, fix_text).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter's markdown-parsing behavior is fully documented in the schema. The description adds no parameter-level detail (e.g., expected size, encoding, or handling of empty input), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ("Report statistics about a text") and enumerates the metrics produced, so the agent knows exactly what comes back. It implicitly distinguishes itself from check_text via "no verdict," but never names that sibling, so the differentiation is inferential rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"With no verdict" signals this is the diagnostic-only option versus the judging siblings, which is useful implied usage. However, there is no explicit when-to-use statement, no naming of check_text/fix_text as alternatives, and no guidance on sequencing (e.g., measure before fixing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_textexplain_rulefix_textlist_rulesmeasure_textScored across 5 tools
Each tool has a clearly distinct role: check_text finds violations, measure_text reports statistics with no verdict, fix_text applies safe fixes, list_rules enumerates rules, and explain_rule details a single rule. The check_text/measure_text boundary is explicitly clarified by 'no verdict' vs violation reporting, leaving no real overlap.
All five tools follow a consistent verb_noun snake_case pattern (check_text, fix_text, measure_text, list_rules, explain_rule). Verb pairing with noun reads predictably across the set.
Five tools is well-scoped for an editorial-linting server, covering the natural verbs (check, fix, measure, list, explain) without redundancy. Each tool earns its place in the workflow.
The core lifecycle is covered: discovery (list_rules, explain_rule), analysis (check_text, measure_text), and remediation (fix_text). Minor gaps exist, such as batch/file-level checking or rule configuration, but agents can work around them.
DraftCheck: flags AI-writing patterns in prose with fix hints. Deterministic linter, not a detector.
Check AI work against requirements and return structured verdicts, findings, and repair steps.
Free mechanical checks for AI text: unnamed counts, dangling references, bad arithmetic, misquotes.
Find the lines that make writing sound like AI, with a plain fix for each. Free to start.