fast-html-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port for SSE transport. Default is 3000. | |
| TRANSPORT | No | Transport method for MCP communication (e.g., sse, stdio). Default is stdio. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| render_pageC | Assemble page from structured components |
| patch_htmlC | Patch HTML element(s) by CSS selector |
| set_attributeB | Set attribute on element(s) by CSS selector |
| edit_html_rangeA | Replace a range of lines in an HTML file with new content (most token-efficient edit — send only the changed lines) |
| edit_sectionA | Replace a rendered section in an HTML file with a new component. Pages rendered with render_page embed section markers. Use list_sections to discover available indices. Provide component+props to re-render, or html for raw replacement. |
| insert_sectionA | Insert a new component section at a specific index, pushing existing sections forward. Uses the same section marker system as render_page. Auto-renumbers all subsequent sections. |
| list_sectionsA | List all component sections in an HTML file that was built with render_page. Returns section indices, component types, and sizes. |
| read_htmlA | Read/analyze existing HTML file. Use mode='text' for token-efficient plain text extraction with offset/limit progressive reading. |
| write_raw_htmlC | Write raw HTML content directly to file |
| write_html_fileC | Write content as formatted HTML file |
| format_htmlC | Format/beautify an existing HTML file |
| preview_htmlB | Preview rendered HTML string without writing |
| list_templatesA | List available template shells (optionally filter by category) |
| propagate_editB | Propagate an entity edit through the dependency graph, updating all transitively affected sections |
| check_consistencyA | Audit document for stale cross-section references and dependency violations |
| list_componentsA | List available interactive components (optionally filter by category) |
| get_template_schemaB | Get template metadata including available variables with defaults |
| get_component_schemaB | Get component schema with available props |
| register_templateA | Register a custom template at runtime for immediate use with render_page/preview_html |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 19 tools
There is some overlap between tools like patch_html and set_attribute (both modify elements via CSS selectors), and write_raw_html vs write_html_file both write HTML but with unclear distinction. However, most tools have clearly defined purposes targeting different aspects (sections, templates, components), so the ambiguity is limited.
All tool names follow a consistent lower_snake_case verb_noun pattern (e.g., list_components, render_page, check_consistency). Verbs are clear and nouns align with the object acted upon, making the naming predictable and readable.
With 19 tools, the set is on the heavy side (16-25). While each tool has a specific role, the number feels slightly excessive for HTML manipulation, especially given the overlapping edit/write tools that could potentially be consolidated.
The tool surface covers creation, reading, editing, rendering, and template/component management comprehensively. The main gap is the lack of delete/removal operations (e.g., delete_element or remove_section), but core workflows are well-supported.