Which integrations are available for this server?

Provides tools for creating, managing, and deploying Hugo static sites, including environment setup, site creation, theme management, and content management.

How do I use hugo-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hugo-mcp create a new Hugo site called my-blog" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

hugo-mcp

by SunnyCloudYang

Overview Schema Source Related Servers Discussions Admin

Python

Local

Hugo MCP Server

A powerful MCP (Model Control Protocol) server for managing Hugo static site generator. This server provides a comprehensive set of tools for creating, managing, and deploying Hugo sites.

Related MCP server: DevServer MCP

Installation

Prerequisites

Python 3.10+
uv (Python package manager)
Git (Highly recommended)

Installing the Hugo MCP Server

Clone the repository:

git clone https://github.com/sunnycloudyang/hugo-mcp.git

Add server to your config (make sure uv has been installed before):

{
     "mcpServers": {
         "hugo-mcp": {
             "command": "uv",
             "args": [
                 "--directory",
                 "/ABSOLUTE/PATH/TO/PARENT/FOLDER/hugo-mcp",
                 "run",
                 "main.py"
             ]
         }
     }
 }

Remember to replace "/ABSOLUTE/PATH/TO/PARENT/FOLDER/hugo-mcp" to your installation path

Enalble this mcp server and try it!

Usage

The Hugo MCP server provides a set of tools that can be used to manage Hugo sites. Each tool has specific parameters and returns a structured response.

Basic Usage

Start the server manually (If needed):
```
uv run main.py
```
Connect to the server using an MCP client.
Use the tools to manage your Hugo sites.

Tools

Environment Setup Tools

check_hugo_installation

Description: Check if Hugo is installed and get its version.

Parameters: None

Returns:

{
  "status": "success",
  "version": "Hugo Static Site Generator v0.92.0/extended linux/amd64 BuildDate=unknown"
}

Error Response:

{
  "status": "error",
  "message": "Hugo is not installed or not in PATH"
}

Prerequisites: None

Actions After Success: None

Actions After Failure: Install Hugo using the install_hugo tool.

install_hugo

Description: Install Hugo using the appropriate method for the current OS.

Parameters:

version (optional): The version of Hugo to install. Defaults to "latest".

Returns:

{
  "status": "success",
  "message": "Hugo installed via Homebrew"
}

Error Response:

{
  "status": "error",
  "message": "Installation failed: Command 'brew install hugo' returned non-zero exit status 1."
}

Prerequisites: Appropriate package manager (Homebrew, apt, dnf, yum) must be installed.

Actions After Success: Hugo is installed and ready to use.

Actions After Failure: Manual installation may be required.

check_go_installation

Description: Check if Go is installed and get its version.

Parameters: None

Returns:

{
  "status": "success",
  "version": "go version go1.17.5 darwin/amd64"
}

Error Response:

{
  "status": "error",
  "message": "Go is not installed or not in PATH"
}

Prerequisites: None

Actions After Success: None

Actions After Failure: Install Go using the install_go tool.

install_go

Description: Install Go using the appropriate method for the current OS.

Parameters:

version (optional): The version of Go to install. Defaults to "latest".

Returns:

{
  "status": "success",
  "message": "Go installed via Homebrew"
}

Error Response:

{
  "status": "error",
  "message": "Installation failed: Command 'brew install go' returned non-zero exit status 1."
}

Prerequisites: Appropriate package manager (Homebrew, apt, dnf, yum) must be installed.

Actions After Success: Go is installed and ready to use.

Actions After Failure: Manual installation may be required.

check_git_installation

Description: Check if Git is installed and get its configuration.

Parameters: None

Returns:

{
  "status": "success",
  "version": "git version 2.30.1 (Apple Git-130)",
  "user": {
    "name": "John Doe",
    "email": "john.doe@example.com"
  },
  "default_branch": "main"
}

Error Response:

{
  "status": "error",
  "message": "Git is not installed or not in PATH"
}

Prerequisites: None

Actions After Success: None

Actions After Failure: Install Git using the install_git tool.

install_git

Description: Install Git using the appropriate method for the current OS.

Parameters: None

Returns:

{
  "status": "success",
  "message": "Git installed via Homebrew"
}

Error Response:

