Skip to main content
Glama

PrePublish - YouTube script QA

by ai.prepublish
OverviewDiscussionsAdmin

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 50 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: hook-only audit vs full script audit, authenticity check, policy preflight, runtime calculation, and fetching an existing audit. The descriptions explicitly state when to choose each and how overlapping-sounding tools differ. An agent should be able to select the right tool without guessing.

Naming Consistency4/5

All names use consistent snake_case, which is predictable and readable. Most follow a verb_noun pattern (audit_hook, audit_script, check_authenticity, get_audit), but policy_preflight and script_runtime are noun compounds rather than verb-led names. This is a minor deviation rather than a real inconsistency.

Tool Count5/5

Six tools are well scoped for a YouTube script QA server, with each tool covering a distinct check or retrieval operation. None feels redundant or trivial, and the set is small enough to stay easy to navigate.

Completeness4/5

The surface covers the core QA lifecycle: hook audit, full script audit, retrieval of prior audits, authenticity risk, policy risk, and runtime estimation. Minor gaps remain, such as no audit-listing or comparison operation, but agents can work around those with the existing tools.

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.

NameRequiredDescriptionDefault
emailNoOnly 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.
nicheNoChannel niche, only if the user said it. Sharpens the comparison.
hook_textYesThe opening lines exactly as written, ideally the first 15 to 30 seconds of speech.

Output Schema

NameRequiredDescription
hookYesThe hook evaluation.
noticeYesThe 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.

NameRequiredDescriptionDefault
emailNoOptional. 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.
audienceNoTarget audience, only if the user said it.
categoryNoVideo category, only if the user said it.
script_textYesThe script text as the user wrote it. Paste it verbatim; do not rewrite, summarise or clean it first.
video_titleYesThe title the user plans to publish under. The audit checks whether the script delivers this promise.
video_duration_secondsNoIntended runtime in seconds, only if the user stated one. Used for pacing; never assumed.

Output Schema

NameRequiredDescription
noticeYesThe scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.
statusNoPresent only when the audit had not settled inside this call; the value is "running".
analysisNoThe 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 and, for the passages on this plan, location, original_quote, improved and why; a locked passage outside ChatGPT carries only priority, category and title, and which line it points to comes with the unlock), locked_count, and policy_preflight. The script text itself and internal bookkeeping are not included. Absent while the audit is still running.
next_stepNoPresent only when the audit is still running: what to do to collect it.
unlock_urlNoPresent only when part of this result is locked on the caller's plan: where the user pays to unlock it. Absent when nothing is locked.
analysis_idYesPrepublish id for this audit. Pass it to get_audit to re-read the result later.
unlock_offerNoPresent with unlock_url: the one sentence to relay when offering it.
open_in_browserYesPermalink to the same audit on prepublish.ai.

TDQS

A4.3/5.0
Behavior4/5

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

Adds substantial context beyond annotations: the optional email side effect (storage, emailing the link, follow-up series), that results come back in-conversation regardless, and honest limits (text-only, doesn't predict published retention, ignores delivery/editing/thumbnail). No contradiction with readOnlyHint=false/destructiveHint=false — the audit creates stored results and optional emails, which is consistent with non-destructive write.

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 output, then usage rules. The trailing caveat chain (doesn't measure retention, can't account for delivery/editing/...) is valuable but slightly verbose.

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

Completeness4/5

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

Output schema exists so return values needn't be explained, yet behavior and limits are well covered. Complete enough for correct invocation; minor redundancy with the rich 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%, including a detailed email param description, so baseline is 3. The description reinforces that email is optional and the audit runs without it, but adds little beyond the schema.

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 ("Run Prepublish's full audit on a YouTube script") and enumerates the outputs: scores, attention-risk map, rewrites. Clearly distinguishes itself from generation/review/grammar-check siblings.

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?

Explicitly says when to choose it (finished or near-finished draft, wants to know what is weak before recording) and lists three concrete exclusions: generating a script, reviewing a published video, checking grammar. Routing is unambiguous.

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.

NameRequiredDescriptionDefault
script_textYesThe script text as the user wrote it. Paste it verbatim; do not rewrite, summarise or clean it first.
video_titleYesThe planned title.

Output Schema

NameRequiredDescription
noticeYesThe scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.
authenticityYesThe 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.

NameRequiredDescriptionDefault
analysis_idYesThe analysis_id returned by audit_script.

Output Schema

NameRequiredDescription
noticeYesThe scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.
analysisNoThe 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.
unlock_urlNoPresent only when part of this result is locked on the caller's plan: where the user pays to unlock it. Absent when nothing is locked.
analysis_idYesThe id that was requested, echoed back.
unlock_offerNoPresent with unlock_url: the one sentence to relay when offering it.
open_in_browserYesPermalink to the same audit on prepublish.ai.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial scope detail beyond them: no new analysis, zero cost, no persistence ('unrecorded script'), plus an explicit list of what it cannot measure (published retention, delivery, editing, thumbnail, topic, distribution). This is exactly the limitation disclosure an agent needs to avoid misusing 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?

Purpose is front-loaded in the first clause, and the cost/limitation sentences each carry real decision value. The trailing enumeration of six things it can't account for is somewhat list-heavy, but not wasteful for a tool where over-trusting the result is the main risk.

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?

Output schema exists, so return values need not be described, and annotations carry the safety profile. The description supplies the remaining gaps: provenance of the id, when to call it, cost, and the full boundary of what the audit does and does not cover.

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 the single parameter is already documented as 'The analysis_id returned by audit_script.' The description restates that provenance but adds no format, constraint, or failure-mode detail beyond the schema, 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?

Specific verb+resource ('Fetch the current state of an audit') plus the retrieval key, and it explicitly scopes the operation as a lookup of an audit 'started earlier' rather than a new run. 'This is a text-only check of an unrecorded script' further pins down what the resource actually is.

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?

Names two concrete triggers: 'when a previous audit was still running' and 'when the user refers back to an audit from earlier in the conversation.' It also implies the exclusion ('performs no new analysis', id comes from audit_script), though it never explicitly says to use audit_script instead when starting fresh.

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.

NameRequiredDescriptionDefault
titleNoThe planned title, if the user has one. Titles are checked too.
scriptYesThe script text as written, at least 200 characters. Below that there is not enough context for a policy read.

Output Schema

NameRequiredDescription
noteYesSays which parts of the result are paid-only, so a locked field is not read as a clean pass.
noticeYesThe scope limit that accompanies every Prepublish result. Repeat it to the user rather than dropping it.
unlock_urlNoPresent only when part of this result is locked on the caller's plan: where the user pays to unlock it. Absent when nothing is locked.
unlock_offerNoPresent with unlock_url: the one sentence to relay when offering it.
policy_preflightYesThe policy read on this script.

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing a freemium split (quoted passages and rewrites are paid; the free result may return counts with locked quotes), a sourcing guarantee (each category cites YouTube's published policy page), and scope limits (not a monetisation guarantee, does not speak for YouTube). The annotations only say readOnlyHint=false, openWorldHint=false, destructiveHint=false, so this added context is genuinely valuable and consistent with them.

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-loads what it does and what it returns, then adds when-to-use, paywall behavior, and a disclaimer. Four sentences of mostly distinct content; the final disclaimer sentence is slightly defensive but earns its place by bounding the tool's authority.

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 needn't enumerate return values, and it still sketches them. Combined with full schema coverage and the paywall/limits disclosure, an agent has everything needed to decide and call 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 coverage is 100%, so both parameters (title, script) are already fully documented including the 200-character minimum rationale. The description adds nothing about parameter format or meaning, so the baseline of 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 — pre-flight a script against YouTube policy categories — and previews the exact output shape (category families, consequence family, verdict, flag counts). The monetisation framing distinguishes it from generic siblings like audit_script or check_authenticity without the agent needing to open a 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 an explicit trigger: 'Choose this when the user is writing about sensitive subject matter and asks whether it is safe to monetise.' That is a clear use condition, but it names no alternative sibling or when-not-to-use case, so it stops short of full routing guidance.

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.

NameRequiredDescriptionDefault
word_countNoA word count, if the user already knows it.
script_textNoA script to count. Provide this or word_count or target_minutes.
target_minutesNoA target runtime in minutes, to convert into a word budget.

Output Schema

NameRequiredDescription
caveatYesWhat this arithmetic excludes. Repeat it rather than presenting a single number.
sourceYesWhere the rates come from, with the published write-up.
word_countNoWords counted or supplied. Present when script_text or word_count was given.
word_budgetNoWords needed to fill the target at each rate. Present when target_minutes was given.
target_minutesNoThe target runtime asked for, echoed back. Present when target_minutes was given.
runtime_minutesNoSpoken runtime in minutes at each rate. Present when script_text or word_count was given.
speaking_rates_words_per_minuteYesThe 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. 1 tool update
    • Changedaudit_script1 field changed
      • changedOutput schema / properties / analysis / description
        Previous 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."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 and, for the passages on this plan, location, original_quote, improved and why; a locked passage outside ChatGPT carries only priority, category and title, and which line it points to comes with the unlock), locked_count, and policy_preflight. The script text itself and internal bookkeeping are not included. Absent while the audit is still running."
  2. 3 tool updates
    • Changedaudit_script2 fields changed
      • addedOutput schema / properties / unlock_offer
        Added value: +{
+  "description": "Present with unlock_url: the one sentence to relay when offering it.",
+  "type": "string"
+}
      • addedOutput schema / properties / unlock_url
        Added value: +{
+  "description": "Present only when part of this result is locked on the caller's plan: where the user pays to unlock it. Absent when nothing is locked.",
+  "type": "string"
+}
    • Changedget_audit2 fields changed
      • addedOutput schema / properties / unlock_offer
        Added value: +{
+  "description": "Present with unlock_url: the one sentence to relay when offering it.",
+  "type": "string"
+}
      • addedOutput schema / properties / unlock_url
        Added value: +{
+  "description": "Present only when part of this result is locked on the caller's plan: where the user pays to unlock it. Absent when nothing is locked.",
+  "type": "string"
+}
    • Changedpolicy_preflight2 fields changed
      • addedOutput schema / properties / unlock_offer
        Added value: +{
+  "description": "Present with unlock_url: the one sentence to relay when offering it.",
+  "type": "string"
+}
      • addedOutput schema / properties / unlock_url
        Added value: +{
+  "description": "Present only when part of this result is locked on the caller's plan: where the user pays to unlock it. Absent when nothing is locked.",
+  "type": "string"
+}
  3. 1 tool update
    • Changedaudit_script2 fields changed
      • addedInput schema / properties / audience / maxLength
        Added value: +500
      • addedInput schema / properties / category / maxLength
        Added value: +500
  4. 1 tool update
    • 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."
  5. 1 tool update
    • 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."
  6. 2 tool updates
    • 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."
  7. 6 tool updates
    • 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"
+}
  8. 2 tool updates
    • 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."
  9. 1 tool update
    • 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."
  10. 6 tool updates
    • First observedaudit_hook
    • First observedaudit_script
    • First observedcheck_authenticity
    • First observedget_audit
    • First observedpolicy_preflight
    • First observedscript_runtime

Related MCP Connectors

Related MCP Servers

  • pinescript-audit-mcp

    tylerscomic-lab
    A
    license
    Not graded
    quality
    D
    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.
    MIT

  • long-video-mcp

    Ehmad9
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables Claude to plan, script, pace, and package long-form videos by splitting a target duration into structured segments, saving and timing narration against a word-per-minute budget, tracking project progress, and generating YouTube chapter timestamps, shot lists, and production checklists.
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources