NewsBlog Composer

Final step. Everything needed to publish, in one block. Returns the title, the Blogger labels line, the custom permalink slug, the search description, the image alt text, and `gemini_image_prompt` - a paste-ready prompt for Gemini with brand names already stripped, so the banner cannot reproduce a real trademark. `image_style` MUST be the style the USER picked. Leave it empty and this tool asks them directly, through the client, and waits for the answer - do not fill it in yourself. The styles it offers are listed in the result under ask_the_user_about_the_image - show the user that list rather than a list written here, which goes stale the moment a style is added. With no style chosen there is no image prompt in the result and save_and_present refuses the pack, because a banner the user was never asked about is the wrong banner. `image_concepts`: describe what the banner should show in plain words (the objects and ideas, not the company names), drawn from the article you just wrote. `banner_text` shortens the headline for the image; `banner_kicker` adds a smaller second line. Pass the result to save_and_present as `pack` and it is written to publish-pack.md alongside the post.

Step 9. Render the HTML body and both JSON-LD blocks, then check them. article: {headline, description (110-160 chars, used as the meta description), intro:[str,str] (exactly two), sections:[{heading, paragraphs:[str], bullets?:[str]}] - TWO or THREE sections, each with TWO to FOUR paragraphs, and the whole body must come to 1000-1300 words, cta (one closing sentence that must contain CTA_LINK_TEXT verbatim so it renders as a link), date_published?, author?, slug?, url?, meta_title?, section?, language?, include_h1?} faq: [{question, answer}] - 4 to 8 entries image: {url, alt, title?, caption?} - url must be the public https URL references: [{title, url, publisher?}] - real fetched URLs only keywords: the primary and secondary keywords from seo_keywords; they go into NewsArticle.keywords and come back in `meta` for save_and_present Pure templating, no model call. Renders the house body format: 720px container, inline styles, banner, byline, hr-separated H2 sections, FAQ as H3/P pairs, references as an ordered list. By default the body carries NO H1 because Blogger renders the post title itself - set BODY_INCLUDES_H1=true if your platform does not. Returns `paste_block`, which is both JSON-LD scripts followed by the body, ready to paste into the post editor, and `meta` - pass that straight to save_and_present so the head, the schema and the body cannot drift apart. Returns validation.issues listing every mismatch found: FAQ questions that differ between the HTML and the FAQPage schema, an image URL that differs between the <img> tag and NewsArticle.image, references missing from the body. Fix the issues and call again rather than publishing output with a non-empty issues list.

Report which providers are configured and which keyless fallbacks are in use. Call this first when something behaves unexpectedly - it shows whether verify_news has a real search key, whether humanize_text can rewrite server-side, and whether score_ai_text is using a real detector or the local heuristic. By default this reads configuration only, so a key that is present but dead still reads as true. Pass `probe=True` to actually call each keyed provider once and find out - that is the difference between "a key is set" and "a key works", and it is worth the few seconds whenever searches come back empty. Pass `check_feeds=True` to fetch every bundled publisher feed and report which ones answered. Publishers move their feeds without notice, so this is how a dead entry gets found before it silently narrows the keyless path. Both are off by default because both make network calls.

Step 5. Get the writing order, then write the article. Takes the verified facts and the keywords and returns the plan: a 1000-1300 word target, exactly two sections, the facts grouped by source with numbers and quotes separated out, keyword placement, FAQ questions, and the angles only this author can supply. ACT ON IT IMMEDIATELY. You are the writer: compose the full body in the configured voice and pass it to build_schema as `article`. Do not print the brief for the user and ask them to write from it - they asked for a post. Every reported claim must trace to a fact in the output. Where the sourcing is thin, reach the length with explanatory background and mark it as background; never attribute an invented detail to a source. Then run find_ai_words until clean and review_draft before build_schema.

Step 3. Download the verified sources and extract usable material. Returns facts, short attributed quotes (<=15 words) and figures, each tagged with the source_url it came from. URLs that fail to fetch or extract are reported in per_url with the reason - they are never filled in with guesses. Everything you write in the article must trace back to an entry returned here. If a claim is not in this output, it does not go in the post.

Check a draft for stock AI phrasing and report exactly where it appears. Returns `clean` (boolean), a count, and every occurrence with the sentence it sits in. Run it after humanize_text and rewrite each flagged sentence, keeping every fact, figure, name and link. Repeat until `clean` is true - the house standard is zero, not "fewer". Cheaper and more precise than score_ai_text for this one job; score_ai_text also measures rhythm and gives you the number.

START HERE when the user gives a topic rather than a specific headline. "write about AI today", "something on electric vehicles", "this week in fintech" are topics. Find what actually happened before writing anything. "AI today", "electric vehicles", "Indian fintech" are topics: there is no claim to verify yet, you first have to find out what actually happened. This searches recent coverage, groups articles reporting the same event into stories, and ranks them by independent publisher count and freshness. Use `ready_to_write` - those stories already clear the two-publisher bar and have fetchable URLs. Check `age_hours` to pick something current. Then pass the chosen story's `headline` to verify_news and its `fetchable_urls` to fetch_article_facts. `days` is the recency window and defaults to 2. Widen it if nothing comes back; narrow it to 1 for same-day news only.

Step 8. Generate a banner image for the article and save it locally. Build the prompt from the article's visual concepts, not its brand names. A trademark filter runs anyway and rewrites brand terms into generic descriptors before the prompt leaves this machine; check terms_removed to see what it changed. The returned path is local. Upload the file and pass a public https URL to build_schema, or NewsArticle.image will point somewhere no crawler can reach.

Check whether this server has been set up, and with what. CALL THIS FIRST, before anything else. If `configured` is false, ask the user the returned questions in the chat, wait for their answers, then call set_profile. Every content tool refuses to run until then. The answers decide the byline, the voice, the schema publisher, where the call to action links, and the canonical URL for every post. Nothing here is inferred from the environment.

Optional. Rewrite a draft to strip AI writing tells, keeping facts intact. Prefer review_draft. This rewrites the text for the writer, which produces machine-written prose again; a detector will read it as such, because detectors measure how predictable the wording is rather than how many stock phrases it contains. Use this only to edit text the writer already wrote, and tell them it was used. With an LLM key configured, the rewrite happens server-side and comes back in rewritten_text. Without one, mode='delegated_to_caller' and you must apply the returned `instructions` to `text_to_rewrite` yourself, preserving every fact, figure, name, date, quote and URL exactly. Optionally pass voice_sample to match a specific writer's rhythm. The sample governs style only and never contributes facts.

Forget the byline and voice, so the setup questions are asked again.

Step 6. Read the writer's draft and say where it is weak. Never rewrite it. Pass the human-written draft and the facts from fetch_article_facts. Returns must_fix / worth_fixing / consider, each note naming the sentence and what to do about it, plus what the draft already does well. Checks claims against the researched facts and flags figures or quotes nothing supports, quotes over 15 words or missing attribution, stock AI phrasing, weak openings, hedging stacks, passive density, and flat sentence rhythm. Returning a rewritten draft defeats the purpose. Give the writer the notes.

Step 11. Write the finished package to disk and hand the post over. `pack` from build_publishing_pack is REQUIRED - this refuses without it. That tool holds the permalink, tags, banner URL and image prompt, and it is where the user gets asked what the banner should look like. Skipping it produces a package that looks finished and is missing all five. Returns `SHOW_THIS_TO_THE_USER` (print it verbatim) and `preview_html` (put it in an HTML artifact so the user can see the post laid out). Produces a timestamped folder containing paste-into-blogger.html (both JSON-LD blocks plus the styled body - the file to paste into the post editor), index.html (a standalone preview page with meta, canonical, Open Graph and Twitter tags in the head), body.html, newsarticle.jsonld, faqpage.jsonld, a copy of the image, meta.json, report.md, and - when `pack` from build_publishing_pack is supplied - publish-pack.md with the title, labels, permalink and Gemini image prompt. report.md is the human-readable summary: verification verdict and publishers, human score before and after humanising, SEO score with any must-fix items, and the reference list. Populate `meta` with keys `verification`, `human_score` ({before, after, detector_used, is_real_detector}), `seo` and `references` and they all appear in it. Pass the `meta` dict that build_schema returned - canonical_url, image_url and the rest are read from it when not given explicitly. Put the verification result, both human scores, the SEO audit and the reference list in meta so the post stays auditable later.

Step 7. Score how human the text reads, 0-100 (higher = more human). Uses a real detector API if one is configured, otherwise a local heuristic that measures structural tells (sentence-length burstiness, stock phrases, em dash density, lexical variety). Check is_real_detector before presenting the number, and always surface the caveat: no detector score proves authorship. Run it before and after humanize_text to show the improvement.