{
  "status": "error",
  "message": "Installation failed: Command 'brew install git' returned non-zero exit status 1."
}

Prerequisites: Appropriate package manager (Homebrew, apt, dnf, yum) must be installed.

Actions After Success: Git is installed and ready to use.

Actions After Failure: Manual installation may be required.

configure_git

Description: Configure Git with user name and email.

Parameters:

name: The user name to set.
email: The email address to set.

Returns:

{
  "status": "success",
  "message": "Git configured with name 'John Doe' and email 'john.doe@example.com'"
}

Error Response:

{
  "status": "error",
  "message": "Failed to configure Git: Command 'git config --global user.name John Doe' returned non-zero exit status 1."
}

Prerequisites: Git must be installed.

Actions After Success: Git is configured with the specified user name and email.

Actions After Failure: Manual configuration may be required.

Site Management Tools

create_site

Description: Create a new Hugo site.

Parameters:

site_name: The name of the site to create.
theme (optional): The theme to use for the site.
force (optional): Whether to force creation if the directory already exists. Defaults to false.
use_example_site (optional): Whether to use the example site from the theme. Defaults to true.

Returns:

{
  "status": "success",
  "path": "/path/to/site",
  "theme": "paper",
  "example_site": true,
  "author": {
    "name": "John Doe",
    "email": "john.doe@example.com"
  }
}

Error Response:

{
  "status": "error",
  "message": "Directory 'site' already exists. Use force=True to overwrite."
}

Prerequisites: Hugo must be installed.

Actions After Success: A new Hugo site is created with the specified theme and example content.

Actions After Failure: The site is not created.

Theme Management Tools

list_themes

Description: List available Hugo themes from the official Hugo themes website.

Parameters: None

Returns:

{
  "status": "success",
  "themes": [
    {
      "name": "PaperMod",
      "url": "https://github.com/gohugoio/hugoThemes/tree/master/themes/hugo-papermod",
      "image": "https://themes.gohugo.io/themes/hugo-papermod/tn-featured_hu_275191178647f5e7.png"
    },
    {
      "name": "Hugo Blox - Tailwind",
      "url": "https://github.com/gohugoio/hugoThemes/tree/master/themes/blox-tailwind",
      "image": "https://themes.gohugo.io/themes/blox-tailwind/tn-featured_hu_8c1541d303ce3b9b.png"
    }
  ],
  "count": 150
}

Error Response:

{
  "status": "error",
  "message": "Network error: Connection refused"
}

Prerequisites: Internet connection.

Actions After Success: A list of available themes is returned.

Actions After Failure: No themes are returned.

get_theme_details

Description: Get detailed information about a specific Hugo theme.

Parameters:

theme_name: The name of the theme to get details for.

Returns:

{
  "status": "success",
  "theme": {
    "name": "Paper",
    "url": "https://github.com/gohugoio/hugoThemes/tree/master/themes/paper",
    "image": "https://themes.gohugo.io/themes/paper/tn-featured.png",
    "description": "A simple, clean, and responsive Hugo theme for personal blog.",
    "features": [
      "Responsive design",
      "Clean and minimal",
      "Fast and lightweight",
      "SEO friendly"
    ],
    "tags": ["blog", "minimal", "responsive"],
    "github_url": "https://github.com/nanxiaobei/hugo-paper",
    "demo_url": "https://themes.gohugo.io/theme/paper/",
    "installation": "git submodule add https://github.com/nanxiaobei/hugo-paper themes/paper"
  }
}

Error Response:

{
  "status": "error",
  "message": "Theme 'NonExistentTheme' not found on the Hugo themes website"
}

Prerequisites: Internet connection.

Actions After Success: Detailed information about the theme is returned.

Actions After Failure: No theme details are returned.

install_theme

Description: Install a Hugo theme using git submodule or Hugo modules.

Parameters:

site_path: The path to the Hugo site.
theme_name: The name of the theme to install.
theme_url: The URL of the theme repository.
use_modules (optional): Whether to use Hugo modules instead of git submodules. Defaults to false.

Returns:

{
  "status": "success",
  "theme": "paper",
  "method": "git_submodule"
}

Error Response:

{
  "status": "error",
  "message": "Failed to install theme: Command 'git submodule add https://github.com/nanxiaobei/hugo-paper themes/paper' returned non-zero exit status 1."
}

Prerequisites:

Hugo must be installed.
Git must be installed (for git submodules).
Go must be installed (for Hugo modules).

Actions After Success: The theme is installed and configured in the site.

Actions After Failure: The theme is not installed.

update_theme

Description: Update an installed Hugo theme.

Parameters:

site_path: The path to the Hugo site.
theme_name: The name of the theme to update.
use_modules (optional): Whether the theme was installed using Hugo modules. Defaults to false.

Returns:

{
  "status": "success",
  "theme": "paper",
  "method": "git_submodule"
}

Error Response:

{
  "status": "error",
  "message": "Failed to update theme: Command 'git submodule update --remote themes/paper' returned non-zero exit status 1."
}

Prerequisites:

Hugo must be installed.
Git must be installed (for git submodules).
Go must be installed (for Hugo modules).
The theme must be already installed.

Actions After Success: The theme is updated to the latest version.

Actions After Failure: The theme is not updated.

Content Management Tools

create_post

Description: Create a new Hugo post.

Parameters:

site_path: The path to the Hugo site.
post_title: The title of the post.
content_type (optional): The content type of the post. Defaults to "posts".
draft (optional): Whether the post should be a draft. Defaults to true.
date (optional): The date of the post.

Returns:

{
  "status": "success",
  "file": "content/posts/my-first-post.md",
  "draft": true
}

Error Response:

{
  "status": "error",
  "message": "Site path '/path/to/site' does not exist"
}

Prerequisites: Hugo must be installed.

Actions After Success: A new post is created in the specified content type directory.

Actions After Failure: The post is not created.

list_content

Description: List content in the Hugo site.

Parameters:

site_path: The path to the Hugo site.
content_type (optional): The content type to list. If not specified, all content is listed.

Returns:

{
  "status": "success",
  "content": [
    "posts/my-first-post.md",
    "posts/another-post.md",
    "pages/about.md"
  ]
}

Error Response:

{
  "status": "error",
  "message": "Site path '/path/to/site' does not exist"
}

Prerequisites: Hugo must be installed.

Actions After Success: A list of content files is returned.

Actions After Failure: No content is returned.

Preview and Build Tools

start_preview

Description: Start Hugo local server.

Parameters:

site_path: The path to the Hugo site.
port (optional): The port to use. Defaults to 1313.
bind (optional): The address to bind to. Defaults to "127.0.0.1".
build_drafts (optional): Whether to build draft content. Defaults to false.
build_future (optional): Whether to build future content. Defaults to false.
build_expired (optional): Whether to build expired content. Defaults to false.

Returns:

{
  "status": "success",
  "url": "http://127.0.0.1:1313",
  "pid": 12345,
  "options": {
    "build_drafts": false,
    "build_future": false,
    "build_expired": false
  }
}

Error Response:

{
  "status": "error",
  "message": "Site path '/path/to/site' does not exist"
}

Prerequisites: Hugo must be installed.

Actions After Success: The Hugo server is started and accessible at the specified URL.

Actions After Failure: The server is not started.

stop_preview

Description: Stop a running Hugo preview server.

Parameters:

pid: The process ID of the server to stop.

Returns:

{
  "status": "success",
  "message": "Server with PID 12345 stopped"
}

Error Response:

{
  "status": "error",
  "message": "Process with PID 12345 not found"
}

Prerequisites: None.

Actions After Success: The Hugo server is stopped.

Actions After Failure: The server is not stopped.

build_site

Description: Build the Hugo site for production.

Parameters:

site_path: The path to the Hugo site.
destination (optional): The destination directory. Defaults to "public".
clean_destination (optional): Whether to clean the destination directory before building. Defaults to false.
minify (optional): Whether to minify the output. Defaults to false.

Returns:

{
  "status": "success",
  "destination": "/path/to/site/public",
  "output": "Built in 123 ms"
}

Error Response:

{
  "status": "error",
  "message": "Site path '/path/to/site' does not exist"
}

Prerequisites: Hugo must be installed.

Actions After Success: The site is built and ready for deployment.

Actions After Failure: The site is not built.

deploy_site

Description: Deploy a Hugo site to various platforms.

Parameters:

site_path: The path to the Hugo site.
platform: Deployment platform (github-pages, netlify, vercel, custom).
destination (optional): Build destination directory. Defaults to "public".
branch (optional): Branch to deploy to. Defaults to "main".
commit_message (optional): Commit message for the deployment. Defaults to "Update site".
remote_url (optional): Remote URL for custom deployment.
api_key (optional): API key for the deployment platform.
additional_options (optional): Additional platform-specific options.

Returns:

{
  "status": "success",
  "platform": "github-pages",
  "branch": "gh-pages",
  "url": "https://username.github.io"
}

Error Response:

{
  "status": "error",
  "message": "Deployment failed: GitHub Pages deployment failed: Command 'git push origin gh-pages --force' returned non-zero exit status 1."
}

Prerequisites:

Hugo must be installed.
Git must be installed.
For GitHub Pages: Git repository must be initialized.
For Netlify: Netlify CLI must be installed (will be installed automatically if not present).
For Vercel: Vercel CLI must be installed (will be installed automatically if not present).

Actions After Success: The site is deployed to the specified platform and accessible at the returned URL.

Actions After Failure: The site is not deployed.

Platform-specific notes:

GitHub Pages: Requires a Git repository and optionally an API key for authentication.
Netlify: Requires Netlify CLI and optionally an API key for authentication.
Vercel: Requires Vercel CLI and optionally an API key for authentication.
Custom: Requires a Git repository and a remote URL.

Complete Workflow Example

Here's a complete workflow example (in python scripts rather than mcp server tools to show the common route) for creating a new Hugo site with a theme:

Check if Hugo is installed:

result = await check_hugo_installation()
if result["status"] != "success":
    result = await install_hugo()

Check if Git is installed:

result = await check_git_installation()
if result["status"] != "success":
    result = await install_git()

Configure Git:

result = await configure_git("John Doe", "john.doe@example.com")

List available themes:

result = await list_themes()
themes = result["themes"]

Get details for a specific theme:

result = await get_theme_details("Paper")
theme_details = result["theme"]

Create a new site with the theme:

result = await create_site("my-blog", theme="nanxiaobei/hugo-paper", use_example_site=True)
site_path = result["path"]

Start the preview server:

result = await start_preview(site_path, build_drafts=True)
preview_url = result["url"]

Create a new post:

result = await create_post(site_path, "my-first-post", draft=False)
post_file = result["file"]

Build the site for production:

result = await build_site(site_path, minify=True)

Deploy the site to GitHub Pages:

result = await deploy_site(
    site_path=site_path,
    platform="github-pages",
    branch="gh-pages",
    commit_message="Deploy site",
    api_key="your-github-token"
)
deploy_url = result["url"]

Troubleshooting

Common Issues

Hugo is not installed:
- Use the install_hugo tool to install Hugo.
Git is not installed:
- Use the install_git tool to install Git.
Theme installation fails:
- Check if the theme URL is correct.
- Make sure Git is installed for git submodules.
- Make sure Go is installed for Hugo modules.
- Read the theme's doc to check if there is sth. different
Preview server fails to start:
- Check if the port is already in use.
- Make sure the site path is correct.
- Check your network
Build fails:
- Check if the site path is correct.
- Make sure all required dependencies are installed.

Getting Help

If you encounter any issues not covered in this documentation, please open an issue on the GitHub repository.

Available Tools

15 tools

build_siteC

Build the Hugo site for production

ParametersJSON Schema

Name	Required	Default
`minify`	No
`site_path`	Yes
`destination`	No	public
`clean_destination`	No

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only says 'Build the Hugo site for production' but does not disclose what build entails (compilation, asset processing), side effects (overwrites public folder?), or required permissions. This is insufficient.

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 extremely concise (one short sentence) but at the expense of valuable information. It lacks details that would justify such brevity; effective conciseness requires front-loading essential content, which is missing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, no annotations, and 4 undocumented parameters, the description fails to provide necessary context for a build tool. It omits behavior (e.g., minification, destination directory), prerequisites, and side effects, making it inadequate for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 4 parameters with 0% description coverage, and the description adds no meaning to any parameter. It does not explain site_path, minify, destination, or clean_destination, leaving the agent with no guidance on parameter usage.

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 'Build the Hugo site for production', providing a specific verb (Build), resource (Hugo site), and context (for production). This distinguishes it from sibling tools like create_site, deploy_site, and start_preview.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives. For instance, it does not differentiate from deploy_site or start_preview, nor does it mention prerequisites like having Hugo installed or site configured.

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

check_git_installationA

Check if Git is installed and get its configuration

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only states the action without explaining what happens if Git is not installed, what configuration is returned, or any side effects. Minimal behavioral disclosure.

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

Conciseness5/5

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

The description is a single sentence, concise and front-loaded. Every word adds value, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description is adequate in a minimal sense. However, it lacks details on return values or error conditions, which would be helpful for an agent to process the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the input schema has 100% coverage. With no params, the baseline is 4, and the description adds no parameter information, which is acceptable.

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 verb 'Check' and the resource 'Git installation', and mentions getting configuration. It distinguishes itself from sibling tools like check_hugo_installation and check_go_installation.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, such as when Git-related features are needed. The description does not provide context or exclusions.

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

check_go_installationA

Check if Go is installed and get its version

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It implies a read-only check but does not explicitly state that there are no side effects, no authentication requirements, or what happens if Go is not installed. It is minimally transparent.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no unnecessary words. It effectively communicates the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description covers the basic action but lacks details about the return format or error handling. It is adequate for a trivial check but could be more complete.

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?

There are zero parameters and schema coverage is 100% (empty schema). The description adds no parameter information, which is acceptable since there are none. Baseline 3 applies.

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 verb 'Check' and the resource 'Go installation' and specifies that it retrieves the version. It is distinct from siblings like 'check_hugo_installation' and 'check_git_installation'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'check_hugo_installation' or 'get_system_info'. No explicit when/when-not or usage context is given.

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

check_hugo_installationA

Check if Hugo is installed and get its version

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

The description implies a read-only check but does not explicitly state that it is non-destructive or whether it might attempt to install Hugo. With no annotations, the description could be more transparent about side effects.

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

Conciseness5/5

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

A single sentence that is concise and front-loaded with essential information. No extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the purpose is clear, the description lacks details about the return format (e.g., version string or boolean), which is important since no output schema exists. This leaves the agent guessing about the response structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so schema coverage is 100%. The description does not add param-specific information, which is acceptable for zero-parameter tools.

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 checks if Hugo is installed and retrieves its version, using a specific verb and resource. It differentiates from sibling tools like check_go_installation and check_git_installation.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, such as the sibling system-info tools. It does not mention prerequisites or exclusions.

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

create_postC

Create a new Hugo post

ParametersJSON Schema

Name	Required	Default
`date`	No
`draft`	No
`site_path`	Yes
`post_title`	Yes
`content_type`	No	posts

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states 'Create' without mentioning side effects, file creation behavior, or requirements. This leaves the agent uninformed about potential impacts.

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 very concise (5 words) but lacks structure and substance. Under-specification reduces its usefulness beyond the bare minimum.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, no output schema, and no annotations, the description provides virtually no context. It is insufficient for the agent to understand the tool's behavior or usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not mention or explain any of the 5 parameters. The agent gets no insight into what each parameter means or how to use them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and the resource 'a new Hugo post', matching the tool name. However, it does not differentiate from sibling tools like create_site or list_content, which limits clarity for distinguishing use cases.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The agent receives no help in deciding to invoke it.

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

create_siteC

Create a new Hugo site

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`site_name`	Yes
`site_abs_path`	Yes
`in_current_dir`	No

TDQS

C2.3/5.0

Behavior2/5

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

No annotations provided, so description must convey behavior. Only states 'Create', but no details on side effects (e.g., directory creation, configuration files), error conditions, or required dependencies like Hugo installation.

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?

Extremely concise but under-specified. A single phrase lacks necessary context; important information is omitted for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to provide enough context for correct tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description does not mention any parameters. With 0% schema coverage, the agent has no help understanding 'site_abs_path', 'site_name', 'force', or 'in_current_dir' beyond their names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description 'Create a new Hugo site' clearly states verb and resource, distinguishing it from siblings like create_post or install_theme. However, it lacks specificity about what 'creating a site' entails.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. Does not mention prerequisites, directory requirements, or when not to use (e.g., if site already exists).

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

deploy_siteC

Deploy a Hugo site to various platforms

ParametersJSON Schema

Name	Required	Default
`branch`	No	main
`api_key`	No
`platform`	Yes
`site_path`	Yes
`remote_url`	No
`destination`	No	public
`commit_message`	No	Update site
`additional_options`	No

TDQS

C2.1/5.0

Behavior1/5

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

No annotations exist, so description must disclose behavior. It does not mention whether deployment overwrites remote, requires authentication, or any other behavioral traits.

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 single sentence is concise but severely under-specifies the tool for its complexity. Not structured for quick comprehension of capabilities.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters, no output schema, and no annotations, the description is far too sparse to guide correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description adds nothing about the 8 parameters. Provides no meaning beyond what is in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Deploy') and resource ('Hugo site'), but 'various platforms' is vague and does not distinguish from sibling 'build_site'.

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

Usage Guidelines2/5

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

No guidance on when to use deploy_site vs alternatives, no prerequisites mentioned, and no exclusions or context for usage.

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

get_system_infoC

Get system information

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.1/5.0

Behavior1/5

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

No annotations are present, and the description lacks any disclosure of behavioral traits such as side effects, idempotency, or data sources.

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?

While extremely short (4 words), the description is under-specified and fails to convey essential context, making it insufficient rather than concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and zero parameters, the description should indicate what system information is returned (e.g., OS, versions), but it does not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and 100% schema coverage, the description does not need to add parameter details. Baseline of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get system information' is a tautology of the tool name, providing no additional clarification or differentiation from sibling tools.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like check_hugo_installation or list_themes.

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

get_theme_detailsC

Get detailed information about a specific Hugo theme

ParametersJSON Schema

Name	Required	Description	Default
`theme_name`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description should reveal behavioral traits such as whether the tool is read-only, requires authentication, or has rate limits. It only states 'get detailed information', which is insufficient for safe invocation.

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?

The description is a single concise sentence that directly states the tool's purpose. It is front-loaded but could benefit from additional context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is a simple query with one parameter and no output schema, the description is overly minimal. It does not explain what information is returned or any constraints, leaving the agent with insufficient context for decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, 'theme_name', has no description in the schema (0% coverage) and the tool's description adds no meaning beyond its name. The agent is left to infer what values are valid.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches detailed information about a specific Hugo theme, distinguishing it from sibling tools like list_themes which lists all themes. However, it could be more specific about what 'detailed information' includes.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like list_themes or other sibling tools. The description lacks any when-to-use or when-not-to-use context.

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

install_themeD

Install a Hugo theme

ParametersJSON Schema

Name	Required	Description	Default
`site_path`	Yes
`theme_url`	Yes
`theme_name`	Yes
`use_go_module`	No

TDQS

D1.9/5.0

Behavior1/5

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

With no annotations, the description must disclose behavioral traits. It fails to mention side effects (e.g., filesystem changes, network requests), required permissions, or what happens if the theme already exists. The single word 'Install' is insufficient.

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 a single short sentence, which is concise but overly terse. It lacks structure and critical details, making it under-specified rather than efficiently written.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters (3 required), no output schema, and no annotations, the description fails to provide adequate context for correct invocation. It does not explain installation requirements, process, or expected outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the tool description does not mention any parameters. It adds no meaning beyond the schema's bare names and types. For example, it does not explain what 'site_path' or 'theme_url' represent or how they interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'install' and the resource 'a Hugo theme', distinguishing it from sibling tools like list_themes which list themes. However, it lacks specificity about what 'install' entails (e.g., downloading from a URL, adding to a site).

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

Usage Guidelines1/5

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

No usage guidance is provided. There is no mention of when to use this tool versus alternatives like update_theme or get_theme_details, nor prerequisites such as having Hugo or Git installed.

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

list_contentC

List content in the Hugo site

ParametersJSON Schema

Name	Required	Description	Default
`site_path`	Yes
`content_type`	No

TDQS

C2.2/5.0

Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It only says 'List content', omitting details on return format, side effects, authentication requirements, or rate limits. This is insufficient for an agent to understand its full behavior.

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?

