This document provides essential instructions for autonomous coding agents (like Copilot, Cursor, OpenCode, Gemini, etc.) operating within the SysMetrics MCP repository.
- Name: SysMetrics MCP
- Type: Model Context Protocol (MCP) Server for Linux system metrics.
- Language: Go 1.25.6+
- Architecture:
cmd/sysmetrics-mcp(entrypoint),internal/config(CLI/config parsing),internal/handlers(core metrics logic). - Key Libraries:
github.com/mark3labs/mcp-go(MCP Framework),github.com/shirou/gopsutil/v3(System Metrics).
We use a Makefile for standard development tasks. Always prefer these targets to ensure consistency.
- Build:
make build- Compiles the project to
bin/sysmetrics-mcpwithCGO_ENABLED=0.
- Compiles the project to
- Run Locally:
go run . [flags] - Format Code:
make fmt(runsgo fmt ./...) - Lint Code:
make lint(runsgolangci-lint runandgo vet ./...) - Update Dependencies:
make deps(runsgo mod downloadandgo mod tidy)
Tests are critical. Always verify your changes before finalizing them.
- Run all tests:
make test # Under the hood: CGO_ENABLED=0 go test -v ./...
- Run tests in a specific package:
CGO_ENABLED=0 go test -v ./internal/handlers - Run a single test (highly recommended for TDD/debugging):
CGO_ENABLED=0 go test -v -run ^TestFunctionName$ ./internal/handlers - Run tests with coverage:
CGO_ENABLED=0 go test -coverprofile=coverage.out ./... && go tool cover -func=coverage.out
Adhere strictly to standard Go idioms and the existing patterns in this repository.
- Formatter: Use standard
go fmt. Runmake fmtbefore committing. - Imports: Group imports into three distinct blocks separated by a blank line:
- Standard library packages.
- Third-party packages (e.g.,
github.com/shirou/gopsutil/v3/...). - Internal project packages (
sysmetrics-mcp/internal/...).
- Linter Strictness: The project uses
golangci-lintwith strict rules (e.g.,revive,gosec,gocritic). Your code must passmake lintcleanly without adding#nosecornolintpragmas unless absolutely necessary and documented.
- General: Use
camelCasefor variables andPascalCasefor exported identifiers. - Acronyms: Keep initialisms uppercase (e.g.,
HTTPClient,UserID, notHttpClientorUserId). - Interfaces: Interface names should typically end in
-er(e.g.,MetricFetcher,ConfigParser). - Packages: Package names should be short, lowercase, and avoid snake_case or hyphens. Do not use generic names like
utilorcommon.
- Do not panic: The server must run continuously. Never use
panic()orlog.Fatal()inside handlers or internal packages. - MCP Errors: Handlers must return structured error messages via
mcp.NewToolResultErrorinstead of crashing the server or returning raw Go errors to the MCP transport. - Contextual Errors: When returning errors internally, wrap them to provide context:
return fmt.Errorf("failed to fetch disk metrics for %s: %w", mountPoint, err)
- Graceful Degradation: If a specific metric fails to load (e.g., Raspberry Pi GPU temp on a standard Linux machine), log a warning or return
N/Ainstead of failing the entire tool request.
- Favor strong typing. Avoid
interface{}(orany) unless implementing generic data structures. - Use pointers for structs only when they need to be mutated or when passing large configurations. Otherwise, pass by value.
- Prefer explicit struct initialization over positional arguments.
- Table-Driven Tests: Use table-driven tests for complex logic (refer to existing tests in
config_test.go). - Mocking: Handlers are unit tested by mocking or calling them directly with a context (
handlers_test.go). Focus on testing the business logic independently of the MCP transport layer. - Asserts: Use standard library
testingpackage patterns. Avoid heavy third-party assertion libraries unless already present in thego.mod.
- Platform Awareness: The code detects Raspberry Pi hardware to provide additional metrics (GPU temp, throttling). Keep fallback paths clean for generic Linux environments.
- Tools Addition: When adding a new MCP tool, ensure it is properly registered in
cmd/sysmetrics-mcp/main.goand its handler is implemented ininternal/handlerswith appropriate error handling and JSON serialization.
When acting on user requests in this repository:
- Understand Context: Read
Makefile,.golangci.yml, andGEMINI.mdto understand constraints. Usegrepandglobto locate relevant handler files before writing code. - Plan: Write out a concise plan including the exact files to be modified and tests to be written.
- Execute: Modify the code using absolute file paths.
- Self-Verify: ALWAYS run
make fmt,make lint, and the specificgo test -run ...command for the code you touched. Do not finalize until these pass.