Skip to main content
Glama

Persuasion Taxonomy

Check and compare headlines, hooks, and subject lines

check_headlines
Read-onlyIdempotent

Check headlines, email subject lines, ad openings, video hooks, social post openings and first lines, and compare options against each other. For each line it tells you whether the line does its job in that spot, meaning which of the nine reader questions it answers, and whether a competitor could send it unchanged. It also shows exactly what a reader sees before the cutoff, flags anything that fails outright, and brings in evidence from thousands of real headline tests. Then it tells you what each option is betting on and which two to test. Before you call it, list the reader questions each line answers and quote the exact words doing the work. Use it whenever you write headlines, hooks or subject lines, whenever you have to choose between them, and whenever someone asks "which one is best?" You won't get a score out of ten. Nobody can predict a winner from the words alone, and that includes this tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slotYesWhere the lines will appear: email_subject, ad_opening, landing_page_headline, first_line, video_hook, social_post_open, sales_letter_headline. Each spot has its own job, and the check tells you what it is.
briefNoThe brief. The swap test needs it to tell whether a competitor could send the line unchanged, and without it no line can pass.
linesYes
followsNoWhat the reader saw just before this line, like the ad before a landing page headline, or the headline or subject before a first line.
awareness_levelNoHow much the reader already knows, on Eugene Schwartz's scale. Use unaware if they don't know they have the problem, problem_aware if they feel it, solution_aware if they know solutions exist, product_aware if they know you, and most_aware if they're ready and only need the offer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/closed-world, and the description adds substantial context beyond them: it names the nine reader questions the check reports on, the swap test, the cutoff preview, outright failure flags, and evidence pooled from thousands of real tests. It also proactively sets an expectation ("You won't get a score out of ten") that prevents misuse of the result.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and output content, and every sentence does work, including the expectation-setting line about no score out of ten. It is on the long side and the middle sequencing is a touch dense, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description fully carries the burden of describing returns: what each line is judged on, which reader questions it answers, whether a competitor could send it unchanged, the cutoff view, failure flags, evidence, and a recommended two-variant test. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80%, so the schema carries most of the burden, but the description adds real meaning: "Before you call it, list the reader questions each line answers and quote the exact words doing the work" tells the agent the required 'answers' payload must be authored by the caller. The swap-test note also clarifies why the brief matters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (check, compare) and a precisely scoped resource: headlines, email subject lines, ad openings, video hooks, social post openings/first lines. The enumeration of line types plus the comparison framing makes it easy to separate from the broader diagnose_marketing_copy sibling 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use triggers: "whenever you write headlines, hooks or subject lines, whenever you have to choose between them, and whenever someone asks 'which one is best?'". It does not name a when-not condition or point at the closest alternative (diagnose_marketing_copy), so it falls 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.