At four words, the description is extremely concise but under-specified. It fails to provide necessary context that the agent needs, making it a case of under-specification rather than efficient conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, no annotations, and only two parameters, the description is completely inadequate. It does not explain what is returned, how to filter content, or any other contextual information needed for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds no explanation for the two parameters ('site_path' and 'content_type'). The parameter names are somewhat self-explanatory, but the description does not add value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'List content in the Hugo site', providing a specific verb and resource. However, it does not differentiate from sibling tools such as 'create_post' or 'list_themes', which also deal with content lists.

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

Usage Guidelines2/5

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

The description offers no guidance on when to use this tool versus other sibling tools like 'list_themes' or 'build_site'. There are no usage notes, prerequisites, or alternative recommendations.

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

list_themesA

List available Hugo themes from the official Hugo themes website

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the full burden. It states it's a list operation from an official website, which implies read-only behavior. However, it does not disclose potential traits like network latency, caching, or format of the result.

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

Conciseness5/5

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

Single sentence of 12 words, front-loaded with the verb and resource. Extremely concise with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description does not fully explain the return value (e.g., whether it returns names, URLs, or metadata). It implies a list but lacks specificity about the output structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100% by default. Per guidelines, zero-parameter tools get a baseline of 4. The description adds no parameter details, but none are needed.

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 verb 'List' and the resource 'available Hugo themes' with the source 'official Hugo themes website'. It distinguishes well from siblings like 'install_theme' and 'get_theme_details'.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. Usage is implied from the description (list themes), but no when/not or alternative recommendations are provided.

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

start_previewC

Start Hugo local server for preview

ParametersJSON Schema

Name	Required	Default
`bind`	No	127.0.0.1
`port`	No
`site_path`	Yes
`build_drafts`	No
`build_future`	No
`build_expired`	No

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, and the description only states the action without disclosing any behavioral traits. It does not mention that the server will run in the background, require stopping via 'stop_preview', or any permissions or resource usage.

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?

The description is extremely concise at one sentence with no wasted words. However, it could benefit from additional structure, such as a brief note on usage or parameters, without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema and minimal annotations, the description does not provide enough context for a complex tool with 6 parameters. It lacks information about the server's behavior, return value, or how to interact with it (e.g., stopping, accessing preview URL).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no information about any of the 6 parameters. With 0% schema description coverage, the burden falls entirely on the description, but it fails to explain what 'site_path' represents or the meaning of 'bind', 'port', 'build_drafts', etc.

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 action ('Start Hugo local server') and the purpose ('for preview'). It distinguishes the tool from its sibling 'stop_preview' and other build tools like 'build_site'.

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

Usage Guidelines2/5

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

No usage guidance is provided. The description does not specify when to use this tool vs alternatives (e.g., 'build_site' for production, 'stop_preview' to stop). It lacks context such as prerequisites or typical workflow.

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

stop_previewB

Stop a running Hugo preview server

ParametersJSON Schema

Name	Required	Description	Default
`pid`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It states the action but does not disclose potential side effects, such as requiring correct PID, or behavior if the server is not running. The behavior is generally understood but lacks detail.

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

Conciseness5/5

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

The description is a single, grammatically correct sentence that efficiently conveys the tool's purpose with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one required parameter and no output schema, the description is adequate but could be improved by explaining the 'pid' parameter or prerequisites like a running server.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description does not explain the 'pid' parameter, which is required. It merely repeats the schema's title without adding meaning, leaving the agent to guess what the integer represents.

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 action ('Stop') and the resource ('a running Hugo preview server'), differentiating it from sibling tools like 'start_preview' or 'build_site'.

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

Usage Guidelines3/5

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

The description implies usage after starting a preview server, but it does not explicitly state when to use this tool over alternatives or provide conditions like 'use when the preview server is running'.

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

update_themeC

Update an installed Hugo theme

ParametersJSON Schema

Name	Required	Description	Default
`site_path`	Yes
`theme_name`	Yes
`use_modules`	No

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states 'Update an installed Hugo theme' without disclosing what happens during the update (e.g., whether it updates to the latest version, if it prompts for input, or if it can revert changes). The description lacks detail on side effects, reversibility, or required permissions.

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

Conciseness3/5

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

