Phase 5: Model Context Protocol (MCP) · 90 min · Python · MCP SDK · GitHub API

Real Integrations — GitHub, Slack, Postgres

Defense in depth: safety lives in the tool layer, not just in the prompt.

Hiring signal: Real integration code is the portfolio material that gets AI engineers hired. Companies with existing GitHub, Slack, and Postgres infrastructure see immediate value in a candidate who has working MCP servers for all three. Ship it, put it on GitHub, link it on your resume.

What you will learn

Build a GitHub MCP server with PAT auth and scoped-to-safe operations only (no destructive tools)
Build a Slack MCP server with Bot Token auth and exponential backoff for rate limits
Build a Postgres MCP server with read/write user separation, parameterized queries, row limits, and blocked DDL

The Problem

Theory is done. This lesson builds production-grade MCP servers for three tools that appear in nearly every company's stack: GitHub for code and issues, Slack for team communication, and Postgres for business data.

Each integration has sharp edges. GitHub's API requires a Personal Access Token and returns paginated results in nested JSON. Slack enforces per-method rate limits and has message timestamps as first-class identifiers. Postgres is a live database where a model-generated SELECT * on a 5-million-row table without a LIMIT will OOM your server, and a DROP TABLE on the wrong prompt injection would be catastrophic.

The right approach isn't to hope the model behaves. Safety goes in the tool layer: hardcoded row limits, read-only database users, blocked DDL operations, explicit write confirmation. Defense in depth means the system is safe even when the model does something unexpected.

Principle of least privilege for AI tools
Each MCP server connection should have only the permissions required for its intended operations. The read query tool uses a database user with only SELECT. The write tool uses a separate user. Even if the model is deceived into trying a DROP TABLE, the connection lacks permission to execute it.

GitHub MCP Server

The GitHub REST API is well-documented and returns structured JSON. Authentication: Authorization: Bearer <PAT> header. Your PAT only needs the scopes required for your tools — repo:read and issues:write covers the core use cases.

What to expose:

search_repositories — find projects, check ecosystem health
get_issue — full issue details by number
list_issues — browse open issues by label, state
create_issue_comment — post AI-generated analysis or summaries
list_pull_requests — track open PRs
search_code — find examples, check usage patterns

What NOT to expose: delete_repository, force_push, delete_branch. Destructive operations should not be AI-callable tools. If a user needs them, they use the GitHub UI directly.

Return schemas should be stable and minimal: repos return {id, full_name, description, stars, language, url}. Issues return {number, title, body, state, labels, assignees, url}. Consistent schemas make the model's output predictable.

Your Postgres MCP server's execute_query tool should enforce a row limit (e.g., LIMIT 1000) because:

Models don't know your table sizes. "Show me all customer records" on a 5M-row table without a limit causes a multi-GB result set, OOM errors, and a broken context window. The MCP server must enforce safety limits as a hard constraint — not hope the model will add LIMIT itself. Defense in depth: safety at the tool layer, not just in the prompt.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Slack MCP Server, Postgres MCP Server, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.