Click on "Install 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., "@being-human analyze my previous writing and generate my voice rules"
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.
Your assistant writes like a press release because it doesn't know who you are. This tells it.
being-human reads the prompts you've already typed, measures how you actually write, and hands the model a description of your voice specific enough to follow. It also builds a list of words to avoid, computed by contrast against the model's own output, so it's personal to you rather than borrowed from a blog post about ChatGPT tells.
Local, stdlib Python 3, no dependencies, no network calls.
pip install being-human
being-human learn --name "Your Name" # harvest your writing, measure it
being-human check draft.md # AI tells
being-human verify draft.md # is it statistically you?
being-human export --target chatgpt # or agents, cursor, system, json
being-human card # draw your voiceprint as a shareable svgNo Claude Code history? Point it at a ChatGPT export or your own files:
being-human harvest --source chatgpt --path conversations.json --out .being-human/ --contrast
being-human harvest --source files --path ~/Documents/writing --out .being-human/Related MCP server: HumanizeMCP
Instructions with numbers attached, because "be concise" is not actionable and "your median message is 12 words" is:
- Write "i" lowercase. They do, 83% of the time.
- Vary sentence length hard. Theirs average 9 words but deviate 8, up to 81.
- No exclamation marks. Rate is 0.28 per 1k.
- Don't hedge. Hedge rate is 1.1 per 1k -- they assert.Your transcripts contain both sides of every conversation. So every word can be scored by log-odds: how much more likely you are to use it than the model is, on the same topics, in the same threads. The top of that list is your voice. The bottom is the model's.
Mine came back actually, clean, rather, genuinely, exactly, roughly. None of
those appear on any published list of AI words. They're the specific tics this
model has when talking to me. Yours will differ, because the contrast is against
your writing.
They catch different failures, and passing one says nothing about the other:
| is this generic AI writing? tells, rhythm, structure |
| is this you? authorship distance, Burrows's Delta against a length-matched null resampled from your own corpus |
Measured on my own corpus:
authorship | slop | |
my own writing | 6th pct, me | 99/100 |
generic LinkedIn slop | 19th pct, me? | 0/100 |
a README by someone else | 94th pct, not me | 97/100 |
Row two is the catch: slop has unremarkable grammar, so authorship distance passes it. Row three is clean prose with no tells that is plainly a different hand. The second case is the one nobody else tests for, and it's the one that bites.
Held-out chunks of real writing sit at the 49th to 60th percentile, with a 1-6% false-positive rate above p97. Thresholds are personal. Em dashes get flagged against your measured rate rather than a universal rule, which is why this doesn't punish people who genuinely use them.
claude mcp add being-human -- being-human-mcpSeven tools, two resources, two prompts. Configs for Claude Desktop, Cursor, Codex and Zed are in mcp/README.md.
MCP tools are model-invoked and nothing forces a model to call one, which is awkward when the payload is instructional. So every tool returns the voice rules alongside its own result. There's no path through the server that hands back a score without the target attached.
There's a Claude Code plugin too, via
/plugin marketplace add Syedomershah99/being-human. It adds
/being-human:learn, :check, :write, :verify, :export, and a hook that
grows the corpus as you type.
Everything is local. Grep for urllib, requests or socket and you'll find
nothing. Secrets are redacted at harvest time before anything touches disk, and
.being-human/ is gitignored. The voiceprint is safe to share. The corpus it was
built from is not.
This space got crowded in 2026. inside-lago framed the thesis, slop-guard is a mature slop linter, idiolect is architecturally closest, and writer-persona had the best idea of the lot: validate the profile with a backtest instead of trusting it.
Two things here I couldn't find elsewhere. The user-vs-model contrast, which derives the avoid-list from both sides of your own transcripts rather than from a curated list. And a deterministic impostor test. writer-persona uses an LLM judge across 8 axes; this is arithmetic, so it costs nothing and returns the same answer every time.
Burrows's Delta and log-odds with a Dirichlet prior are both established methods. The claim is the application and the calibration, not the statistics.
MIT. The tell list is data/slop-lexicon.json. If you keep seeing something that isn't in there, send a PR.
mcp-name: io.github.Syedomershah99/being-human
Compile the voiceprint into a format another tool reads: 'chatgpt' (custom instructions box, ~1500 chars), 'agents' (AGENTS.md), 'cursor' (.cursorrules), 'claude' (CLAUDE.md), 'system' (raw system prompt), or 'json'. Use when the user wants their voice set up in a different assistant.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses output formats and a character limit for chatgpt, but does not state whether the operation is read-only, writes files, or returns a value. Side effects and permissions are unmentioned.
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 written sentences. The first lists all targets compactly, and the second gives usage context. No wasted words.
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 one-parameter tool with no output schema, the description covers purpose, usage, and parameter semantics well. The only gap is not explicitly stating what the tool returns or whether it has side effects, which is minor given the tool's simplicity.
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 coverage is 0% and the schema only provides an enum. The description adds detailed semantics for each enum value (e.g., 'chatgpt' => custom instructions box, ~1500 chars; 'agents' => AGENTS.md), fully compensating for the schema's lack of explanations.
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 uses a specific verb ('compile') and resource ('voiceprint') and clearly distinguishes the tool from siblings by listing exact output formats. It unambiguously states what the tool does.
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 provides clear context with 'Use when the user wants their voice set up in a different assistant.' It does not explicitly state when not to use or name alternatives, but the sibling tool names and the format list imply the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the user's measured writing voice as explicit rules. CALL THIS BEFORE writing any prose the user will send or publish under their own name -- a post, email, reply, bio, doc, commit message, cover letter, or anything else in their name. The rules are measured from their own past writing (sentence rhythm, casing, punctuation rates, vocabulary, words to avoid), so they override your defaults. Cheap and fast; call it rather than guessing what the user sounds like.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses that the tool measures rules from past writing (sentence rhythm, casing, punctuation rates, vocabulary, words to avoid), that they override defaults, and that the tool is 'cheap and fast.' It does not explicitly state side-effect-free or mention error/insufficient-data behavior, but for a simple getter this is adequate.
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 compact yet information-dense. Each sentence serves a purpose: defining the output, providing an imperative usage cue, explaining the source and authority of the output, and emphasizing cost/benefit. There is no wasted wording or repetition beyond the intended emphasis.
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 zero-parameter tool with no output schema and no annotations, the description is remarkably complete. It tells the agent what the tool does, when to use it, why it matters, what data informs it, and what the behavioral characteristics are. The sibling context further clarifies its niche without needing extra explanation.
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 zero parameters, and the schema has 100% coverage (empty object). Per the rubric, a baseline of 4 applies when there are no parameters. The description doesn't need to explain parameter semantics.
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 uses a specific verb and resource: 'Get the user's measured writing voice as explicit rules.' It clearly distinguishes from sibling tools by focusing on retrieval of explicit rules rather than scoring, verification, status, learning, noting, or export. The scope is well-defined.
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 on when to call: 'CALL THIS BEFORE writing any prose the user will send or publish under their own name' with concrete examples (post, email, reply, bio, etc.). It also explains why it should be used ('they override your defaults') and gives negative guidance ('call it rather than guessing'). It does not name sibling tools as alternatives, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build or refresh the voiceprint from the user's own writing. Sources: 'claude-history' and 'claude-projects' (local Claude Code history), 'chatgpt' (a conversations.json from a ChatGPT data export, needs path), 'files' (a folder of the user's own writing, needs path). Takes a few seconds. Run this once at setup, or again to fold in newer writing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The user's name, for labelling. | |
| path | No | Required for 'chatgpt' and 'files'. | |
| append | No | Add to the existing corpus instead of replacing. | |
| source | Yes | Where to harvest from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It adds useful behavioral context: 'Takes a few seconds,' source-specific requirements ('needs path' for chatgpt/files), and the notion of refreshing. However, it does not explicitly clarify the default replace-vs-append behavior or potential side effects beyond what the schema already states. The phrase 'Build or refresh' is somewhat ambiguous.
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 two sentences and efficiently front-loads the purpose: first sentence defines the action, second sentence lists sources and timing. No filler or redundancy; every clause contributes.
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 4-parameter tool with no output schema, the description covers the essential context: what it does, what sources exist, prerequisites, and when to run it. It could be improved by explicitly stating the default append behavior, but overall it is complete enough for an agent to invoke correctly.
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 coverage is 100%, so the baseline is 3. The description adds meaningful detail to the 'source' enum by explaining each value (e.g., 'claude-history' is local Claude Code history, 'chatgpt' needs a conversations.json export, 'files' is a folder of writing). It also notes the path requirement for two sources, reinforcing the schema.
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 starts with 'Build or refresh the voiceprint from the user's own writing,' which clearly states the action (build/refresh) and the resource (voiceprint). It distinguishes itself from sibling tools like voice_get (retrieve) and voice_score (evaluate) by focusing on creation/update.
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 explicit timing: 'Run this once at setup, or again to fold in newer writing.' It also details the source options and prerequisites. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record something about the user's voice that measurement cannot reach -- a phrase they have banned, who they are usually writing for, a correction they just made to your draft, a running joke. Use this whenever the user says 'I wouldn't say that', 'too formal', or rewrites something you wrote. Notes persist across every rebuild of the voiceprint and tend to matter more than the statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | The rule or observation, in one or two sentences. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that notes persist across rebuilds and matter more than statistics, which is useful behavioral context. However, it does not mention return value or whether notes overwrite or append, which is a minor gap but acceptable for such a simple tool.
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 three sentences, each with a distinct role: purpose, usage triggers, and persistence context. It is front-loaded with the core function and contains no filler or repetition.
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 single-parameter tool with no output schema, the description covers the purpose, when to use it, content guidelines, and persistence behavior. It is fully self-contained and leaves no critical questions unanswered about how or why to invoke the 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?
Despite 100% schema coverage, the description significantly enhances the parameter's meaning by providing concrete examples of what to record (banned phrases, audience, corrections, running jokes). This goes far beyond the schema's generic 'rule or observation' and helps the agent craft effective notes.
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 explains that the tool records qualitative notes about the user's voice, with specific examples of what to record. This distinguishes it from sibling tools like voice_get, voice_score, and voice_learn, which handle measurement, analysis, or learning. The verb 'Record' and resource 'something about the user's voice' are concrete and unambiguous.
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?
It explicitly states when to use the tool: 'Use this whenever the user says...' with concrete trigger phrases like 'I wouldn't say that' or 'too formal'. This provides clear decision guidance, and the distinction from statistical measurement implies that this is for subjective, non-measurable feedback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a draft 0-100 for AI tells and get line-level findings. CALL THIS ON EVERY DRAFT before showing it to the user. Checks a curated slop lexicon plus structural signals -- sentence-length uniformity, paragraph shape, bullet symmetry, punctuation rates -- against THIS user's own measured baseline rather than universal rules. Above 85 reads human, below 50 is slop. Also returns the voice rules, so one call gives you both the critique and the target.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a file to score, instead of text. | |
| text | No | The draft text to score. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It richly discloses how scoring works: curated slop lexicon, structural signals, comparison against the user's baseline, and thresholds (>85 human, <50 slop). It also notes that voice rules are returned, giving the agent a complete behavioral model.
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 efficient and front-loaded: purpose in the first sentence, usage directive second, then methodology and thresholds. Each sentence earns its place with no fluff.
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 tool's complexity and lack of output schema, the description covers what it does, when to use it, how it evaluates, thresholds, and that it returns voice rules. This is complete enough for an agent to invoke it correctly.
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?
Both parameters (path and text) are fully described in the schema, so coverage is 100%. The description adds no additional parameter meaning beyond what the schema already provides, matching the baseline of 3.
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 defines the tool as scoring a draft 0-100 for AI tells and returning line-level findings. This is a specific verb+resource+output that distinguishes it from sibling voice_* tools.
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?
It explicitly states when to use the tool: 'CALL THIS ON EVERY DRAFT before showing it to the user.' This gives clear usage context, though it does not mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a voiceprint exists and how solid it is: sample count, word count, when it was built, and whether the corpus is large enough for the measurements to be stable. Use this when you are not sure the user has set being-human up yet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It uses 'Check' to imply a read-only operation and describes the information returned (sample count, word count, build time, corpus stability). However, it does not state the return format, potential errors, or any prerequisites beyond the setup implication.
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 only two sentences, front-loaded with the action, and every phrase adds value. It is concise, structured, and free of 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?
The tool is simple with no parameters and no output schema, so the description must explain what it returns. It does so by listing the data points it provides, and it gives usage context. The only gap is the lack of explicit return structure, but that is acceptable for such a simple 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?
The tool has zero parameters, and the schema is empty, so the description does not need to add meaning for parameters. The baseline of 4 for zero-parameter tools is appropriate, as there is nothing to describe.
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's function with a specific verb ('Check') and resource ('voiceprint'), and lists the exact aspects it assesses (sample count, word count, build time, corpus stability). This distinguishes it from sibling tools that get, score, verify, learn, note, or export voiceprints.
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 provides an explicit use case: 'Use this when you are not sure the user has set being-human up yet.' This gives clear context for when to invoke the tool. However, it does not mention alternatives or exclusions, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The impostor test: statistically, is this text a plausible sample of THIS user? Returns an authorship percentile against a null resampled from their own writing at the same length. Under 75 means indistinguishable from them; over 97 means it reads as someone else. This is a different question from voice_score -- that one catches AI tells, this one catches 'fluent, clean, and not you'. Run BOTH on any draft before showing it; a draft has to pass each. Also names the specific words that pushed it out of range.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to a file, instead of text. | |
| text | No | The draft text to test. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the statistical method (null resampled from the user's own writing, same length), defines thresholds (under 75, over 97), and notes that it names specific words that fall outside the range—providing thorough behavioral context.
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?
Every sentence earns its place: it defines the purpose, explains interpretation, contrasts with sibling, gives usage guidance, and mentions output. The description is dense but not wordy, and it is front-loaded with the core concept.
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 having no output schema, the description explains the return value (authorship percentile) and the additional output (specific out-of-range words). It provides enough context for the agent to understand when to use the tool and what to expect.
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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description mentions 'text' but does not elaborate on the 'path' parameter; it adds no semantic value beyond what the schema already provides.
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 identifies the tool as an authorship verification test ('impostor test') and explains its output (authorship percentile). It distinguishes itself from voice_score, making the purpose unambiguous and specific.
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 instructs to run both voice_verify and voice_score on any draft before showing it, and explains the difference in what each catches. This gives clear when-to-use and when-not-to-use guidance that differentiates from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: retrieving reusable rules (voice_get), scoring a draft for AI tells (voice_score), statistical authorship verification (voice_verify), checking corpus status (voice_status), building/refreshing the print (voice_learn), storing qualitative notes (voice_note), and exporting to other formats (voice_export). The only mild overlap is voice_get vs. voice_score both returning voice rules, but the primary purpose is clearly differentiated in the descriptions.
All tools share the consistent 'voice_' namespace prefix and use a single lowercase word after the underscore. The action words are not uniformly verb_noun (status and note are nouns), but the pattern is perfectly predictable and uniform in style, with no casing or separator mixing.
Seven tools is well within the ideal 3–15 range. Each tool covers a necessary part of the voiceprint lifecycle—setup, usage, critique, verification, notes, and export—without redundant or extraneous additions.
The set covers the full workflow from status check and voiceprint building to draft scoring, authorship verification, note capture, and export. Minor gaps exist around managing notes (no editing or deletion) and no explicit way to remove or reset the voiceprint, but these don't block core use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal MCP server for humans who create. Proof of authorship, license control.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
AI voice generation: text-to-speech and voice cloning from any MCP client.
An MCP server that integrates with Discord to provide AI-powered features.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Syedomershah99/being-human'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
