MCP servers for PR template suggestions, GitHub Actions integration, and Slack notifications. Progressive learning project with three modules.
This is a teaching-focused MCP server collection across three modules with 7 tools total. The server demonstrates solid naming conventions (all start with action verbs) and has parameter schemas with types defined. However, there are significant gaps: descriptions are present but often generic, output schemas are not documented, error handling is minimal, and there is no evidence of permission checks or security hardening. The tools read source code and interact with git/GitHub/Slack but lack the production-grade polish of enterprise systems. As a reference implementation for a HuggingFace course, it serves its educational purpose, but falls short of production deployment standards.
Get the full diff and list of changed files in the current git repository.
Format output as a Slack message with proper markdown syntax.
List available PR templates with their content.
Get recent GitHub Actions events received via webhook.
Get the current status of GitHub Actions workflows.
Send a formatted notification to the team Slack channel.
Let Claude analyze the changes and suggest the most appropriate PR template.
Output schemas are not documented for any tool. LLMs cannot infer what fields to expect from responses, making multi-step tool composition error-prone. E.g., analyze_file_changes returns a string but the structure (JSON, text format, field names) is unclear.
No error handling guidance. Tools that call external services (git, GitHub, Slack) lack recovery hints. E.g., if git diff fails, should the LLM retry, ask the user, or try a different branch? Bare exception messages don't guide agent behavior.
get_pr_templates() takes no parameters and returns all templates. No pagination, limit, or filtering. If templates grow large, this forces the LLM to process verbose output. Should support pagination or filtering by template type.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
send_slack_notification is marked WRITE but has no confirmation/dry-run mechanism. Agents may send notifications accidentally. Consider adding a 'dry_run' parameter or requiring explicit confirmation before posting.
Parameter descriptions are generic or incomplete. E.g., 'message' in send_slack_notification just says 'supports Slack markdown' but doesn't explain max length, required formatting, or what happens if the message is empty. 'workflow_name' in get_workflow_status is optional but doesn't explain what happens if omitted (all workflows? latest only?).
No security checks visible. Tools handle git commands, GitHub API, and Slack tokens. No evidence of input sanitization against command injection, path traversal, or credential leakage in parameters. Slack token appears to be managed externally, which is good, but git commands and paths need defensive coding.
analyze_file_changes attempts to fetch roots via mcp.get_context().session.list_roots(), but Roots capability is deprecated (scheduled for removal ~2027-07-28). Should migrate to accepting working_directory as a parameter or via configuration, not relying on client-side root hints.