Step 10. Score the finished body. Returns TWO scores, SEO and AEO. `score` is on-page SEO: H1 and keyword placement, keyword density, H2 structure, word count, meta title and description lengths, slug shape, image alt text, and links - external and internal counted separately, with anchor text checked. `aeo` is Answer Engine Optimisation, scored on its own under that key: whether an assistant can lift a correct, self-contained answer off the page and cite it. It checks the 40-60 word opening answer, question-shaped H2s, paragraph length, at least one figure or dated fact, a visible FAQ, heading order, and sources in the body. Structure, not keywords - a page can score well on SEO and badly here, and the gap is the point. Both carry must_fix / should_fix lists. Show the user both numbers; save_and_present puts them on separate rows of the Checks table. Pass `headline` when the body has no H1 because the blog platform renders the title itself - the H1 checks then run against that headline instead of failing a correctly-built post. Fix everything in must_fix and call again. On-page structure only: it says nothing about search volume, competition, or links from other sites.

Step 4. Mine the keywords this post should target, before drafting. Pass the headline plus the `text` of the facts returned by fetch_article_facts. Keywords come out of the source material you actually fetched, so they reflect the reporting rather than a guess. Returns primary_keyword, secondary_keywords, entities, and - from real Google autocomplete data - long_tail_queries and faq_query_candidates. Draft the FAQ from faq_query_candidates wherever your facts can answer them: those are questions people actually type. Also returns a suggested slug, meta title and meta description to feed into build_schema and seo_audit. No search-volume or competition data; that needs a paid keyword API.

Record who is publishing, where, and in what voice. Run once, after asking. author_name: the person's real name. Prints as "By <name>" and goes into the NewsArticle author field. tone: neutral | witty | upbeat | heartfelt | sombre. Shapes how posts are written; it never changes a fact, a figure, a quote or a link. company_name: the publisher. Becomes the schema publisher and the linked text in the closing call to action. site_url: the domain where posts are published. Canonical URLs, image paths and the call-to-action link are all built from it. A main domain or a subdomain both work. company_url: only when the blog is on a subdomain and the call to action should point at a different company site. Defaults to site_url. logo_url: defaults to <company_url>/logo.png. Only pass values the user actually typed. Ask the name, company and domain as free-text questions - do not offer guessed options, do not take a name from the account or folder path, do not pick a tone for them, and do not carry over a company or domain from an earlier post or example.

Earlier posts of your own worth linking to from this draft. These are INTERNAL links - your post pointing at your posts. They are not backlinks: a backlink is a link on somebody else's site, and no tool can create one. Internal links are the half you control, and they are what passes authority between your pages and builds topical depth. draft_brief already calls this, so you normally do not need to. Call it directly to re-check a draft, or to see what the index holds. Matching is strict on purpose: a shared named entity is evidence, a shared common word is not. When nothing clears the relevance floor it returns an empty list, and that is the right answer - an irrelevant internal link is worse than no link at all. The index fills as save_and_present writes each post, so this returns nothing until you have published more than one.

START HERE when the user gives a specific headline and wants a post about it. Confirms the headline describes a real, corroborated story before anything is written. Call this even if the user just says "write a blog post about <headline>" - verifying first is the point of this server. Searches every configured news provider, keeps only results that actually match the headline, and counts how many INDEPENDENT publishers are carrying it. Returns is_legit=false unless at least two independent publishers match, or a single primary/official source does. This verifies a headline; it does not find one. If the user gave you a topic ("today's AI news") rather than a headline, call find_stories first. Note that an old headline will correctly return old sources - `days` limits how far back to look. Do not draft anything if is_legit is false. Feed `fetchable_urls` to fetch_article_facts, and use `reference_candidates` as the reference list - those are real publisher URLs. Some providers return aggregator redirects that still name the outlet; they count toward corroboration but are not usable as links, and build_schema rejects them.

Write a complete, publication-ready blog post about a news story. USE THIS TOOL whenever the user asks for a blog post, an article, a news write-up, or "content" about a headline or a current topic - including when the request is as plain as "write me a blog post about X", and including when they do not mention this server by name. Do not search the web and draft the article yourself. That produces an unverified post with no schema, no SEO pass and no publishing pack, which is the exact outcome this server exists to prevent. Call this first instead. It does not write the article on its own - it checks the input, confirms setup, and returns the ordered plan with the next call to make. Follow the plan. The article gets written at the draft_brief step, by you, to the structure that tool returns.