NewsBlog Composer MCP

build_schema

Renders the article HTML and both JSON-LD blocks, validates mismatches between them, and returns a paste-ready block with meta for publishing.

Instructions

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 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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`faq`	Yes
`image`	Yes
`article`	Yes
`keywords`	No
`references`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Sep 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries all behavioral disclosure. It states the tool is 'pure templating, no model call,' describes that it returns validation.issues and instructs agents to 'fix the issues and call again rather than publishing output with a non-empty issues list.' It also discloses the H1 behavior and how to change it with BODY_INCLUDES_H1, which is significant behavioral context.

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

Conciseness4/5

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

The description is lengthy, but nearly every line adds required detail given the empty schema. It is front-loaded with the purpose, then parameter contracts, then behavioral notes, which is a logical order. It could be tightened with clearer headings, but the density is justified.

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?

The description provides everything an agent needs to call the tool correctly: input contracts, output shape (`paste_block`, `meta`, and `validation.issues`), validation semantics, and pipeline integration with `save_and_present`. Given the lack of output schema and annotations, this is a complete definition.

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

Parameters5/5

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

The input schema provides no descriptions, but the description enumerates the exact structure expected for `article` (headline, description character count, intro length, section limits, word count, optional fields), the 4-8 entry requirement for `faq`, the public-https requirement for `image.url`, and the source of `keywords`. This richly compensates for the 0% schema coverage.

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 opens with 'Step 9. Render the HTML body and both JSON-LD blocks, then check them,' which names a specific action and artifact. It goes on to differentiate itself from siblings like write_blog_post and save_and_present by framing it as pure templating and explicitly tying the `meta` output to save_and_present. This makes the tool's role in the pipeline unmistakable.

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?

The description places the tool as Step 9 and does not leave its use to inference: it references the seo_keywords tool for keyword input and directs the `meta` output to save_and_present. However, it never names alternative tools or states explicit conditions under which a different tool should be chosen, so it falls short of full alternative guidance.

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

build_schema

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools