PrePublish - YouTube script QA

Server Details

Audit a YouTube script before recording: hook, pacing, drop-off risk, copy-paste rewrites.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 28 days
Last Tested: 2026-10-07 02:25
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored 2026-10-02 17:50 across 6 tools

Disambiguation4/5

audit_hook and audit_script share the 'audit a script' purpose, but the descriptions explicitly distinguish them (hook-only vs full draft, cheaper vs broader). The remaining four tools target clearly distinct concerns (authenticity, policy, runtime, retrieval), so boundaries are mostly clean.

Naming Consistency3/5

Naming mixes conventions: verb_noun (audit_hook, audit_script, check_authenticity, get_audit) alongside noun-first compounds (policy_preflight, script_runtime). All snake_case and readable, but the prefix style is not predictable across the set.

Tool Count5/5

Six tools is well-scoped for a script QA service, covering the distinct analysis angles without bloat. Each tool earns its place and nothing feels redundant or padded.

Completeness4/5

The surface covers hook scoring, full audit, authenticity, policy preflight, runtime estimation, and async result retrieval, which is solid coverage of the domain. Minor gap: no tool for an overall consolidated report or channel-level comparison, but core lifecycle (start audit, fetch result) is present.

Available Tools

6 tools

audit_hookScore the opening of a YouTube scriptAInspect

Score just the opening lines of a YouTube script: how much attention each sentence pulls, whether it opens a curiosity gap, how far away the payoff sits, plus the top issues and rewritten alternatives. Choose this when the user shares only a hook or opening paragraph, or wants a fast second opinion before auditing a whole draft. Cheaper and narrower than audit_script. This is a text-only check of an unrecorded script. It maps relative attention risk inside the draft. It does not measure or predict published YouTube retention, and it cannot account for delivery, editing, thumbnail, topic or distribution.

ParametersJSON Schema

Name	Required	Description
`email`	No	Only needed once the free anonymous hook check for the day is used. Prepublish stores this address and may send a short series of follow-up emails about the check that include an unsubscribe link. Ask the user; never invent it. When the caller is authenticated with a Prepublish API key the result comes back in the conversation instead, so do not ask for an address in that case.
`niche`	No	Channel niche, only if the user said it. Sharpens the comparison.
`hook_text`	Yes	The opening lines exactly as written, ideally the first 15 to 30 seconds of speech.

Output Schema

ParametersJSON Schema

Name	Required	Description
`hook`	Yes	The hook evaluation.
`notice`	Yes	The scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations are minimal (readOnlyHint false, openWorldHint true, destructiveHint false), so the description carries real load and does so: it discloses the email capture/retention side effect conceptually, frames the check as text-only on an unrecorded script, and bounds the scope by disclaiming retention prediction. What is missing is the concrete rate-limit/free-anonymous-quota behavior, which is only described in the schema parameter, not the tool description. No contradiction with annotations; the write-ish side effect is consistent with readOnlyHint=false.

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?

Purpose and when-to-use are front-loaded in the first two sentences, which is correct ordering. The second sentence is a long run-on of five comma-linked clauses, and the trailing limitation list is dense, but nearly every clause adds routing or scope information rather than 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 an output schema present, return values need not be explained, and the description covers the remaining agent needs: what the score covers, when to select it versus the sibling, the relative cost, and the explicit limits of the analysis. Nothing required to invoke it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters (email, niche, hook_text) are already documented in the schema, including the email/auth nuance. The description adds no parameter-level detail beyond what the schema provides (e.g., hook_text length or format guidance is not repeated). Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Opens with a specific verb and resource ("Score just the opening lines of a YouTube script") and enumerates the actual outputs: attention pull per sentence, curiosity gap, payoff distance, issues, rewrites. It explicitly positions itself against the sibling audit_script as "cheaper and narrower," so an agent can distinguish the two 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 Guidelines5/5

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

States the selection condition directly: "Choose this when the user shares only a hook or opening paragraph, or wants a fast second opinion before auditing a whole draft." It also names the alternative (audit_script) and gives explicit when-not guidance by listing what the tool cannot assess (delivery, editing, thumbnail, topic, distribution).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

