Clearon Editorial Pipeline MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLEARON_EDITORIAL_ROOT | No | Override the default data directory. By default, project data is stored in a user data directory (macOS: ~/Library/Application Support/clearon-editorial-pipeline-mcp/projects, Linux: ${XDG_DATA_HOME:-~/.local/share}/clearon-editorial-pipeline-mcp/projects, Windows: %APPDATA%\clearon-editorial-pipeline-mcp\projects). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_server_healthA | Report editorial pipeline health, storage root, and review boundary. |
| create_editorial_projectC | Create a new Clearon editorial project with an immutable initial revision. |
| list_editorial_projectsB | List editorial projects and their workflow status. |
| get_editorial_projectB | Read project metadata and a current or specified immutable revision. |
| audit_revisionB | Run transparent Clearon style heuristics against a revision. This is not an AI-authorship detector. |
| propose_revisionA | Validate a proposed rewrite without saving it; checks the current fingerprint, protected passages, and style heuristics. |
| apply_revisionB | Append an immutable revision after an exact proposal review; never overwrites prior text. |
| approve_revisionC | Approve the current revision only after explicit editorial, factual, and quotation review confirmations. |
| export_wordpress_payloadA | Create a draft-only payload from the approved revision for a separate publishing dry run. Does not publish. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct action in the editorial workflow, and the descriptions generally clarify the resource being acted on. The only mild ambiguity is between audit_revision and propose_revision, since both involve style heuristics, but the existing-versus-proposed distinction is made clear.
All tool names follow a consistent verb_noun snake_case pattern, such as get_editorial_project, propose_revision, and export_wordpress_payload. There are no mixed conventions or vague generic verbs.
Nine tools is well-scoped for an editorial pipeline covering project creation, inspection, revision workflow, approval, and export. Each tool maps to a meaningful stage in the process without redundancy or bloat.
The core lifecycle—create, list, get, audit, propose, apply, approve, and export—is covered with no dead ends. Missing operations like project metadata updates or explicit rejection are minor given the immutable-revision design and the intentional dry-run export boundary.