Boris Eetgerink

September 8, 2026

Claude Bug Hunt Routine v2

So last time I had a proof of concept running of a Claude Routine that automatically fixes bugs in an Umbraco implementation, based on the Umbraco log viewer management API. Now with the Umbraco MCP server I have greatly simplified the routine. The setup now:

API User & Client credentials

Like before, add an API user and add client credentials. Unlike before, there is no recommended Client Id naming scheme anymore. In their examples Umbraco uses the "umbraco-back-office-mcp" Client Id. With the following MCP server configuration, the Client Id doesn't have to be unique across implementations and environments.

MCP Server Configuration

Add the following .mcp.json file to the root of the project. Add it to version control.

{
  "mcpServers": {
    "umbraco-mcp": {
      "command": "npx",
      "args": ["@umbraco-cms/mcp-dev@lts-17"]
    }
  }
}

Add the following .env file to the root of the project. Gitignore it, do not add it to version control.

UMBRACO_CLIENT_ID=umbraco-back-office-mcp
UMBRACO_CLIENT_SECRET={ClientSecret}
UMBRACO_BASE_URL=https://{www.domain.com}/
UMBRACO_INCLUDE_TOOL_COLLECTIONS=log-viewer

Note that log-viewer is one of the available Tool Collections of the Umbraco MCP server. By specifying tool collections or individual tools, you can limit which access Claude has, besides the permissions as set on the API user.

Routine Instructions

The routine instructions are also a lot simpler now and don't ask for an explicit script execution. Instead, Claude determines, based on the available MCP tools and their description, that it should use the MCP server to load the logs.

Note that I explicitly stated "Use the MCP server", because on my first run Claude happily used the management API instead, because the MCP server didn't initialize quickly enough. With this guardrail Claude tries again if the MCP server is too slow to initialize.

Use the MCP server to get the log viewer fatal, error and warning levels from the past 24 hours and group them by level and similarity. For each group:
- Identity if the error is still in the main branch.
- If it is, create a branch with a short descriptive name in the following format: hotfix/{short-descriptive-name}
- Apply a fix and commit it on the new branch. Include in the commit message: a short description of the fix, why it works, the error message and the stack trace (if there is any). Do not push the new branch and/or create a PR.

Next Steps

That's all for now. In the next version I'll see if I can convert the routine instructions into a skill to further reduce the amount of boiler plate. Bonus if I can make it a Cloud routine, so it runs whether I have my laptop on or not.

About Boris Eetgerink

Hey, thanks for reading. I'm an Umbraco and .NET support specialist with over 20 years of development experience. I blog about whatever occupies my mind the most at the time. Feel free to connect with me on LinkedIn.