audit_scriptAudit a YouTube script before recordingAInspect

Run Prepublish's full audit on a YouTube script the user has already written. Returns hook, structure and pacing scores, a script-level attention-risk map naming the passages most likely to lose viewers, and a copy-paste rewrite for each flagged passage. Choose this when the user has a finished or near-finished draft and wants to know what is weak before they record. Do not use it to generate a script, to review a published video, or to check grammar. An email is optional: the result comes back in the conversation either way. This is a text-only check of an unrecorded script. It maps relative attention risk inside the draft. It does not measure or predict published YouTube retention, and it cannot account for delivery, editing, thumbnail, topic or distribution.

ParametersJSON Schema

Name	Required	Description
`email`	No	Optional. Only when the user gave an address and wants the result link by email: Prepublish stores it with the audit, emails the result link to it, and may send a short series of follow-up emails about the audit that include an unsubscribe link. Leave it out otherwise; the audit runs without it. Never invent an address. When the caller is authenticated with a Prepublish API key the account address is used, so do not ask for one in that case.
`audience`	No	Target audience, only if the user said it.
`category`	No	Video category, only if the user said it.
`script_text`	Yes	The script text as the user wrote it. Paste it verbatim; do not rewrite, summarise or clean it first.
`video_title`	Yes	The title the user plans to publish under. The audit checks whether the script delivers this promise.
`video_duration_seconds`	No	Intended runtime in seconds, only if the user stated one. Used for pacing; never assumed.

Output Schema

ParametersJSON Schema

Name	Required	Description
`notice`	Yes	The scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.
`status`	No	Present only when the audit had not settled inside this call; the value is "running".
`analysis`	No	The settled audit: status (and error_message when it failed), video_title, overall_score with hook_score, structure_score and pacing_score, ready_to_record, one_key_improvement, score_explanations, the attention_map (position_pct, hold_index, note, sentiment), the improvements in priority order (priority, category, title, location, original_quote and, for the passages on this plan, improved and why), locked_count, and policy_preflight. The script text itself and internal bookkeeping are not included. Absent while the audit is still running.
`next_step`	No	Present only when the audit is still running: what to do to collect it.
`analysis_id`	Yes	Prepublish id for this audit. Pass it to get_audit to re-read the result later.
`open_in_browser`	Yes	Permalink to the same audit on prepublish.ai.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description adds substantial non-obvious behavior: the email address is stored with the audit, a result link is emailed, follow-up emails with an unsubscribe link may be sent, and the account address is used under API-key auth. It also scopes limits precisely (text-only, unrecorded script, relative in-draft attention risk, no retention prediction, no delivery/thumbnail/topic factors).

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 outputs, then usage rules, then caveats. Efficient overall, though the limitation block is slightly repetitive ('text-only check of an unrecorded script' overlaps with the earlier draft framing) and costs more lines than strictly necessary.

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?

