Deployment: Dockerfile and Smithery config

[calclavia]

This PR adds files for deploying your MCP server on Smithery. After deployment, users can use your server over streamable HTTP (hosted on Smithery) without needing to install any dependencies.

Changes

• Added Dockerfile to package your server for deployment.
• Added Smithery Configuration file to specify how to start your server. See documentation.
• Updated README to include popularity badge.

Server Details

• Smithery ID: @merill/lokka
• Server Homepage: https://smithery.ai/server/@merill/lokka

Action Items

• Build Passing: We verified that the Docker builds and your server starts up using an automated test.
• Code Review: Please review the changes to ensure the configuration is accurate for your server.
• Claim Server: Head to your server page to claim your server. This will let you edit your server listing on Smithery and deploy new versions of your server.

These files were automatically generated and tested by Smithery

[gemini-code-assist]

Hello @calclavia, 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!

Summary of Changes

Hello team, gemini-code-assist here to provide a summary of this pull request. This PR introduces the necessary files and configuration to enable deployment of the Lokka MCP server onto the Smithery platform. The primary goal is to allow users to access and interact with the server via streamable HTTP hosted on Smithery, eliminating the need for local dependency installations. The changes include adding a Dockerfile to containerize the application and a Smithery configuration file (smithery.yaml) to define how the server should be built and started within the Smithery environment, including specifying required authentication parameters. Additionally, the README has been updated to include a Smithery popularity badge.

Highlights

• Docker Containerization: Includes a Dockerfile to package the server and its dependencies into a container for consistent deployment.
• Smithery Configuration: Adds a smithery.yaml file defining the server's start command, required configuration parameters (like tenant ID, client ID, and client secret), and an example configuration for the Smithery platform.
• README Update: Adds a Smithery popularity badge to the README file.

Changelog

Click here to see the changelog

• Dockerfile
  • Added a new Dockerfile to define the build process for the server's container image.
  • Uses node:lts-alpine as the base image.
  • Copies package files and installs production dependencies.
  • Copies the built server code.
  • Ensures the main server script (build/main.js) is executable.
  • Sets the entrypoint to run the server using node build/main.js.
• README.md
  • Added a Smithery popularity badge link at the beginning of the file.
• smithery.yaml
  • Added a new Smithery configuration file.
  • Defines the startCommand type as stdio.
  • Provides a commandFunction to generate the start command (node build/main.js) and pass required authentication details (TENANT_ID, CLIENT_ID, CLIENT_SECRET) as environment variables based on the provided configuration.
  • Defines a configSchema using JSON Schema to specify the required configuration properties (tenantId, clientId, clientSecret).
  • Includes an exampleConfig with placeholder values.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

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 issue 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 is currently in preview and 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 to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

---

A Dockerfile appears,
To calm deployment fears.
With YAML config set,
On Smithery, you bet,
Your server now adheres.

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 effectively adds the necessary Dockerfile and Smithery configuration for deploying the MCP server. The changes are clear and align with the goal of enabling deployment on Smithery. The automated generation and testing by Smithery provide a good baseline for correctness. I have one suggestion regarding Docker security best practices.

Summary of Findings

• Dockerfile Security: Non-Root User: The Dockerfile currently runs the application as the root user. It's recommended to create and use a non-root user for improved security. A comment has been added with a specific suggestion to address this.
• Dockerfile: Executable Permissions (Informational): The RUN chmod +x build/main.js command (line 14) sets executable permissions on build/main.js. While not harmful, this permission isn't strictly necessary because the script is executed via node build/main.js in the ENTRYPOINT (line 17), and the node interpreter doesn't require the script file itself to have execute permissions. This is a minor point and was not commented on directly due to review settings (low severity).

Merge Readiness

The pull request is well-structured and the configurations seem appropriate for Smithery deployment. There is one medium-severity suggestion regarding Docker security (running as a non-root user) that I recommend addressing before merging. As an AI, I am not authorized to approve pull requests; please ensure further review and approval by authorized team members.

[gemini-code-assist]

For enhanced security, it's a best practice to run applications inside Docker containers as a non-root user. This can help mitigate potential vulnerabilities if the application process is compromised.

Could we consider creating a dedicated, unprivileged user for running the application? This typically involves:

1. Adding a new group and user.
2. Changing ownership of the application files to this new user.
3. Switching to this user with the USER instruction before the ENTRYPOINT or CMD.

What are your thoughts on incorporating this approach?

# Create a non-root user and group
RUN addgroup -S appgroup && adduser -S -G appgroup appuser

# Change ownership of the app directory to the new user
# This ensures the non-root user can read/execute necessary files.
RUN chown -R appuser:appgroup /app

# Switch to the non-root user
USER appuser