A powerful MCP (Model Control Protocol) server for managing Hugo static site generator.
hugo-mcp has 15 tools with basic schema definitions and descriptions, but suffers from critical gaps in parameter documentation, missing output schemas, and inconsistent naming patterns. Most tools have descriptions under the recommended length (10-1024 chars) and lack detailed parameter constraints. Parameter descriptions are often generic or missing. No visible input validation or error recovery guidance. Schema definitions are present but incomplete, many parameters lack descriptions or detailed constraints. Tools lack annotations (readOnlyHint, destructiveHint, idempotentHint) that would guide agents on safety. The server reads like a straightforward CLI wrapper rather than an LLM-optimized tool suite. Average tool score across 15 tools: ~42/100, placing this in the 'fair to poor' range (50-59 baseline for mediocre community servers, below that here).
Build the Hugo site for production
Check if Git is installed and get its configuration
Check if Go is installed and get its version
Check if Hugo is installed and get its version
Create a new Hugo post
Create a new Hugo site
Deploy a Hugo site to various platforms
Parameter descriptions are minimal or missing. Most parameters (e.g., 'site_path', 'port', 'theme_url') have generic descriptions like 'Path to the Hugo site' or 'Name of the theme' without specifying valid ranges, formats, or constraints. LLMs cannot infer whether 'port' accepts 1 - 65535 vs 80 - 8080, or whether 'site_path' must be absolute vs relative.
No output schemas documented. Tools return 'Dict[str, Any]' with no indication of which fields are present, their types, or meaning. E.g., create_site returns a dict, is it {'status': 'success', 'path': '/path/to/site'} or {'success': true, 'id': '123', ...}? LLMs cannot extract chaining IDs or plan follow-up calls without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 8 | - | v1 |
Get system information
Get detailed information about a specific Hugo theme
Install a Hugo theme
List content in the Hugo site
List available Hugo themes from the official Hugo themes website
Start Hugo local server for preview
Stop a running Hugo preview server
Update an installed Hugo theme
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools like 'delete' or 'create' should be marked destructive or non-idempotent to guide agent retry logic and planning. Without annotations, agents cannot distinguish safe-to-retry reads from irreversible writes. E.g., 'deploy_site' is marked as IRREVERSIBLE but the tool lacks a destructiveHint annotation.
Enum constraints missing for multi-choice parameters. 'platform' in deploy_site accepts 'github-pages, netlify, vercel, custom' but is defined as a free-form string, not an enum. Same for 'content_type' in create_post (accepts 'posts', 'blog', etc.) and 'bind' in start_preview. Enums are self-documenting and prevent hallucinated values.
No error recovery guidance. Error responses from underlying utils (e.g., 'Deployment failed: {str(e)}' in deploy_site) provide raw exception text, not actionable guidance. LLMs cannot infer whether to retry, ask the user, or abandon the plan. E.g., 'Hugo not found. Install Hugo from https://gohugo.io or check PATH.' would be actionable; '{str(e)}' is not.
Secrets exposed as parameters. 'api_key' in deploy_site is a parameter, not server-side injected. Agent logs and prompt history will contain API keys, creating a security vulnerability. Must use environment variables or vault injection.
No pagination or result limiting for list_* tools. 'list_themes' and 'list_content' return unbounded lists with no mention of total count, page/offset parameters, or result caps. If Hugo has 1000+ themes, returning all of them blows the context window and wastes tokens.
Irreversible operations (deploy_site, build_site with clean_destination=true) lack confirmation or dry-run support. An agent can accidentally deploy or destroy a directory without a checkpoint. Should provide a 'dry_run' parameter or 'confirm_before_execute' pattern.
Process management (stop_preview) requires raw PID, not a human-friendly identifier. Users don't know process IDs, 'stop the preview on port 1313' is natural, but 'stop PID 12345' is awkward. Should accept 'site_path' or 'port' and resolve to PID internally.
Parameter naming is inconsistent. 'use_go_module' in install_theme vs 'use_modules' in update_theme for similar concepts. 'build_drafts' vs 'draft' (singular) across tools. Inconsistent naming forces LLMs to guess and wastes reasoning cycles.