Skip to main content
Glama

create-blog-html

Generate localized HTML blog posts with consistent writing styles by analyzing existing content and applying proper formatting for SEO optimization.

Instructions

Generate HTML blog posts under public/blogs///.html with a BLOG_META block.

CRITICAL: WRITING STYLE CONSISTENCY Before generating content, you MUST:

  1. Read existing blog posts from public/blogs//*/.html (use findExistingBlogPosts utility or read files directly)

  2. Analyze the writing style, tone, and format from 2 existing posts in the same locale

  3. Match that exact writing style when generating the new blog post content and description

  4. Maintain consistency in: paragraph structure, heading usage, tone, formality level, and overall format

IMPORTANT REQUIREMENTS:

  1. The 'locale' parameter is REQUIRED. If the user does not provide a locale, you MUST ask them to specify which language/locale they want to write the blog in (e.g., 'en-US', 'ko-KR', 'ja-JP', etc.).

  2. The 'content' parameter is REQUIRED. You (the LLM) must generate the HTML content based on the 'topic' and 'locale' provided by the user. The content should be written in the language corresponding to the locale AND match the writing style of existing blog posts for that locale.

  3. The 'description' parameter is REQUIRED. You (the LLM) must generate this based on the topic, locale, AND the writing style of existing blog posts.

  4. The 'appSlug' parameter:

    • If the user explicitly requests "developer category", "developer blog", "personal category", "my category", or similar, you MUST set appSlug to "developer".

    • If the user mentions a specific app/product, use that app's slug.

    • If not specified, defaults to "developer".

Slug rules:

  • slug = slugify(English title, kebab-case ASCII)

  • path: public/blogs///.html

  • appSlug: Use "developer" when user requests developer/personal category. Defaults to "developer" if not specified.

  • coverImage default: /products//og-image.png (relative paths are rewritten under /blogs///)

  • overwrite defaults to false (throws when file exists)

HTML Structure (follows public/en-US.html pattern):

  • BLOG_META block at the top with JSON metadata

  • HTML body content: paragraphs (), headings (, ), images (), lists (, ), horizontal rules (), etc.

  • You must generate the HTML content based on the topic, making it relevant and engaging for the target locale's language, while maintaining consistency with existing blog posts.

Supports multiple locales when locales[] is provided. Each locale gets its own HTML file. For each locale, you must:

  1. Read existing posts in that locale to understand the writing style

  2. Generate appropriate content in that locale's language

  3. Match the writing style and format of existing posts

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appSlugNoProduct/app slug used for paths and CTAs. Defaults to "developer" when not provided.developer
titleNoEnglish title used for slug (kebab-case). Falls back to topic when omitted.
topicYesTopic/angle to write about in the blog body
localeYesPrimary locale (e.g., 'en-US', 'ko-KR'). Required to determine the language for blog content generation.
localesNoOptional list of locales to generate. Each locale gets its own HTML file. If provided, locale parameter is ignored.
contentYesHTML content for the blog body. You (the LLM) must generate this HTML content based on the topic and locale. Structure should follow the pattern in public/en-US.html: paragraphs (<p>), headings (<h2>, <h3>), images (<img>), lists (<ul>, <li>), horizontal rules (<hr>), etc. The content should be written in the language corresponding to the locale.
descriptionYesMeta description for the blog post. You (the LLM) must generate this based on the topic and locale. Should be a concise summary of the blog content in the language corresponding to the locale.
tagsNoOptional tags for BLOG_META. Defaults to tags derived from topic.
coverImageNoCover image path. Relative paths rewrite to /blogs/<app>/<slug>/..., default is /products/<appSlug>/og-image.png.
publishedAtNoPublish date (YYYY-MM-DD). Defaults to today.
modifiedAtNoLast modified date (YYYY-MM-DD). Defaults to publishedAt.
overwriteNoOverwrite existing files when true (default: false).
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes critical behaviors: the tool requires reading existing posts for style consistency, enforces locale and content requirements, handles defaults for appSlug and coverImage, and specifies that overwrite defaults to false (throws when file exists). This covers key operational traits beyond basic parameters.

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

Conciseness2/5

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

The description is overly verbose and poorly structured, with repetitive instructions (e.g., multiple bullet points on writing style consistency) and redundant details that could be condensed. It front-loads critical information but includes excessive elaboration, reducing clarity and efficiency.

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?

Given the complexity of the tool (12 parameters, no annotations, no output schema), the description is largely complete. It covers the tool's purpose, behavioral requirements, and parameter usage in detail. However, it lacks information on error handling or output format, which could be beneficial for an agent invoking this tool.

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?

The schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description adds some semantic context, such as explaining slug generation rules and locale handling for multiple files, but does not significantly enhance the parameter understanding beyond what the schema provides. This meets the baseline for high 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 clearly states the tool's purpose: 'Generate HTML blog posts under public/blogs/<appSlug>/<slug>/<locale>.html with a BLOG_META block.' It specifies the exact verb ('Generate'), resource ('HTML blog posts'), and output location, distinguishing it from sibling tools like 'improve-public' or 'validate-aso' that handle different operations.

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 provides clear context for when to use this tool, such as generating blog content in specific locales and matching existing writing styles. However, it does not explicitly state when NOT to use it or mention alternatives among sibling tools, like using 'improve-public' for modifications instead of creation.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/quartz-labs-dev/pabal-resource-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server