helix.mcp

An increasingly inaccurately named CLI and MCP server for AI agents investigating .NET CI/CD failures across Helix and Azure DevOps.

No MCP needed. hlx works as a standalone CLI — dnx lewing.helix.mcp (zero-install) or dotnet tool install -g lewing.helix.mcp. See the CLI reference.

Built with Squad — meet the squad.

Why?

AI agents investigating CI failures in dotnet repos (runtime, sdk, aspnetcore, etc.) hit two problems:

1. Raw APIs return too much data. A single Helix console log can be megabytes. The Azure DevOps build timeline returns hundreds of records. Dumping this into a context window wastes tokens and drowns the signal.
2. Every agent starts from scratch. When multiple agents — or the same agent across tool calls — inspect the same build, each one repeats the same API calls and downloads.

hlx solves both:

• Return less, return better. Tools like helix_search and azdo_search_log search in place and return only matching lines with context — agents never download a full log. helix_status returns structured failure summaries instead of raw JSON. Default tail limits (500 lines), filter parameters (failed by default), and maxMatches caps keep responses focused.
• Cache everything, share across processes. A local SQLite cache sits between agents and the APIs. Different MCP server instances (one per IDE window/terminal) share the same cache, so the second agent to inspect a job gets instant results. Smart TTLs track job lifecycle — running jobs cache briefly (15–30s), completed jobs cache for hours.

Zero config — public dotnet CI works out of the box. Install and go.

Context-Efficient Design

Every tool is designed to minimize token consumption in agent context windows: