Skip to main content
Glama
Mohammed-Jameal-J

NewsBlog Composer MCP

by Mohammed-Jameal-J
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

build_publishing_pack

Assembles the final publishing block: title, labels, slug, search description, image alt text, and a paste-ready image prompt. Pass the pack to save_and_present to write publish-pack.md.

Instructions

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 eight styles are product_hero, explainer_diagram, scene_with_display, hardware_macro, whiteboard_sketch, newspaper_front, editorial_illustration and newsletter_header. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugNo
entitiesNo
headlineYes
keywordsNo
banner_textNo
descriptionNo
image_styleNo
banner_kickerNo
canonical_urlNo
image_conceptsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.1
    • addedInput schema / properties / banner_kicker
      Added value: +{
+  "default": "",
+  "title": "Banner Kicker",
+  "type": "string"
+}
    • addedInput schema / properties / banner_text
      Added value: +{
+  "default": "",
+  "title": "Banner Text",
+  "type": "string"
+}
    • changedInput schema / properties / image_style / default
      Previous value: -"editorial"New value: +""
  2. First observedv0.2.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries full burden and handles it well: it discloses that an empty image_style triggers an interactive prompt that waits for the user, that missing style causes save_and_present to refuse the pack, and that gemini_image_prompt strips brand names. These are non-obvious behaviors an agent must know to act correctly.

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 longer than typical but every sentence carries value. It front-loads the purpose and return values, then dives into the critical image_style rule and param guidance. It could be tightened slightly (e.g., merging the style enumeration into the flow), but overall it's well-structured and not padded.

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?

Given the tool's complexity (10 parameters, no output schema, no annotations), the description is remarkably complete. It covers the tool's role, prerequisites, the primary behavioral caveat, and how to chain it to save_and_present. The only omissions are secondary parameter details, which are minor and do not impair correct invocation.

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 0%, so the description must compensate. It explains key parameters: image_style (user-chosen, eight enumerated styles), image_concepts (plain-words description not company names), banner_text (shortened headline), and banner_kicker (second line). However, slug, description, keywords, entities, and canonical_url are not explained beyond their titles, leaving some parameters under-specified for an agent.

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 'Final step. Everything needed to publish, in one block,' and then lists the exact outputs (title, Blogger labels line, permalink slug, search description, image alt text, gemini_image_prompt). This is a specific verb+resource and clearly distinguishes it from siblings like save_and_present or generate_image by framing it as the assembly step that precedes saving.

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 gives strong contextual cues: it's the 'final step,' mentions 'the article you just wrote,' and instructs to 'pass the result to save_and_present.' It explains the critical user-choice rule for image_style and the consequence of leaving it empty. It does not explicitly name alternatives or say when not to use it, but the workflow is clear enough to avoid misuse.

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

Deploy Server

Other Tools