feat: update MCP server profile for distroless Hummingbird (v1.3.0)

[fatherlinux]

Summary

• Adds Distroless Runtime section documenting that Hummingbird runtime images have no shell
• Adds FIPS image variants (latest-fips, latest-fips-builder) to base images table
• Replaces broken wheel-based Containerfile example with venv pattern (old example used shell-form RUN in runtime stage, which fails on distroless)
• Adds exec-form RUN fallback guidance

Context

Hummingbird Python images went intentionally distroless as of 2026-03-25 rebuild (HUM-813). The previous constitution example Containerfile used RUN pip install ... (shell-form) in the runtime stage, which is now broken on all Hummingbird runtime images.

All CrunchTools MCP servers need to adopt the venv multi-stage pattern going forward.

Test plan

• Verified pattern works on mcp-slack (companion PR: crunchtools/mcp-slack)
• Review profile version bump (1.2.0 → 1.3.0)

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request updates the MCP server profile documentation to reflect recent changes in Hummingbird Python images, which are now intentionally distroless. The update provides critical guidance on adapting multi-stage Dockerfile patterns to work with these minimal images, specifically promoting a venv-based approach and introducing FIPS-compliant image variants.

Highlights

• Documentation Update: The MCP server profile documentation has been updated to version 1.3.0.
• Distroless Runtime Guidance: A new section was added to explain the implications of Hummingbird runtime images being distroless, including guidance on avoiding shell-form RUN commands and preferring the venv pattern.
• FIPS Image Variants: FIPS-compliant image variants (latest-fips, latest-fips-builder) were added to the base images table.
• Multi-Stage Build Pattern: The recommended multi-stage Containerfile example was updated to use a venv-based pattern, replacing the previous wheel-based approach which is incompatible with distroless runtimes.
• libstdc++ Copy Instruction: The example for copying libstdc++ was updated to reference the FIPS builder image.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the MCP Server Profile documentation to version 1.3.0, introducing guidelines for using distroless Hummingbird base images, specifically for Python applications. It details a venv-based multi-stage build pattern, explains the implications of distroless runtimes, and incorporates FIPS-compliant Python images. The example Dockerfile and libstdc++ copy instructions have been updated accordingly. Feedback indicates that the example Dockerfile's current file copy order is not optimal for build caching, which could lead to slower builds, and suggests reordering steps to install dependencies before copying application source code to improve efficiency, in line with repository style guide requirements for CI workflows.

[gemini-code-assist]

The current file copy order in this example is not optimal for build caching. Any change in src/ will cause all Python dependencies to be re-installed, because COPY src/ ./src/ comes before RUN pip install .. This can slow down builds significantly.

To leverage build caching more effectively, it's recommended to install dependencies before copying the application source code. This typically involves a multi-step process:

1. Copy pyproject.toml.
2. Install dependencies from it.
3. Copy the src directory.
4. Install the project itself (e.g., with --no-deps).

Since this is a documented pattern, showing a more cache-efficient approach would be beneficial for developers following this guide.

References

1. The repository style guide mandates build caching for CI workflows (line 24). While this example is in documentation, it presents a pattern that will be used in CI. An inefficient pattern for layer caching goes against the spirit of this rule and will lead to slower builds. ^(link)