Skip to main content
Glama

generate_html

Read-onlyIdempotent

Convert Markdown to a complete, self-contained HTML document with inlined styles and KaTeX math. Returns the HTML string directly for browser rendering without writing files.

Instructions

Generate a complete, self-contained HTML document from Markdown with all styles inlined. Renders GFM (tables, task lists, strikethrough) and KaTeX math into a full HTML page with an embedded block and a KaTeX CSS CDN link. Returns the HTML string directly — no file is written to disk. Side effects: none. This tool is read-only and performs no file I/O. Returns: a complete HTML document string () with inline styles, ready for rendering in a browser. The optional title parameter sets the tag in the HTML section. Use this when you need styled HTML output returned as a string (e.g., for embedding in responses or previewing). Prefer convert_to_html when you need to write the HTML to a file on disk. Prefer convert_to_pdf or convert_to_image for non-HTML visual output formats.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
markdownYesThe raw Markdown source text to convert. Supports GitHub-Flavored Markdown (tables, task lists, strikethrough) and KaTeX math expressions. Pass the full document content as a string, not a file path.
titleNoOptional. Sets the <title> tag in the HTML document's <head> section. Displayed in browser tabs and bookmarks. Defaults to 'Document' if omitted.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv0.1.6
  2. Removedv0.1.3
  3. Changed2 schema fields changedv0.1.2
    • addedInput schema / properties / markdown / description
      Added value: +"The raw Markdown source text to convert. Supports GitHub-Flavored Markdown (tables, task lists, strikethrough) and KaTeX math expressions. Pass the full document content as a string, not a file path."
    • addedInput schema / properties / title / description
      Added value: +"Optional. Sets the <title> tag in the HTML document's <head> section. Displayed in browser tabs and bookmarks. Defaults to 'Document' if omitted."
  4. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Beyond annotations (readOnlyHint, destructiveHint), the description adds valuable behavioral context: output is a string not file, includes KaTeX CSS CDN link dependency, specifies exact return format (<!DOCTYPE html>…</html>), and confirms side effects none. Does not mention idempotency from annotations, but coverage is strong otherwise.

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?

Ten sentences cover purpose, features, I/O behavior, side effects, return values, parameter specifics, and sibling distinctions. While dense, every sentence earns its place with no redundancy, following a logical what→how→when→alternatives structure.

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?

Comprehensive for a conversion tool with many siblings. Compensates for missing output schema by explicitly describing the returned HTML string structure. Covers behavioral traits, parameters, and clear differentiation from 20+ sibling conversion tools.

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?

With 100% schema description coverage, the baseline is 3. The description adds minor supplemental context about the 'title' parameter's effect on the HTML <head> section, but the schema already fully documents both parameters' purposes and types.

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 uses a specific verb ('Generate') and clear resource ('complete, self-contained HTML document'). It explicitly distinguishes from sibling 'convert_to_html' by emphasizing 'returns the HTML string directly — no file is written to disk' versus file output.

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?

Provides explicit usage guidance: 'Use this when you need styled HTML output returned as a string' and clear alternatives: 'Prefer convert_to_html when you need to write the HTML to a file' and 'Prefer convert_to_pdf or convert_to_image for non-HTML visual output formats.'

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

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/XJTLUmedia/MCP_Markdown_Formatter'

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