You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
So no issues if distroless is a requirement. But at this point in the development, it is premature for the MCP Server itself and for non-production use-cases. We could easily have multiple docker files to accomodate distroless and not distroless.
Using a distroless container image means your container includes only your application and its runtime — no shell, no package manager, no debugging tools.
That sounds ideal, especially prematurely when adding new functionality/components to a system that may require higher visibility/observability in a given system.
Here are the main reasons why using a distroless image can be a bad idea: #1 Debugging Becomes Painful
Distroless images don’t include: bash / sh curl ps netstat apt / yum
i.e. Most standard Linux tools
If something goes wrong in production, you can’t exec into the container and inspect it. Because there is no shell.
This makes incident response slower and more complex. You need:
Sidecar debug containers
Ephemeral debug images
Rebuilds just to inspect behavior
That’s fine for mature software. Not so great for fast-moving agile software development.
#2 Local Development Becomes Friction-Filled
Distroless is great for production minimalism.
It’s terrible for:
Experimentation
Rapid troubleshooting
Investigating weird runtime edge cases
Developers often end up maintaining:
One Dockerfile for dev
One for prod
Now you have divergence risk.
#3 Observability Tooling Limitations
Many debugging or monitoring tools assume basic OS utilities exist.
If you rely on:
Runtime profilers
On-the-fly tracing
Crash dump analysis
Temporary diagnostics
You may discover the container simply doesn’t support what you need.
#4 Operational Complexity Increases
Distroless pushes complexity outward.
Instead of “Let’s exec in and look.”
You now need:
Debug sidecars
Separate debug images
Stronger logging discipline
More complete telemetry
If your observability is weak, distroless will expose it brutally.
/bin/sh exists for subprocesses
Distroless images may omit or minimally include these.
You discover issues at runtime.
#6 Security Gains May Be Marginal
Distroless is often sold as “more secure.”
But:
The real attack surface is usually your application.
Most container exploits rely on runtime vulnerabilities, not bash.
A properly hardened minimal distro (e.g., Alpine or slim Debian) may provide nearly identical risk reduction.
Security benefit is real — but sometimes overstated.
#7 Not Ideal for Dynamic Environments
If your application:
Installs plugins dynamically
Runs scripts
Uses subprocess-heavy workflows
Executes user-provided commands
Distroless can break those assumptions.
The reason will be displayed to describe this comment to others. Learn more.
It will be a requirement for production (a ton of customer have requested it because of the amount of CVEs that are eliminated), but your points are valid for rapid iteration/development. That said, for rapid iteration, you should also be able to run it locally/dev container that has obserability/tools. We also prefer to rely on high and strong logging discipline.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
This README documents the MCP server, but the repo’s main feature docs live under docs/explanation/features/<version>/.... Consider adding a corresponding feature doc there (and linking to this README) so the new external integration is discoverable alongside other SimpleChat features.
Suggested change
For a high-level overview of this integration alongside other SimpleChat features, see the MCP feature documentation under `docs/explanation/features/<version>/MCP_SERVER_INTEGRATION.md`.
| **list_group_workspaces** | Required | `GET /api/groups` | Returns paginated group workspaces the user is a member of. Params: `page`, `page_size`, `search`. |
| **list_group_documents** | Required | `GET /api/group_documents` | Returns documents from the user's active group. Params: `page`, `page_size`, `search`, `classification`, `author`, `keywords`. |
| **list_group_prompts** | Required | `GET /api/group_prompts` | Returns prompts from the user's active group. Params: `page`, `page_size`, `search`. |
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason this would not run in a distroless (mcr.microsoft.com/azurelinux/distroless/python:3.12) multi-step build like the core app?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So no issues if distroless is a requirement. But at this point in the development, it is premature for the MCP Server itself and for non-production use-cases. We could easily have multiple docker files to accomodate distroless and not distroless.
Using a distroless container image means your container includes only your application and its runtime — no shell, no package manager, no debugging tools.
That sounds ideal, especially prematurely when adding new functionality/components to a system that may require higher visibility/observability in a given system.
Here are the main reasons why using a distroless image can be a bad idea:
#1 Debugging Becomes Painful
Distroless images don’t include:
bash/shcurlpsnetstatapt/yumIf something goes wrong in production, you can’t exec into the container and inspect it. Because there is no shell.
This makes incident response slower and more complex. You need:
That’s fine for mature software. Not so great for fast-moving agile software development.
#2 Local Development Becomes Friction-Filled
Distroless is great for production minimalism.
It’s terrible for:
Developers often end up maintaining:
Now you have divergence risk.
#3 Observability Tooling Limitations
Many debugging or monitoring tools assume basic OS utilities exist.
If you rely on:
You may discover the container simply doesn’t support what you need.
#4 Operational Complexity Increases
Distroless pushes complexity outward.
Instead of “Let’s exec in and look.”
You now need:
If your observability is weak, distroless will expose it brutally.
#5 Compatibility Surprises
Some apps assume:
/bin/shexists for subprocessesDistroless images may omit or minimally include these.
You discover issues at runtime.
#6 Security Gains May Be Marginal
Distroless is often sold as “more secure.”
But:
bash.Security benefit is real — but sometimes overstated.
#7 Not Ideal for Dynamic Environments
If your application:
Distroless can break those assumptions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will be a requirement for production (a ton of customer have requested it because of the amount of CVEs that are eliminated), but your points are valid for rapid iteration/development. That said, for rapid iteration, you should also be able to run it locally/dev container that has obserability/tools. We also prefer to rely on high and strong logging discipline.