Skip to main content
Glama
Mohammed-Jameal-J

NewsBlog Composer MCP

by Mohammed-Jameal-J
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

save_and_present

Write the completed article package to a timestamped folder and return all file paths, including paste-ready HTML, preview page, JSON-LD, image, meta, and audit report.

Instructions

Step 11. Write the finished package to disk and return the paths.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaNo
packNo
slugYes
titleNo
languageNo
html_bodyYes
image_urlNo
image_pathNo
descriptionNo
json_ld_faqNo
canonical_urlNo
json_ld_articleNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.1/5.0
Behavior4/5

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

No annotations, so the description carries the full burden. It discloses that files are written to a timestamped folder, that a file is only produced conditionally ('when pack from build_publishing_pack is supplied'), and that outputs include human-readable report.md. It doesn't address overwrite behavior or permissions, but the write scope is well conveyed.

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 core action, then structured into artifact list and meta guidance. It is fairly long but each section (outputs, report.md, meta keys) adds distinct information, with little redundancy.

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?

For a 12-param, no-annotation, no-output-schema tool, the description documents the files produced and the meta structure well. The main gap is that half the input parameters receive no explanation, but the critical ones and the meta/pack objects are covered.

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 0%, so the description must compensate. It does explain that meta should be the dict from build_schema and that canonical_url/image_url are read from it, and it specifies the required meta keys. However, only 2 of 12 parameters (slug, html_body) are implied by the artifact list, and most others (title, language, json_ld_article, json_ld_faq, etc.) are never explained.

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: 'Write the finished package to disk and return the paths.' It also enumerates the exact artifacts produced, so an agent can distinguish it from siblings like build_schema or build_publishing_pack, which produce inputs rather than write to disk.

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?

Frames itself as 'Step 11', clearly placing it at the end of the pipeline after build_publishing_pack and build_schema. It explains that meta comes from build_schema's return, giving clear sequencing context, but doesn't explicitly state exclusions or alternatives to this tool.

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