Tests whether your message will stick: grades readability and memorability before you send.
Scored across 2 tools
The tools have distinct core purposes: check_if_it_sticks diagnoses reception with scores and questions, while make_it_stick transforms a draft into a stickier version. Their overlap (both use cold readers and can return questions_first) is explicitly clarified by cross-references in the descriptions, leaving only mild room for confusion about when to use which.
Both names are snake_case, verb-first, and share the 'it_stick(s)' theme, making them predictable. The minor structural difference (check_if_it_sticks includes a conditional clause, make_it_stick does not) is a small deviation but still readable and consistent overall.
Two tools is borderline thin for the stated purpose; while each tool is substantial and covers a distinct operation (diagnose vs. transform), the surface feels minimal. Additional operations like history, comparison, or settings could earn their place but are absent.
The core loop of testing a draft and then transforming it is fully covered, including question-answer cycles and skip options. Minor gaps exist (e.g., no batch checks, saved history, or side-by-side draft comparison), but agents can work around these for the primary workflow.
Use this when someone asks whether words they are about to send will land: 'Will this email land well?', 'How does this come across?', 'Could this be misunderstood?', 'Does this sound too harsh?', 'What might my manager misunderstand?' Three cold readers (a distracted stranger, a skeptic, and the target reader), each reading cold and never seeing the others, test how the message is actually received against the sender's stated goal. QUESTIONS FIRST: when the words leave gaps only the author can fill (the readers cannot find the point, the proof, or the specifics), the first result has status 'questions_first' and carries up to three short questions built from the readers' own complaints about this text, plus what the readers heard and where they split. Ask the author those questions, then call again with the same text and motivation plus answers to get the sharper, enriched verdict; if the author would rather not answer, call again with skip_questions true to get the verdict on the words as they stand. A verdict returns four plain grades out of 5, graded directly by the same readers in the same cold read (Easy to read, Holds your attention, The point lands, You'd pass it on; medians across the three readers), for conversation moments (a what's new update, a hard text) a walk_away pair: the thought the author wants the reader to leave with, from the goal, against the thought the readers may actually leave with, from what they heard, the core the readers heard (or the plain split when they heard different points), the readers' own notes including where they split, six SUCCESs medians with the spread between readers and a one-line reason each (the diagnostic layer underneath the plain grades), starter forms only (a proverb line, a curiosity-gap opener, a 3-4 sentence mini-story, concrete swaps for abstract phrases), the one prioritized fix for the element that most blocks the stated goal, and after_text: the draft copied exactly with only that one fix applied by a dedicated guarded step, when the bound passes (null when the bound discards it, with after_reason saying why; changed_lines counts the lines that differ). The tool never rewrites the draft in full; for the finished version itself, call make_it_stick, which returns the transformation cold readers carried away best (the same readers feed it). Do not use this for shortening, grammar fixes, translation, or generic 'make this clearer' rewriting; the host does those itself. Use it only to test how a finished draft will be received. Your words are not recorded or kept; the server keeps only a daily count of how many checks ran (integers, no text). The three readers run on Cloudflare Workers AI (Meta Llama 3.3 70B); under Cloudflare's published Workers AI terms, your text is not retained once it is no longer needed to answer, and it is never used to train AI models. Show the human the questions, scores, starters, and after_text as returned; the human decides what to send, and the tool sends nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The exact words to check: a message, note, toast, post, or pitch. A few sentences up to about 900 words. | |
| moment | No | Optional moment name, e.g. 'what's new', 'recommend something', 'a story I tell', 'say thanks', 'ask or invite', 'a hard text'. Helps the target reader sit in the right seat. | |
| answers | No | Answers to a previous questions_first result, in the author's own words. Pass the same text and motivation, plus these, to get the enriched verdict. | |
| motivation | Yes | One line: what should these words do? Who should do, feel, or remember what? Example: 'Get a friend to actually try the book I loved.' | |
| skip_questions | No | Set true when the author declined the follow-up questions: returns the verdict on the words as they stand. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the read-only annotation: it explains the three cold readers, the questions_first flow, verdict components, after_text guarding, and the bound/null behavior. It also discloses that text is not retained and that only an integer daily count is kept, which is valuable 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?
The trigger and main workflow are front-loaded, and most sentences carry useful information for a complex tool with no output schema. However, it is a very dense single paragraph with an extensive output inventory, which makes it harder to parse than necessary.
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?
There is no output schema, so the description must explain return behavior; it does so in detail, including questions_first, four grades, SUCCESs medians, walk_away, starters, prioritized fix, after_text, and null bounds. It also covers privacy, sibling routing, and limitations, making it complete for this 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 coverage is 100%, so the basic parameter meanings are already documented. The description adds workflow semantics that the schema does not fully convey: pass the same text and motivation with answers to enrich the verdict, or use skip_questions true when the author declines.
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 states a specific verb and resource: testing how a finished draft will be received by cold readers against the sender's goal. It explicitly distinguishes itself from the sibling make_it_stick and from host-side editing tasks such as shortening or grammar fixes.
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 gives concrete trigger phrases such as 'Will this email land well?' and explicit exclusions: do not use for shortening, grammar, translation, or generic rewriting. It also names make_it_stick as the alternative for producing a finished rewrite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hand it a draft and its goal; get back the version that sticks. The tool scans the draft for its real point (every part of it, human stakes first), then writes three transformations: a CONCRETE COMPARISON (the key fact restated as something the reader can see, the popcorn move), a CORE COMPRESSION (the one line the reader must repeat, like 'School is cancelled'), and a SCENE (one concrete moment built only from what the draft holds). A code fact gate drops any transformation whose numbers are not stated in the draft or a plain derivation of stated numbers; nothing is ever invented. Then cold readers pick the winner by a gist test: each candidate is read cold, the reader's one-line gist is scored against the point and the key fact, and the best-carrying version wins. The author's ORIGINAL competes as a candidate and can win outright: status 'already_sticks' means the words already stick and the original is the version to send. If the scan finds the core is unreachable without inventing (the draft needs a name, a scene, or an identity line only the author holds), the first result has status 'questions_first' with up to three short questions; pass the author's answers back as answers on a second call, or set skip_questions true to transform the words as they stand. The result returns the winning version with its kind label, the original alongside, the losing transformations as alternates, and what a cold reader carried away from the winner. Takes about half a minute: cold readers are not instant. Use check_if_it_sticks instead when the human wants the diagnosis and scores first. Your words are not recorded or kept; the server keeps only daily counts of how many runs happened (integers, no text). The readers run on Cloudflare Workers AI (Meta Llama 3.3 70B); under Cloudflare's published Workers AI terms, your text is not retained once it is no longer needed to answer, and it is never used to train AI models.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | One line: what should these words do? Who should do, feel, or remember what? Example: 'Get parents to thank a teacher this week.' | |
| text | Yes | The draft to transform, in the user's own words: a message, note, toast, post, or pitch. A few sentences up to about 900 words. | |
| answers | No | Answers to a previous questions_first result, in the author's own words. Pass the same text and goal, plus these, to run the transformation with the seed material included. | |
| audience | No | Optional: who it is for, named plainly, not 'everyone'. Example: 'my team at work'. | |
| skip_questions | No | Set true when the author declined the seed questions: transforms the words as they stand. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and non-destructive annotations, the description discloses the internal workflow: fact gating, cold-reader scoring, original-as-candidate comparison, possible statuses, runtime, data-retention limits, and the model provider. It gives the agent enough behavioral context to set expectations and handle the multi-step flow.
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 front-loaded with the core promise and then explains the transformation pipeline, statuses, and privacy terms. It is longer than necessary for a simple tool, but the complexity and multi-step workflow justify most sentences; a few examples and asides could be trimmed.
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?
There is no output schema, so the description must explain returns, and it does: winning version, kind label, original, alternates, cold-reader takeaway, and the already_sticks and questions_first statuses. Given the tool's complexity, the definition 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?
Schema coverage is already 100%, so the schema documents each parameter. The description adds meaningful semantics for answers and skip_questions, explaining that answers seed a second call after a questions_first result and that skip_questions transforms the draft as-is. It adds less for text and goal, but overall it goes beyond 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 opens with a specific verb-and-resource transformation: hand it a draft and goal, receive the version that sticks. It also names the sibling tool check_if_it_sticks and explains the different use case, so the agent can distinguish them 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?
It explicitly routes the agent: use this tool for transformation, use check_if_it_sticks when the human wants diagnosis and scores first. It also explains the questions_first follow-up path and skip_questions behavior, so the agent knows how to handle each outcome.
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.
check_if_it_sticksmake_it_stickAudits outbound emails for clarity, respect, and higher reply rates
Plan and check marketing copy against the nine questions every reader asks. Free, no API key.
Scores text for substance, depth, and clarity in under 25ms.
Build a voice from your own texts, measure whether a text still sounds like you, then write in it.
Add one secure layer between your agents and this server.
