Procal Ops Bot

This bot lives in a Telegram group topic and responds when mentioned or replied to, giving the cohort a conversational way to ask about incidents, review pull requests, and check on the procal infrastructure without leaving chat. It was built as a personal deep-dive alongside the DevOps Institute program, exploring how Claude and the Model Context Protocol (MCP) can support day-to-day operations work on top of the same procal stack described in the other case studies.

Architecture

Claude receives one unified tool list built from local Bitbucket tools plus whatever the connected MCP servers expose; the bot doesn't need to know which is which.

Tech stack

What it does

1. 1

   Incident triage

   Mention the bot about a service error and it checks active Grafana incidents, queries Loki error logs and Prometheus metrics, checks slow Tempo traces, and cross-references recent commits, then returns what happened, probable cause, and a recommended fix.

2. 2

   PR review, on request

   Ask it to review, approve, request changes on, or comment on a Bitbucket PR, and it acts directly through the Bitbucket API.

3. 3

   Auto PR review (polling)

   A background loop watches the infra repo's PRs every 5 minutes, runs a Terraform-focused review on any new PR or commit, posts it as a Bitbucket comment, and notifies the Telegram group, tracking which PRs/commits it already reviewed so it never double-reviews on restart.

4. 4

   Code fixes without cloning

   For simple fixes, it creates a branch off the PR's source branch, commits the fix via the Bitbucket source API, and opens a PR back to the author, with no local clone involved.

5. 5

   Audit trail

   Every write action (approvals, comments, branch commits, new PRs) is logged and sent as a Telegram notification to a configured audit chat.

Highlights

• A unified tool registry blends local Python tools (Bitbucket) with five separate MCP servers (Grafana, AWS, SonarQube, Jenkins, Git), some over stdio and one over HTTP, behind a single interface Claude calls into.
• AWS access is read-only by design, enforced twice: a `READ_OPERATIONS_ONLY` flag on the MCP server itself, plus a read-only IAM policy on the instance role, belt and suspenders on a bot that can act autonomously.
• A small FastAPI admin panel lets you toggle which tool groups (AWS, Bitbucket, Grafana, SonarQube, Jenkins, per-repo Git) are enabled per Telegram chat, without redeploying the bot.
• Credentials flow through the EC2 instance role via IMDS rather than static keys in `.env`, matching the same 'no long-lived credentials on disk' pattern used elsewhere in the program's infra work.
• PR-review polling state is persisted to disk, so a bot restart mid-cycle doesn't cause it to re-review PRs it already commented on.