martins-humaniser
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANTHROPIC_API_KEY | No | API key for the anthropic backend. Required only if using the anthropic backend. | |
| AI_HUMANIZER_LEVEL | No | Rewrite level: light, standard, or deep. | standard |
| AI_HUMANIZER_MODEL | No | Model for the anthropic backend. | claude-sonnet-5-5 |
| AI_HUMANIZER_VOICE | No | Enable matching the user's voice. | off |
| AI_HUMANIZER_LOCALE | No | Spelling variant, for example British English or American English. | British English |
| AI_HUMANIZER_OUTPUT | No | Directory where saved copies go. | output/ |
| AI_HUMANIZER_BACKEND | No | Backend to use: auto, claude-cli, anthropic, ollama, openai-compatible, or mock. | auto |
| AI_HUMANIZER_WORKERS | No | Number of parallel chunks. | 3 |
| AI_HUMANIZER_SEMANTIC | No | Enable the deep check for empty claims. | off |
| AI_HUMANIZER_CLI_MODEL | No | Model for the claude-cli backend. Defaults to the CLI default. | |
| AI_HUMANIZER_LOCAL_URL | No | Local server address for ollama and openai-compatible backends. | http://localhost:11434 |
| AI_HUMANIZER_VOICE_DIR | No | Directory containing the user's writing samples. | voice/ |
| AI_HUMANIZER_SKILL_PATH | No | Path to an installed Claude skill file to use for rules. | |
| AI_HUMANIZER_ASSESS_RUNS | No | Number of assessor runs to average. | 1 |
| AI_HUMANIZER_EXTRA_RULES | No | Extra rule files to load. | |
| AI_HUMANIZER_LOCAL_MODEL | No | Model for the ollama and openai-compatible backends. | llama3.1:8b |
| AI_HUMANIZER_CUSTOM_RULES | No | Directory containing private custom rules. | rules/custom/ |
| AI_HUMANIZER_LOCAL_API_KEY | No | API key for a local server that requires one. | |
| AI_HUMANIZER_ASSESSOR_BACKEND | No | Backend to use as the assessor. Defaults to the same backend as the rewrite. |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| humanizer_statusA | Show which rewrite backends are available, which rule sources are loaded, and supported file types. |
| humanizer_get_rulesA | Return the editing rules (default rules, any installed humanizer skill, and the user's own SOP files). Read these before rewriting text yourself. Custom rules outrank the defaults. |
| humanizer_extract_documentB | Read a PDF, DOCX, Markdown or text file and return its text as Markdown. Args: path: Absolute path to the file on this machine. max_chars: Cap on returned text. |
| humanizer_lint_textA | Check text for AI-writing tells without using a model. Returns a 0-100 score (higher means more AI-like), counts by category, and each finding with its line, the matched text, a message and a suggested fix. Quotations are skipped except for chatbot artefacts. |
| humanizer_compareA | Compare an original and a rewrite: AI-tell score before and after, remaining tells, and whether numbers, links, emails and quotations survived. Call this after rewriting, before saving. |
| humanizer_save_documentA | Write rewritten Markdown text to a .docx, .pdf, .md or .txt file. Args: text: The rewritten document as Markdown (headings with #, one blank line between paragraphs). output_path: Absolute path ending in .docx, .pdf, .md or .txt. source_path: Optional original file. If it is a DOCX with the same structure, its styles are kept. overwrite: Replace an existing output file. The source file is never overwritten. |
| humanizer_humanize_textA | Rewrite text on the server with a model backend, then lint it and check facts. Args: text: Text to rewrite (Markdown or plain). level: light, standard or deep. backend: auto, claude-cli, anthropic or mock. Default auto. locale: For example "British English". style_sample: A sample of the author's own writing to match. assess: Also run the AI assessor for a before and after score (slower). voice: Match the writing samples in the voice folder (see humanizer_voice_profile). semantic: Add an AI pass that catches meaning-level tells such as empty claims (slower). local_model: Model name when backend is ollama or openai-compatible, for example llama3.1:8b. |
| humanizer_humanize_fileA | Rewrite a PDF, DOCX, Markdown or text file on the server and save the result next to it. PDF input is saved as .docx unless output_format is pdf. The original file is never changed. Default output is .humanised.. Args: path: Absolute path to the source file. output_path: Optional absolute output path (.docx, .pdf, .md or .txt). output_format: docx, pdf, md or txt. Default follows the source (PDF sources become docx). level: light, standard or deep. backend: auto, claude-cli, anthropic or mock. locale: For example "British English". style_sample: A sample of the author's own writing to match. overwrite: Replace an existing output file. assess: Also run the AI assessor for a before and after score (slower). also_pdf: Also save a PDF copy next to the output. voice: Match the writing samples in the voice folder. semantic: Add an AI pass that catches meaning-level tells (slower). local_model: Model name for the ollama or openai-compatible backends. |
| humanizer_assess_textA | Score how AI-written a text reads (0 to 100, higher is more AI-like) with a blind rubric. Returns six dimension scores, quoted issues that were checked against the text, and the pattern-checker score for comparison. Uses a model backend, so it is slower than lint_text. Args: text: The text to assess. backend: auto, claude-cli, anthropic or mock. runs: Repeat the assessment and average it (reduces noise). |
| humanizer_assess_fileB | Score a PDF, DOCX, Markdown or text file the same way as humanizer_assess_text. |
| humanizer_assess_pairB | Blind before and after scores for an original and your rewrite, plus a faithfulness check. Use this after rewriting text yourself. The assessor is not told which version is the rewrite. The faithfulness check reports details the rewrite invented, lost or changed. |
| humanizer_voice_profileB | Measure the author's writing habits from the samples in the voice folder. Returns the folder path, files read, word count, measured habits (sentence length, contractions, dashes) and a short model-written description of the voice. At least 150 words of samples are needed. |
| humanizer_learn_from_editA | Learn the author's taste from an AI draft and the version they fixed by hand. Returns the sentences that changed, phrases they removed, and general rules. With save=true the phrases are added to the pattern checker and the rules to the rewrite prompt from then on. |
| humanizer_forget_phraseC | Remove a phrase that was learned from the author's edits. |
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 14 tools
Most tools occupy clearly distinct slots: extract vs save vs humanize_text vs humanize_file vs lint vs assess are separable, and the text/file suffix pattern makes the scope explicit. The one real collision is humanizer_compare versus humanizer_assess_pair, which both take an original and a rewrite and both report before/after scores plus a fact-faithfulness check; the descriptions differentiate them (deterministic lint vs blind model rubric) but an agent could easily grab the wrong one.
Every tool uses the same humanizer_ prefix plus snake_case, and almost all follow a verb_noun shape (get_rules, lint_text, save_document, learn_from_edit, assess_file). The few noun-only names (status, voice_profile) are natural reads of read-only probes and do not break the pattern.
Fourteen tools sits comfortably in the sensible range for a document-rewriting pipeline, and each one maps to a real pipeline stage. It is slightly heavy because the assess_* and humanize_* families triple up across text/file/pair, which produces redundancy around the compare/assess_pair overlap.
The lifecycle is largely covered end to end: read a document, inspect and load rules, rewrite inline or as a file, lint, assess, verify facts, save, then learn from hand edits and profile the author's voice. Gaps are minor: learned rules can only be removed phrase-by-phrase (no way to list or drop a whole learned rule), and there is no tool to manage or reset the voice sample folder.