mcp-log-diagnosticslisted

# Diagnosing a Teams or Azure DevOps MCP server **The log file is the primary diagnostic surface**, because when a server runs under an MCP client nobody sees stderr. Default paths (override with `TEAMS_MCP_LOG_DIR` / `ADO_MCP_LOG_DIR`): ``` %LOCALAPPDATA%\teams-mcp\logs\teams-mcp.log %LOCALAPPDATA%\ado-mcp\logs\ado-mcp.log ``` One line per event, flushed per write, rolling to `.1` at 8 MB, `pid=` on every line since several server instances can share the file. Format: ``` {utc} {LVL} {pid} {event} req={n} {message} ``` Recipe: 1. `dotnet run --project src/<server> -- selftest` — separates "auth is broken" from "a tool is broken", and writes to the same log file. It prints the log path on the first line. 2. `dotnet run --project src/<server> -- call <tool> key=value…` — reproduces one tool call through the real server path (host, silent auth, `Run` wrapper, filters) without an MCP client: result JSON on stdout, the server's own log lines on stderr, non-zero exit on a tool error. Bare `call` lists the tools; arguments can also be one JSON object or `-` for JSON on stdin. This is the step that turns "the model saw an error" into a command you can iterate on. 3. Read the top of the log: the `startup` lines report version, runtime, which env vars are set, the gates (`sendEnabled` / `writeEnabled`, plus `approvalEnabled` for `approve_release`), the log settings, and whether an authentication record exists. 4. Grep an event name. The stable ones are `star