Skip to main content
Glama

tool_generate_blog_scaffold

Generate an SEO-optimized markdown scaffold for CSDN blog posts, including title ideas, H2/H3 structure, code placeholders, and suggested tags before drafting content.

Instructions

Generate an SEO-optimized markdown scaffold for a CSDN blog post.

Returns a markdown skeleton tuned for CSDN ranking: keyword-front-loaded title ideas, H2/H3 hierarchy, intro hook, code-block placeholders, and suggested tags. Use this BEFORE writing to get a good structure, then fill it in and pass the result to write_blog.

Tip: call get_style_guide first so the filled-in content matches the author's voice.

Args: topic: The blog topic / subject. keywords: SEO keywords (the first one is front-loaded into title ideas). style: Writing style preset — "intro" (开源项目/MCP 介绍文), "tutorial" (保姆级部署教程), "technical", "analysis", "notes", or "general". tags: Optional pre-chosen tags; otherwise suggested from keywords.

Returns: dict with {ok, topic, style, title_suggestions, tags_suggested, scaffold}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNo
styleNotechnical
topicYes
keywordsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are provided, so the description must disclose behavior itself. It does document the return payload shape ({ok, topic, style, title_suggestions, tags_suggested, scaffold}) and the conditional tag-suggestion behavior, which is genuinely useful. It does not state whether the tool has any side effects (it appears to be a pure generator), leaving a small gap.

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 purpose, then Args/Returns blocks. Every section earns its place and nothing is redundant, though the prose is somewhat long for a four-parameter generator.

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?

With no output schema and 0% schema description coverage, the description supplies the missing parameter meanings and the return structure, plus workflow placement. Nothing an agent needs to invoke this correctly is absent.

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?

Schema description coverage is 0%, so the description carries the full burden and does: topic, keywords (noting the first is front-loaded into titles), style (with the actual allowed presets the schema fails to declare as an enum), and tags (with the fallback behavior when omitted). This is a substantial addition over the bare schema.

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 a specific verb+resource: 'Generate an SEO-optimized markdown scaffold for a CSDN blog post', and enumerates what the scaffold contains (title ideas, H2/H3 hierarchy, hook, code placeholders, tags). This clearly distinguishes it from siblings like write_blog and seo_check, which operate on finished content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states explicit sequencing ('Use this BEFORE writing... then fill it in and pass the result to write_blog') and names the related sibling get_style_guide with the condition for calling it first. An agent knows exactly where this fits in the workflow.

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