This server analyzes text for writing style issues and AI-generated content patterns. It provides the following tools:
check_text: Analyze text (plain or markdown) for 8 categories of writing problems — weasel words, passive voice, duplicate words, long sentences, nominalizations, hedging, filler adverbs, and AI tells. Returns structured results with issue positions, line/column numbers, and context. Accepts an optional config object to customize detectors and a format option (plain or markdown) to skip code blocks, tables, and headings.
fix_duplicates: Automatically remove adjacent repeated words from text and return the cleaned version.
list_word_lists: Retrieve metadata about all detector word lists, including item counts and sample entries (e.g., 95 weasel words, 98 AI tell words, 100 hedging phrases, etc.).
check_file (local server only): Read a file directly from disk and analyze it for style issues. Automatically discovers and applies .wscrc.json configuration files by searching upward from the file's directory, with optional config override support.
Allows running the Writing Style Checker in GitHub Actions CI to automatically check files for writing issues with configurable options.
A prose linter and AI-slop detector. WSC finds AI tells — words, phrases, and sentence structures overrepresented in AI-generated text, each flag backed by a published corpus study. It also catches classic writing issues: weasel words, passive voice, duplicate words, long sentences, nominalizations, hedging, and filler adverbs. Available as a web editor, HTTP API, MCP server, CLI, and GitHub Action.
Web Editor - Real-time highlighting with inline fix buttons for all 8 detectors
HTTP API - POST text with optional config, retrieve structured JSON responses
MCP Server (Remote) - Connect AI assistants via Streamable HTTP transport
MCP Server (Local) - Stdio-based server via wsc-mcp on npm
CLI - Check files from the command line via wsc-lint
GitHub Action - Run checks in CI with ::warning annotations
Configurable - Customize detectors with .wscrc.json files
Related MCP server: BeLikeNative Grammar Server
WSC flags patterns that research on AI-generated text finds overrepresented, and cites a source for every flag. It does not, and cannot, prove authorship. Classifier-based detectors carry a documented false-accusation risk: a Stanford study found that seven of them misflagged 61% of essays written by non-native English speakers. WSC avoids that trap by design — every flag is a specific, explainable edit that improves the text no matter who, or what, wrote it.
Detector | Items | Description |
Weasel Words | 95 words/phrases | Vague terms like "very", "basically", "arguably", "numerous" |
Passive Voice | 260 irregular verbs | Auxiliary verbs + past participles (regular |
Duplicate Words | — | Adjacent repeated words across whitespace, case-insensitive |
Long Sentences | threshold: 30 words | Sentences exceeding a configurable word count |
Nominalizations | 245 word pairs | Nouns replaceable with verbs ("utilization" → "use") |
Hedging | 100 phrases | Phrases that weaken assertions ("I think", "it seems") |
Filler Adverbs | 139 words | Adverbs adding emphasis without substance ("totally", "utterly") |
AI Tells | 98 words (+111 inflected forms) + 83 phrases + 12 structural patterns | Words, phrases, and sentence constructions overrepresented in AI-generated text ( |
Word lists sourced from Matt Might's shell scripts and expanded with additional entries. AI tells draw on published corpus studies: Kobak et al. 2025 (Science Advances), Juzek & Ward 2025 (COLING), Liang et al. 2024 (Stanford), and Reinhart et al. 2025 (PNAS). Wikipedia's editor-maintained Signs of AI writing catalogue and AI-detection vendor reports round out the sources.
Create a .wscrc.json to customize detectors. All tools (API, MCP, CLI) support it.
{
"$schema": "https://wsc.theserverless.dev/schema.json",
"detectors": {
"weaselWords": {
"enabled": true,
"add": ["synergy", "leverage"],
"remove": ["very"]
},
"longSentences": { "maxWords": 25 },
"adverbs": { "enabled": false }
}
}Every field is optional. Missing fields use defaults. JSON Schema provides autocompletion in VS Code.
POST /api/checkAnalyze text for writing style issues. Accepts optional config object.
curl -X POST https://wsc.theserverless.dev/api/check \
-H "Content-Type: application/json" \
-d '{"text":"The code was written very quickly."}'Response:
{
"summary": {
"total": 2,
"weaselWords": 1,
"passiveVoice": 1,
"duplicateWords": 0,
"longSentences": 0,
"nominalizations": 0,
"hedging": 0,
"adverbs": 0
},
"issues": {
"weaselWords": [{ "word": "very", "index": 21, "line": 1, "column": 22, "context": "..." }],
"passiveVoice": [{ "phrase": "was written", "index": 9, "line": 1, "column": 10, "context": "..." }],
"duplicateWords": [],
"longSentences": [],
"nominalizations": [],
"hedging": [],
"adverbs": []
},
"meta": { "characterCount": 34, "wordCount": 6, "sentenceCount": 1, "processingTimeMs": 2 }
}With config:
curl -X POST https://wsc.theserverless.dev/api/check \
-H "Content-Type: application/json" \
-d '{"text":"The code was written very quickly.", "config":{"detectors":{"weaselWords":{"enabled":false}}}}'GET /api/checkReturns API documentation as JSON.
GET /api/detectorsReturns the list of all 8 detectors with descriptions, configurability, and word counts.
GET /healthRuns a smoke test with known text and returns {"status":"healthy"} or 503.
Limits: Max 100,000 characters per request. CORS enabled for all origins.
The Writing Style Checker is available as an MCP server, letting AI assistants check your writing directly.
Tool | Description |
| Analyze text for all 8 writing style issues. Accepts optional |
| Remove duplicate adjacent words and return cleaned text |
| Return info about all detector word lists |
| (Local only) Read a file from disk and analyze it. Auto-discovers |
Connect any MCP client to the hosted server - no installation required.
{
"mcpServers": {
"writing-style-checker": {
"type": "url",
"url": "https://wsc.theserverless.dev/mcp"
}
}
}Install via npm for local usage. Includes check_file for analyzing files on disk with auto-discovery of .wscrc.json.
npx wsc-mcpClaude Desktop / Claude Code config:
{
"mcpServers": {
"writing-style-checker": {
"command": "npx",
"args": ["wsc-mcp"]
}
}
}See the wsc-mcp npm page for full documentation.
Check files from the command line.
# Check all markdown files
npx wsc-lint check "**/*.md"
# Read from stdin
echo "The code was written very quickly." | npx wsc-lint check --stdin
# JSON output for scripting
npx wsc-lint check "**/*.md" --format json
# GitHub Actions annotations
npx wsc-lint check "**/*.md" --format github
# Create a config file
npx wsc-lint initSee the wsc-lint README for full documentation.
- uses: theserverlessdev/wsc@v1
with:
files: '**/*.md'
max-warnings: 20Input | Default | Description |
|
| Glob pattern for files to check |
| — | Path to |
| unlimited | Max warnings before failing |
|
| Only check files changed in this PR |
The web editor runs in your browser - we never send text to any server. The API and MCP endpoints only process text you explicitly send to them.
.
├── src/
│ ├── core/ # Shared detection engine
│ │ ├── detector.ts # 8 detection algorithms
│ │ ├── words.ts # Word/phrase lists (800+ entries)
│ │ ├── config.ts # Config types, merging, validation
│ │ ├── config-node.ts # Node-only: file loading, discovery
│ │ ├── analyzer.ts # Unified analyzeText() entry point
│ │ └── index.ts # Public API exports
│ ├── docs/ # Documentation content (Markdown files)
│ ├── mcp/
│ │ └── handler.ts # MCP JSON-RPC 2.0 handler
│ ├── lib/
│ │ ├── App.svelte # Main editor page component
│ │ ├── stores/theme.ts # Theme store (light/dark/system)
│ │ └── components/ # UI components (StatsBar, ConfigPanel, etc.)
│ ├── routes/
│ │ ├── +layout.svelte # Shared layout (header, nav, footer)
│ │ ├── api/check/+server.ts # HTTP API endpoint
│ │ ├── mcp/+server.ts # MCP endpoint
│ │ ├── health/+server.ts # Health check endpoint
│ │ ├── docs/+page.svelte # Documentation page
│ │ └── words/+page.svelte # Word library browser
│ └── styles/
│ └── main.scss # Global styles (light + dark themes)
├── mcp-server/ # Standalone stdio MCP server (npm: wsc-mcp)
├── cli/ # CLI tool (npm: wsc-lint)
├── action/ # GitHub Action (composite)
├── tests/ # 341 tests across 18 files
├── static/
│ ├── schema.json # JSON Schema for .wscrc.json
│ ├── llms.txt # AI/LLM discovery file
│ └── llms-full.txt # Detailed LLM context
├── wrangler.toml # Cloudflare Workers config
└── svelte.config.js # SvelteKit configurationgit clone https://github.com/theserverlessdev/wsc.git
cd wsc
npm install
npm run devVisit http://localhost:5173. The API is at /api/check, MCP at /mcp, health at /health.
Command | Description |
| Start dev server |
| Build for production |
| Type check with svelte-check |
| Run all 341 tests |
| Coverage report |
Deployed as a Cloudflare Worker at wsc.theserverless.dev.
npm run build
npx wrangler deploySee CONTRIBUTING.md for development setup, testing, and pull request guidelines.
For substantial changes, please open an issue first.
Matt Might for the original shell scripts
Built with SvelteKit and Svelte 5, deployed on Cloudflare Workers
Logo made with DiffusionBee
Read a UTF-8 file from local disk and analyze it for the same writing style issues as check_text (weasel words, passive voice, hedging, AI tells, and more). Read-only: the file is never modified, and Markdown files are automatically masked so code blocks and tables are not linted as prose. A .wscrc.json config is auto-discovered from the file's directory upward unless config is passed explicitly. Returns the same line-and-column report as check_text, or an error message for unreadable or oversized (over 100,000 characters) files. Use when the text lives on disk; use check_text for text already in the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or relative path to the file to analyze; read as UTF-8 | |
| config | No | Optional config (same schema as .wscrc.json); when set, auto-discovery of .wscrc.json is skipped |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=true, and the description reinforces 'Read-only: the file is never modified.' It adds important details like Markdown masking for code blocks/tables, auto-discovery of config, and error conditions for unreadable/oversized files. No contradictions with annotations.
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?
Concise at approximately 100 words, every sentence serves a purpose. Front-loaded with the core action, then adds behavioral semantics and usage guidance without 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?
Despite no output schema, the description adequately explains the return format (same line-and-column report as check_text) and error conditions. Covers config auto-discovery, file size limit, and Markdown masking, making the tool's behavior fully understood.
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 covers both parameters with descriptions (100% coverage). The description adds value by explaining path must be UTF-8 and that setting config disables auto-discovery, which enriches the schema information.
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?
Explicitly states the tool reads a file from local disk and analyzes for writing style issues, directly distinguishing it from check_text for inline text. The verb 'read and analyze' clearly specifies the action on the resource.
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?
Provides explicit guidance: 'Use when the text lives on disk; use check_text for text already in the conversation.' This clearly defines appropriate use cases and the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze text for writing style issues: weasel words, passive voice, duplicate words, long sentences, nominalizations, hedging, filler adverbs, and research-cited AI tells. Read-only and stateless — text is analyzed in memory, never stored. Returns a plain-text report with each issue's line and column, the matched text, surrounding context, and the reason for AI tells; texts over 100,000 characters return an error message. Use this for text already in the conversation; use check_file for files on disk. It only reports issues — to auto-remove duplicate words, follow up with fix_duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to analyze for writing style issues | |
| config | No | Optional config to enable/disable detectors or add/remove word-list entries; same schema as .wscrc.json (https://wsc.theserverless.dev/schema.json) | |
| format | No | Set to "markdown" to mask code blocks, inline code, tables, and headings so they are not linted as prose; default "plain" lints everything |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, openWorldHint=false), the description adds that the tool is read-only, stateless, never stores text, returns a plain-text report with line/column details, and has a character limit error.
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?
The description is dense but every sentence adds value. It could be more structured (e.g., bullet points) but remains concise and front-loads the main purpose.
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?
Given the complexity (3 params, nested objects, no output schema), the description covers output format, error conditions, sibling usage, and behavioral traits. No obvious gaps.
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 already covers all parameters with descriptions (100% coverage). The description adds minor context (character limit, output format) but doesn't significantly enhance understanding of schema-defined parameters like config or format.
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 clearly states the tool analyzes text for specific writing style issues, listing them explicitly. It also differentiates from sibling tools by specifying when to use check_text vs check_file and mentions follow-up with fix_duplicates.
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?
Provides explicit guidance: use for text in conversation, use check_file for files, and follow up with fix_duplicates for auto-removal. Also notes that texts over 100k chars return an error.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove duplicate adjacent words (case-insensitive, including across line breaks) and return the cleaned text plus the list of words that were removed. Read-only with no side effects: the fix is returned in the response, nothing is written anywhere. Use after check_text or check_file reports duplicate words; other issue types are report-only and have no auto-fix.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to clean by removing duplicate adjacent words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and openWorldHint=false. The description adds that the fix is returned in the response with no side effects, reinforcing the read-only nature and adding context beyond annotations.
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 concise sentences front-loading the action and key details, with no unnecessary words. Every sentence earns its place.
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?
For a simple tool with one parameter and no output schema, the description provides complete context: what it does, what it returns, when to use it, and behavioral constraints. Annotations cover safety aspects.
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 schema has 100% coverage for the single parameter 'text' with a basic description. The tool description adds global context (case-insensitive, across line breaks) that goes beyond schema, enhancing understanding.
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 clearly states the tool removes duplicate adjacent words case-insensitively, including across line breaks, and returns cleaned text plus removed words list. This distinguishes it from siblings like check_text and check_file which only report issues.
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?
Explicitly instructs to use after check_text or check_file reports duplicate words, and notes that other issue types are report-only. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return every detector word/phrase list with its entry count, config key, and sample entries, plus a link to the full browsable library. Read-only, takes no parameters, and returns the same catalog for a given release. Use it to see what the detectors match before tuning a config for check_text or check_file; not needed for ordinary checking.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it is read-only (consistent with readOnlyHint annotation), takes no parameters, and returns the same catalog per release (constant behavior). This adds context beyond annotations, though it could mention potential dataset size or caching.
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 concise sentences that front-load the purpose and key features with zero waste. Every sentence serves a clear function.
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?
Despite no output schema, the description fully enumerates what the tool returns (entry count, config key, sample entries, link). For a zero-parameter read-only catalog tool, this is complete and clear.
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 tool has no parameters, and the description confirms this ('takes no parameters'). Per the rubric, 0 parameters earns a baseline of 4; no additional value needed.
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 specifies a clear verb ('return') and resource ('every detector word/phrase list') with detailed output fields (entry count, config key, sample entries, link). It distinguishes from siblings check_file, check_text, and fix_duplicates, which are for checking and fixing.
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 explicitly states when to use the tool ('before tuning a config for check_text or check_file') and when not needed ('not needed for ordinary checking'), providing clear guidance relative to sibling tools.
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. Dates show when Glama detected each change.
v2.2.2check_file5 fields changedInput schema / properties / config / additionalPropertiesAdded value: +{}Input schema / properties / config / descriptionPrevious value: -"Optional WscConfig JSON object (overrides auto-discovered .wscrc.json)"New value: +"Optional config (same schema as .wscrc.json); when set, auto-discovery of .wscrc.json is skipped"Input schema / properties / config / propertyNamesAdded value: +{
+ "type": "string"
+}Input schema / properties / config / typeAdded value: +"object"Input schema / properties / path / descriptionPrevious value: -"Path to the file to analyze"New value: +"Absolute or relative path to the file to analyze; read as UTF-8"check_text5 fields changedInput schema / properties / config / additionalPropertiesAdded value: +{}Input schema / properties / config / descriptionPrevious value: -"Optional WscConfig JSON object to customize detectors"New value: +"Optional config to enable/disable detectors or add/remove word-list entries; same schema as .wscrc.json (https://wsc.theserverless.dev/schema.json)"Input schema / properties / config / propertyNamesAdded value: +{
+ "type": "string"
+}Input schema / properties / config / typeAdded value: +"object"Input schema / properties / format / descriptionPrevious value: -"Set to \"markdown\" to skip code blocks, tables, and headings"New value: +"Set to \"markdown\" to mask code blocks, inline code, tables, and headings so they are not linted as prose; default \"plain\" lints everything"v2.2.1check_filecheck_textfix_duplicateslist_word_listsEach tool has a clearly distinct purpose: check_file vs check_text differ by input source, fix_duplicates is for fixing a specific issue, and list_word_lists provides reference data. No overlap in functionality.
All tool names follow a consistent verb_noun pattern in snake_case (check_file, check_text, fix_duplicates, list_word_lists), making the API predictable.
With 4 tools, the server is well-scoped for a writing style checker: two input methods for analysis, one fix action, and one list action. Not overly sparse or heavy.
The tool surface covers core checking and duplicate removal, but lacks auto-fix for other issue types (e.g., weasel words, passive voice). Users must manually edit text after reports, which is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Find AI-isms with evidence and fingerprint a writing voice from samples. 3 of 5 free.
Free mechanical checks for AI text: unnamed counts, dangling references, bad arithmetic, misquotes.
Deterministic writing filter. Marks 43 AI patterns with the line and the fix.
AI visibility checks, software recommendations and tool comparisons from measured AI answer data
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/theserverlessdev/wsc'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