For a multi-field audit tool with an output schema, the description covers what it returns, when to invoke it, what it will not do, and the email side effect, and it explicitly bounds the meaning of the attention-risk score. Nothing needed to invoke 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 description coverage is 100%, so the schema already carries parameter meaning (baseline 3). The description adds value on the email parameter's side effect on delivery (the result returns in the conversation with or without it) and reinforces the 'only if the user said it' convention for audience/category/duration.

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+resource ('run Prepublish's full audit on a YouTube script') and enumerates the concrete outputs: hook/structure/pacing scores, an attention-risk map naming passages, and per-passage rewrites. Clearly distinguishable from siblings like audit_hook, script_runtime, or check_authenticity.

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 an explicit use condition (finished or near-finished draft, wants to know what is weak before recording) and explicit exclusions (not for generating a script, not for reviewing a published video, not grammar). However, it does not route the excluded cases to the sibling tools that handle them, so it stops short of full when/when-not/alternatives guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_authenticityCheck a script for reused or inauthentic content riskAInspect

Check a script against YouTube's inauthentic-content expectations: whether it reads as mass-produced, templated or repetitive, which signals fire, and what to change. Returns a score, a risk level, the firing signals with quotes, and remediation steps. Choose this when the user worries about reused content, AI-sounding scripts, or a channel that repeats a formula. This reports text-level signals only; it is not a monetisation decision and does not speak for YouTube.

ParametersJSON Schema

Name	Required	Description	Default
`script_text`	Yes	The script text as the user wrote it. Paste it verbatim; do not rewrite, summarise or clean it first.
`video_title`	Yes	The planned title.

Output Schema

ParametersJSON Schema

Name	Required	Description
`notice`	Yes	The scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.
`authenticity`	Yes	The inauthentic-content read on this script.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations (readOnlyHint=false, openWorldHint=false, destructiveHint=false) leave the agent unclear whether the call persists anything, and the description does not resolve that — it only says what is returned. It does add real behavioral context the annotations cannot: the report is text-level only, is not a monetisation decision, and does not speak for YouTube.

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

Conciseness5/5

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

Three sentences, front-loaded with purpose, then output shape, then selection criteria and caveats. Every sentence carries weight and 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 an output schema present and 100% schema coverage, the description only needs to convey purpose, scope boundaries and when to select it — all of which it does, including the caveat that it is not a monetisation ruling. Nothing an agent needs 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.

Parameters3/5

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

Schema description coverage is 100% and both parameters are documented there, including the important 'paste verbatim; do not rewrite, summarise or clean it first' instruction. The description adds no further parameter meaning, so the baseline 3 applies.

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 and resource ('Check a script against YouTube's inauthentic-content expectations') and immediately narrows the scope to text-level signals, explicitly ruling out monetisation decisions. That boundary distinguishes it from sibling audit/policy tools like policy_preflight without needing to name them.

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 trigger conditions: 'Choose this when the user worries about reused content, AI-sounding scripts, or a channel that repeats a formula.' It also implicitly excludes monetisation questions, but never names a concrete alternative tool to use instead, so it stops short of full when/when-not routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_auditCollect a Prepublish audit by idA

Read-only

Inspect

Fetch the current state of an audit that was started earlier, using the analysis_id that audit_script returned. Use this when a previous audit was still running, or when the user refers back to an audit from earlier in the conversation. It performs no new analysis and costs nothing. This is a text-only check of an unrecorded script. It maps relative attention risk inside the draft. It does not measure or predict published YouTube retention, and it cannot account for delivery, editing, thumbnail, topic or distribution.

ParametersJSON Schema

Name	Required	Description	Default
`analysis_id`	Yes	The analysis_id returned by audit_script.

Output Schema

ParametersJSON Schema

Name	Required	Description
`notice`	Yes	The scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.
`analysis`	No	The audit at whatever state it has reached: read its "status" field first, because an audit that has not settled carries no scores. Once settled it carries the projected report described on audit_script, and an audit that failed carries its error_message.
`analysis_id`	Yes	The id that was requested, echoed back.
`open_in_browser`	Yes	Permalink to the same audit on prepublish.ai.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/non-destructive/non-openWorld, and the description adds substantial context beyond them: no new analysis is performed, no cost is incurred, and it explicitly enumerates non-goals (no published retention measurement, no delivery/editing/thumbnail/topic/distribution accounting). This is unusually rich scoping for a read tool.

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 the action and the identity key, and every sentence carries routing or scope information. The final negatives list is a bit dense but serves a real disambiguation purpose rather than padding.

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?

An output schema exists, so return structure needn't be described. Combined with the annotation safety profile and the explicit non-goals, an agent has everything needed to call this correctly and to know when not to.

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

Parameters3/5

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

Schema coverage is 100% and the single parameter is already documented as 'The analysis_id returned by audit_script.' The description restates the same provenance without adding format, validity, or lifecycle detail, so baseline 3 applies.

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 and resource ('Fetch the current state of an audit') and pins the identity key to 'analysis_id that audit_script returned'. This clearly distinguishes it from the sibling audit_script, which produces the audit, and audit_hook.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Gives explicit triggers: 'when a previous audit was still running' or 'when the user refers back to an audit from earlier in the conversation'. It also clarifies cost behavior ('performs no new analysis and costs nothing'), which steers the agent away from re-running audit_script.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

policy_preflightPre-flight a script against YouTube advertiser and monetisation policyAInspect

Check a script before recording for the YouTube policy categories it may touch: which category families are implicated, the consequence family for each, a verdict and flag counts. Each category cites YouTube's own published policy page. Choose this when the user is writing about sensitive subject matter and asks whether it is safe to monetise. The quoted passages and their suggested rewrites are part of the paid audit, so the free result may return counts with locked quotes. It reports risk against published policy text; it is not a monetisation guarantee and does not speak for YouTube.

ParametersJSON Schema

Name	Required	Description	Default
`title`	No	The planned title, if the user has one. Titles are checked too.
`script`	Yes	The script text as written, at least 200 characters. Below that there is not enough context for a policy read.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes	Says which parts of the result are paid-only, so a locked field is not read as a clean pass.
`notice`	Yes	The scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.
`policy_preflight`	Yes	The policy read on this script.

TDQS

A4/5.0

Behavior4/5

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

Adds real behavioral context beyond the annotations: the free result may return counts with locked quotes because 'quoted passages and their suggested rewrites are part of the paid audit,' and it explicitly disclaims being a monetisation guarantee or speaking for YouTube. Annotations (destructiveHint=false, openWorldHint=false) do not cover this gating or scope limitation, so the disclosure is genuinely additive.

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?

Four sentences, front-loaded with the purpose and output shape before moving to selection guidance and caveats. Every sentence carries load (what it returns, when to pick it, what is locked, what it disclaims), though the phrasing is slightly dense.

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 an output schema present the description need not explain return values, and it still covers scope, selection context, paid/free gating, and an explicit liability boundary. Nothing an agent needs to invoke it correctly is missing; the 200-char rule lives in the schema.

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

Parameters3/5

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

Schema description coverage is 100%: the schema already documents title (checked too) and the 200-character minimum rationale for script. The description adds no syntax, precedence, or format detail for either parameter, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('check a script... for the YouTube policy categories it may touch') and enumerates what the result contains: category families, consequence family, verdict, flag counts. It is clear what the tool does, though it never contrasts itself with the similarly named sibling audit_script, so an agent must infer the split.

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 an explicit triggering context: 'Choose this when the user is writing about sensitive subject matter and asks whether it is safe to monetise.' That is a concrete when-to-use condition, but it names no alternatives or exclusions (e.g. when to prefer audit_script or script_runtime instead).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

script_runtimeConvert script length to spoken runtimeA

Read-only

Inspect

Convert a word count, or a pasted script, into a spoken runtime range, and convert a target runtime back into a word budget. Rates come from Prepublish's own measurement of 349 videos: 25th percentile 160 words per minute, median 181, 75th percentile 201. Choose this for "how long will this script run" or "how many words for a ten-minute video". It is arithmetic on speaking rate only: it excludes pauses, B-roll and demonstrations, so a finished edit usually runs longer.

ParametersJSON Schema

Name	Required	Description
`word_count`	No	A word count, if the user already knows it.
`script_text`	No	A script to count. Provide this or word_count or target_minutes.
`target_minutes`	No	A target runtime in minutes, to convert into a word budget.

Output Schema

ParametersJSON Schema

Name	Required	Description
`caveat`	Yes	What this arithmetic excludes. Repeat it rather than presenting a single number.
`source`	Yes	Where the rates come from, with the published write-up.
`word_count`	No	Words counted or supplied. Present when script_text or word_count was given.
`word_budget`	No	Words needed to fill the target at each rate. Present when target_minutes was given.
`target_minutes`	No	The target runtime asked for, echoed back. Present when target_minutes was given.
`runtime_minutes`	No	Spoken runtime in minutes at each rate. Present when script_text or word_count was given.
`speaking_rates_words_per_minute`	Yes	The measured rates used, in words per minute: slow is the 25th percentile, median the 50th, fast the 75th.

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the read-only, non-destructive annotations, the description discloses the calculation basis (349 videos measured, percentiles 160/181/201 wpm) and the key limitation that it is arithmetic on speaking rate only, so finished edits usually run longer. This is meaningful behavioral context not available in annotations.

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

Conciseness5/5

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

The description is front-loaded with the core function, then adds rate data, usage guidance, and a limitation. Every sentence earns its place with no redundancy.

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?

An output schema exists, so return values need not be explained. The description covers purpose, usage, limitations, and the underlying rate model, making it complete for an agent to invoke the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains each parameter. The description reinforces the three modes (word count, pasted script, target runtime) but adds no syntax or format details beyond what the schema provides. Baseline 3 is appropriate.

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?

The description states a specific verb+resource: converting word counts or scripts into runtime ranges, and target runtimes into word budgets. It clearly distinguishes the tool from unrelated siblings (audit/policy tools) and leaves no ambiguity about what it does.

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?

It gives explicit usage examples: "how long will this script run" and "how many words for a ten-minute video." It also adds a caveat that it excludes pauses, B-roll, and demonstrations, effectively signaling when the estimate is not appropriate. No alternative tools are named, but none exist among the siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 2, 2026

Changedaudit_script1 field changed

changedInput schema / properties / email / description

Previous value: -"Where the free result is sent. Prepublish stores this address with the audit, emails the result link to it, and may send a short series of follow-up emails about the audit that include an unsubscribe link. Required for every anonymous audit: the backend rejects the request without it. Ask the user; never invent it. When the caller is authenticated with a Prepublish API key the result comes back in the conversation instead, so do not ask for an address in that case."New value: +"Optional. Only when the user gave an address and wants the result link by email: Prepublish stores it with the audit, emails the result link to it, and may send a short series of follow-up emails about the audit that include an unsubscribe link. Leave it out otherwise; the audit runs without it. Never invent an address. When the caller is authenticated with a Prepublish API key the account address is used, so do not ask for one in that case."

1 tool updateSep 28, 2026

Changedaudit_hook1 field changed

changedInput schema / properties / email / description

Previous value: -"Only needed once the free anonymous hook check for the day is used. Ask the user; never invent it. When the caller is authenticated with a Prepublish API key the result comes back in the conversation instead, so do not ask for an address in that case."New value: +"Only needed once the free anonymous hook check for the day is used. Prepublish stores this address and may send a short series of follow-up emails about the check that include an unsubscribe link. Ask the user; never invent it. When the caller is authenticated with a Prepublish API key the result comes back in the conversation instead, so do not ask for an address in that case."

2 tool updatesSep 27, 2026

Changedaudit_script2 fields changed

changedInput schema / properties / email / description

Previous value: -"Where the free result is sent. Required for every anonymous audit: the backend rejects the request without it. Ask the user; never invent it. When the caller is authenticated with a Prepublish API key the result comes back in the conversation instead, so do not ask for an address in that case."New value: +"Where the free result is sent. Prepublish stores this address with the audit, emails the result link to it, and may send a short series of follow-up emails about the audit that include an unsubscribe link. Required for every anonymous audit: the backend rejects the request without it. Ask the user; never invent it. When the caller is authenticated with a Prepublish API key the result comes back in the conversation instead, so do not ask for an address in that case."

changedOutput schema / properties / analysis / description

Previous value: -"The settled audit as Prepublish returned it: status, overall, hook, structure and pacing scores, the attention-risk map, improvements and, where the plan allows, rewrites. Absent while the audit is still running."New value: +"The settled audit: status (and error_message when it failed), video_title, overall_score with hook_score, structure_score and pacing_score, ready_to_record, one_key_improvement, score_explanations, the attention_map (position_pct, hold_index, note, sentiment), the improvements in priority order (priority, category, title, location, original_quote and, for the passages on this plan, improved and why), locked_count, and policy_preflight. The script text itself and internal bookkeeping are not included. Absent while the audit is still running."

Changedget_audit1 field changed

changedOutput schema / properties / analysis / description

Previous value: -"The audit as Prepublish returned it, at whatever state it has reached. Read its \"status\" field: an audit that is not yet settled has no scores."New value: +"The audit at whatever state it has reached: read its \"status\" field first, because an audit that has not settled carries no scores. Once settled it carries the projected report described on audit_script, and an audit that failed carries its error_message."

6 tool updatesSep 20, 2026

Changedaudit_hook1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "hook": {
+      "description": "The hook evaluation.",
+      "properties": {
+        "created_at": {
+          "description": "When the evaluation was produced.",
+          "type": "string"
+        },
+        "evaluation_id": {
+          "description": "Prepublish id for this hook evaluation.",
+          "type": "string"
+        },
+        "grade": {
+          "description": "Letter grade for the opening.",
+          "type": "string"
+        },
+        "hook_text": {
+          "description": "The opening lines that were scored, echoed back.",
+          "type": "string"
+        },
+        "model_used": {
+          "description": "Which model produced this evaluation.",
+          "type": "string"
+        },
+        "niche": {
+          "description": "The niche the hook was compared against, when one was supplied.",
+          "type": "string"
+        },
+        "one_sentence_verdict": {
+          "description": "The single-sentence read on the hook.",
+          "type": "string"
+        },
+        "overall_score": {
+          "description": "Score for the opening as a whole.",
+          "type": "integer"
+        },
+        "rewrites": {
+          "description": "Alternative openings, each with its style and why that version works.",
+          "items": {
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "sentences": {
+          "description": "Per-sentence breakdown: the quote, its attention pull, its curiosity gap, how far off the payoff sits, and a note.",
+          "items": {
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "top_issues": {
+          "description": "The problems worth fixing first, each with a headline, the quote it applies to, and why it costs attention.",
+          "items": {
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "notice": {
+      "description": "The scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "notice",
+    "hook"
+  ],
+  "type": "object"
+}

Changedaudit_script1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "analysis": {
+      "description": "The settled audit as Prepublish returned it: status, overall, hook, structure and pacing scores, the attention-risk map, improvements and, where the plan allows, rewrites. Absent while the audit is still running.",
+      "type": "object"
+    },
+    "analysis_id": {
+      "description": "Prepublish id for this audit. Pass it to get_audit to re-read the result later.",
+      "type": "string"
+    },
+    "next_step": {
+      "description": "Present only when the audit is still running: what to do to collect it.",
+      "type": "string"
+    },
+    "notice": {
+      "description": "The scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.",
+      "type": "string"
+    },
+    "open_in_browser": {
+      "description": "Permalink to the same audit on prepublish.ai.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Present only when the audit had not settled inside this call; the value is \"running\".",
+      "type": "string"
+    }
+  },
+  "required": [
+    "notice",
+    "analysis_id",
+    "open_in_browser"
+  ],
+  "type": "object"
+}

Changedcheck_authenticity1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "authenticity": {
+      "description": "The inauthentic-content read on this script.",
+      "properties": {
+        "analysis_id": {
+          "description": "Prepublish id for this check.",
+          "type": "string"
+        },
+        "created_at": {
+          "description": "When the check was produced.",
+          "type": "string"
+        },
+        "heuristic_report": {
+          "description": "The deterministic layer behind the score, passed through as the backend produced it."
+        },
+        "override_note": {
+          "description": "Present when the banded result was overridden, explaining why.",
+          "type": "string"
+        },
+        "remediation": {
+          "description": "What to change, each with the current passage, the fix, and why it matters.",
+          "items": {
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "risk_level": {
+          "description": "Banded risk level behind the score.",
+          "type": "string"
+        },
+        "score": {
+          "description": "Authenticity score for the script.",
+          "type": "integer"
+        },
+        "signals": {
+          "description": "Each signal that fired, with its name, severity, reasoning and the quote that triggered it.",
+          "items": {
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "verdict": {
+          "description": "The short verdict in words.",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "notice": {
+      "description": "The scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "notice",
+    "authenticity"
+  ],
+  "type": "object"
+}

Changedget_audit1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "analysis": {
+      "description": "The audit as Prepublish returned it, at whatever state it has reached. Read its \"status\" field: an audit that is not yet settled has no scores.",
+      "type": "object"
+    },
+    "analysis_id": {
+      "description": "The id that was requested, echoed back.",
+      "type": "string"
+    },
+    "notice": {
+      "description": "The scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.",
+      "type": "string"
+    },
+    "open_in_browser": {
+      "description": "Permalink to the same audit on prepublish.ai.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "notice",
+    "analysis_id",
+    "open_in_browser"
+  ],
+  "type": "object"
+}

Changedpolicy_preflight1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "note": {
+      "description": "Says which parts of the result are paid-only, so a locked field is not read as a clean pass.",
+      "type": "string"
+    },
+    "notice": {
+      "description": "The scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.",
+      "type": "string"
+    },
+    "policy_preflight": {
+      "description": "The policy read on this script.",
+      "properties": {
+        "cached": {
+          "description": "True when this exact script and title had already been checked and the stored result was replayed.",
+          "type": "boolean"
+        },
+        "created_at": {
+          "description": "When the pre-flight was produced.",
+          "type": "string"
+        },
+        "preflight": {
+          "description": "The result itself: a verdict of \"no_matches\", \"review_suggested\" or \"high_matches\", the flags, counts_by_category, total_flags, whether the passages are locked, the rubric version it was scored against, the full category rubric with its citations, and the scope statement that must be shown with it.",
+          "type": "object"
+        },
+        "preflight_id": {
+          "description": "Prepublish id for this pre-flight.",
+          "type": "string"
+        },
+        "title": {
+          "description": "The title that was checked, when one was supplied.",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "notice",
+    "policy_preflight",
+    "note"
+  ],
+  "type": "object"
+}

Changedscript_runtime1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "caveat": {
+      "description": "What this arithmetic excludes. Repeat it rather than presenting a single number.",
+      "type": "string"
+    },
+    "runtime_minutes": {
+      "description": "Spoken runtime in minutes at each rate. Present when script_text or word_count was given.",
+      "properties": {
+        "fast": {
+          "description": "Runtime at the fast rate.",
+          "type": "number"
+        },
+        "median": {
+          "description": "Runtime at the median rate.",
+          "type": "number"
+        },
+        "slow": {
+          "description": "Runtime at the slow rate.",
+          "type": "number"
+        }
+      },
+      "required": [
+        "fast",
+        "median",
+        "slow"
+      ],
+      "type": "object"
+    },
+    "source": {
+      "description": "Where the rates come from, with the published write-up.",
+      "type": "string"
+    },
+    "speaking_rates_words_per_minute": {
+      "description": "The measured rates used, in words per minute: slow is the 25th percentile, median the 50th, fast the 75th.",
+      "properties": {
+        "fast": {
+          "description": "75th percentile speaking rate.",
+          "type": "number"
+        },
+        "median": {
+          "description": "Median speaking rate.",
+          "type": "number"
+        },
+        "slow": {
+          "description": "25th percentile speaking rate.",
+          "type": "number"
+        }
+      },
+      "required": [
+        "fast",
+        "median",
+        "slow"
+      ],
+      "type": "object"
+    },
+    "target_minutes": {
+      "description": "The target runtime asked for, echoed back. Present when target_minutes was given.",
+      "type": "number"
+    },
+    "word_budget": {
+      "description": "Words needed to fill the target at each rate. Present when target_minutes was given.",
+      "properties": {
+        "fast": {
+          "description": "Word budget at the fast rate.",
+          "type": "integer"
+        },
+        "median": {
+          "description": "Word budget at the median rate.",
+          "type": "integer"
+        },
+        "slow": {
+          "description": "Word budget at the slow rate.",
+          "type": "integer"
+        }
+      },
+      "required": [
+        "fast",
+        "median",
+        "slow"
+      ],
+      "type": "object"
+    },
+    "word_count": {
+      "description": "Words counted or supplied. Present when script_text or word_count was given.",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "speaking_rates_words_per_minute",
+    "source",
+    "caveat"
+  ],
+  "type": "object"
+}

2 tool updatesSep 20, 2026

Changedaudit_hook1 field changed

changedInput schema / properties / email / description

Previous value: -"Only needed once the free anonymous hook check for the day is used. Ask the user; never invent it."New value: +"Only needed once the free anonymous hook check for the day is used. Ask the user; never invent it. When the caller is authenticated with a Prepublish API key the result comes back in the conversation instead, so do not ask for an address in that case."

Changedaudit_script1 field changed

changedInput schema / properties / email / description

Previous value: -"Where the free result is sent. Required for every anonymous audit: the backend rejects the request without it. Ask the user; never invent it."New value: +"Where the free result is sent. Required for every anonymous audit: the backend rejects the request without it. Ask the user; never invent it. When the caller is authenticated with a Prepublish API key the result comes back in the conversation instead, so do not ask for an address in that case."

1 tool updateSep 19, 2026

Changedaudit_script1 field changed

changedInput schema / properties / email / description

Previous value: -"Where the free result is sent. Required for every anonymous audit — the backend rejects the request without it. Ask the user; never invent it."New value: +"Where the free result is sent. Required for every anonymous audit: the backend rejects the request without it. Ask the user; never invent it."

6 tool updatesSep 10, 2026
- First observedaudit_hook
- First observedaudit_script
- First observedcheck_authenticity
- First observedget_audit
- First observedpolicy_preflight
- First observedscript_runtime

Related MCP Connectors

BanProof AI AOAuthDeprecated
io.github.NimishRangani
Audit creator scripts for TikTok Shop and Amazon policy violations. Returns flags and safe rewrites.
Web Scraping
21
RetentionRail AOAuth
com.retentionrail
Research competitors and trends, write scripts, and screen videos before you publish.
Marketing Image & Video Processing Social Media
1
framesail B
com.framesail
Create long-form YouTube videos end to end: script, storyboard, voiceover, final MP4.
Image & Video Processing Multimedia Processing
283
youtube-growth A
com.dapdip
Audits any YouTube channel against its own history. Every claim carries its sample size.
Social Media Entertainment & Media Research & Data
51

Related MCP Servers

PrePublish MCP serverofficial
Entertainment & Media Marketing
prepublish
A
license
A
quality
B
maintenance
Enables YouTube script QA before recording by auditing drafts for attention risk, authenticity, policy compliance, and runtime, with actionable rewrites.
Updated 12 days ago (2026-09-24 16:35 UTC)
6
37 npm
MIT
banproof-mcp
Legal & Compliance Marketing
Media-Studios
A
license
Not graded
quality
B
maintenance
Audit TikTok Shop and Amazon affiliate video scripts for policy violations. Flags risky claims and suggests safe rewrites.
Updated 8 days ago (2026-09-29 01:28 UTC)
MIT
pinescript-audit-mcp
Code Analysis Finance Testing & QA Tools
tylerscomic-lab
A
license
Not graded
quality
C
maintenance
Enables static auditing of Pine Script v6 strategies to catch backtest-vs-live divergence traps before deployment, returning specific lines and plain-English explanations. It identifies fill-timing, ATR-smoothing, lookahead bias, VWAP-anchoring drift, exit-drift, and v6 syntax issues.
Updated 2 months ago (2026-07-27 16:42 UTC)
MIT
Growth Hacker MCP
Marketing Social Media Content Management Systems
samusilv
F
license
B
quality
D
maintenance
Enables creators and marketers to generate viral social media hooks, format text into Twitter threads with proper character limits, and audit sales copy with actionable feedback on power words and CTAs.
Updated 10 months ago (2025-11-24 01:24 UTC)
3
-