The description is extremely concise (one sentence) but at the cost of being vague. While it avoids unnecessary text, it lacks sufficient detail to be useful. A slightly longer description with key context would improve it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has three parameters, no output schema, and no annotations, the description is completely inadequate. It does not cover prerequisites, return values, side effects, or any usage context beyond the bare action. This fails to support correct agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the schema provides no documentation for the three parameters ('site_path', 'theme_name', 'use_modules'). The description does not explain any parameter, leaving the agent to guess the meaning and valid values. This is insufficient for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and the resource ('an installed Hugo theme'). It distinguishes from the sibling 'install_theme' since installing is different from updating. However, it does not explicitly differentiate from other siblings like 'get_theme_details', but the verb and resource make the purpose clear.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives such as 'install_theme' (for new themes) or 'get_theme_details' (for checking version). The description does not mention prerequisites (e.g., theme must already be installed) or when an update is appropriate.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

15 tool updatesv0.1.0Jul 30, 2026
- First observedbuild_site
- First observedcheck_git_installation
- First observedcheck_go_installation
- First observedcheck_hugo_installation
- First observedcreate_post
- First observedcreate_site
- First observeddeploy_site
- First observedget_system_info
- First observedget_theme_details
- First observedinstall_theme
- First observedlist_content
- First observedlist_themes
- First observedstart_preview
- First observedstop_preview
- First observedupdate_theme

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-07-30 05:35 across 15 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: installation checks, site/content creation, preview management, building, theme operations, and deployment. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., install_theme, create_site, list_themes). No mixing of conventions or vague verbs.

Tool Count5/5

15 tools cover the core Hugo workflow—setup, content creation, preview, build, theme management, and deploy—without being excessive. Each tool earns its place.

Completeness4/5

The tool surface covers the main lifecycle, but lacks update/delete operations for content and themes. A minor gap given typical agent needs.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
ArletOAuth
dev.arlet
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Developer Tools CI/CD & DevOps
2
JFrog Remote MCP Server
io.github.jfrog
MCP Server for JFrog, providing tools for development and artifact management.
Developer Tools CI/CD & DevOps Cloud Platforms
215
vercel-mcpOAuth
com.vercel
An MCP server for Vercel
Cloud Platforms Developer Tools CI/CD & DevOps
2

Related MCP Servers

MCP NPX Fetch
Web Scraping Browser Automation RAG Systems
tokenizin-agency
A
license
A
quality
D
maintenance
A powerful MCP server for fetching and transforming web content into various formats (HTML, JSON, Markdown, Plain Text) with ease.
Updated 2 years ago (2024-12-26 09:28 UTC)
4
6,255 npm
41
MIT
DevServer MCP
Developer Tools Browser Automation App Automation
Uninen
A
license
Not graded
quality
F
maintenance
An MCP server that enables programmatic management and monitoring of development servers through a unified interface and interactive TUI. It provides tools for process control, log streaming, and experimental browser automation via Playwright.
Updated 2 months ago (2026-07-11 02:41 UTC)
1
MIT
Minecraft Ops MCP
Games & Gamification App Automation OS Automation
damocjwj
A
license
B
quality
D
maintenance
An MCP server for managing and operating Minecraft servers through multiple backend protocols including MCSManager API, RCON, and MSMP. It provides tools for instance lifecycle management, file operations, console commands, player administration, and server configuration with built-in security controls.
Updated 5 months ago (2026-04-15 16:40 UTC)
71
2
MIT
project-scaffold
Developer Tools CI/CD & DevOps Cloud Platforms
dawiegriesel
A
license
A
quality
D
maintenance
An MCP server that scaffolds full-stack projects with consistent structure, Docker setup, CI/CD pipelines, and database configuration.
Updated 7 months ago (2026-02-16 14:52 UTC)
6
MIT

Hugo MCP Server

Table of Contents

Installation

Prerequisites

Installing the Hugo MCP Server

Usage

Basic Usage

Tools

Environment Setup Tools

check_hugo_installation

install_hugo

check_go_installation

install_go

check_git_installation

install_git

configure_git

Site Management Tools

create_site

Theme Management Tools

list_themes

get_theme_details

install_theme

update_theme

Content Management Tools

create_post

list_content

Preview and Build Tools

start_preview

stop_preview

build_site

deploy_site

Complete Workflow Example

Troubleshooting

Common Issues

Getting Help

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers