-
Notifications
You must be signed in to change notification settings - Fork 98
MCP Server addition and modification of SimpleChat API to accomodate … #722
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: Development
Are you sure you want to change the base?
Changes from all commits
e913f2f
e90427f
77e1b32
dc65180
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| .env | ||
| logs/ | ||
| __pycache__/ | ||
| *.pyc | ||
| *.pyo | ||
| *.pyd | ||
| .venv/ | ||
| venv/ | ||
| .env.* |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| # Dockerfile | ||
| FROM python:3.11-slim | ||
|
|
||
| WORKDIR /app | ||
|
|
||
| COPY requirements.txt ./ | ||
| RUN pip install --no-cache-dir -r requirements.txt | ||
|
|
||
| COPY . . | ||
|
|
||
| ENV PYTHONUNBUFFERED=1 | ||
| ENV FASTMCP_HOST=0.0.0.0 | ||
| ENV FASTMCP_PORT=8000 | ||
|
|
||
| EXPOSE 8000 | ||
|
|
||
| CMD ["python", "server_minimal.py"] |
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,117 @@ | ||||||||
| # SimpleChat MCP Server (FastMCP) | ||||||||
|
|
||||||||
| This MCP server provides **10 active tools** for interacting with SimpleChat via the Model Context Protocol (Streamable HTTP transport). | ||||||||
|
|
||||||||
|
||||||||
| 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`. |
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.