AGENTS.md

Scope

LazyBearWorks.sln builds exactly one project: LazyBear.MCP/. Libraries/Confluence/ is present in the repo but is not part of the solution and has no .csproj; ignore it unless the user explicitly asks for it.

Trust LazyBear.MCP/Program.cs and project config over README.md. The README describes Razor Pages/UI and a broader tool surface, but the current app only configures MCP HTTP transport and auto-registers tool classes from the assembly.

Main app entrypoint: LazyBear.MCP/Program.cs.
Live MCP tools are discovered via AddMcpServer().WithHttpTransport().WithToolsFromAssembly(). Current tool classes are under LazyBear.MCP/Services/Kubernetes/ and LazyBear.MCP/Services/Jira/ and use [McpServerToolType].
Do not assume Razor Pages are active just because Pages/ exists: Program.cs does not call AddRazorPages() or MapRazorPages().

Build from repo root: dotnet build
Build project directly: dotnet build "LazyBear.MCP/LazyBear.MCP.csproj"
Run from repo root: dotnet run --project "LazyBear.MCP"
MCP manual check: npx @modelcontextprotocol/inspector dotnet run --project LazyBear.MCP
There are no test projects in the solution right now; default verification is dotnet build, plus a focused run/inspector check for transport or tool-registration changes.

LazyBear.MCP/Properties/launchSettings.json says http://localhost:5079, but the app actually listens on http://localhost:5000 because Program.cs hardcodes app.Run("http://localhost:5000").
SDK pin is in LazyBear.MCP/global.json (10.0.100), not at the repo root.

App config lives in LazyBear.MCP/appsettings.json.
Kubernetes:KubeconfigPath defaults empty. K8sClientFactory then tries the default kubeconfig, then in-cluster config.
Jira tools require Jira:Url; if it is empty, JiraClientFactory throws during provider setup. The app still starts because providers capture init errors and tools return those errors as strings.
Treat appsettings.json values as potentially sensitive; do not commit real Jira tokens or cluster-specific settings.