[Feature Request]: Client CLI

[gabe-l-hart]

🧭 Type of Feature

Please select the most appropriate category:

• Enhancement to existing functionality
• New feature or capability
• New MCP-compliant server
• New component or integration
• Developer tooling or test improvement
• Packaging, automation and deployment (ex: pypi, docker, quay.io, kubernetes, terraform)
• Other (please describe below)

🧭 Epic

Title: Client CLI for managing CF components
Goal: With CF running locally, developers would be able to perform all of the actions currently hosted by the UI/REST API via a CLI
Why now:

• This is part of the effort to make CF a daily-driver component in the agentic developer workflow. First-class CLI experiences are common-place with the most popular open-source AI developer tools (ollama, lmstudio, continue.dev, etc), so providing a client CLI would bring this familiar look-and-feel and help encourage developers to adopt CF for their daily work.
• Having a client CLI would also allow seamless transition between a local and hosted instance.

📐 Design Sketch (optional)

Include a diagram, sketch, or flow (use Mermaid if desired):

(TODO: working on a diagram with the CLI actions)

---

🔗 MCP Standards Check

• Change adheres to current MCP specifications
• No breaking changes to existing MCP-compliant integrations
• If deviations exist, please describe them below:

---

🔄 Alternatives Considered

List any alternative designs, existing workarounds, or rejected ideas.

---

📓 Additional Context

Include related issues, links to discussions, issues, etc.

[terylt]

Hi @gabe-l-hart

Just happened across your issue while I was looking for another one. I've started a bit of a CLI called cforge in this PR: #1207. Currently it supports the plugin lifecycle and deploying CF and its plugins as a configuration file, but could be expanded to support your ideas. I just wanted to note it here in case its of interest.. I agree coalescing around a nice CLI would be great for the project.

[gabe-l-hart]

Hi @terylt! Very cool that you've already started down this route. I probably should have looked deeper for other efforts in this area before launching the issue, but figured this would help aggregate thoughts. It looks like your CLI is aimed at the deployment portion of the lifecycle, right? I think this would compliment my idea nicely. My goal with this issue is around using a deployed CF (either running locally or remotely) from the command line to manage and test the various MCP assets which I think would pair well with deployment scripts. I could even imagine incorporating all of this under a single top-level CLI. Something like:

• mcpgateway serve: Exactly what mcpgateway does now
• mcpgateway deploy: Exactly what cforge does now
• mcpgateway tools: All the interacionts with tools
• mcpgateway resources: ...

[terylt]

Yes, exactly, I called it cforge just to detach it a bit from being only around the MCP part of the gateway, but the idea is to support several sub clis. But I'm not set on the name. Right now it has:

cforge gateway and cforge plugins but I do think it would be cool to have what you are talking about... Right now the only way to create new tools and stuff is to use curl, use the UI, or I guess adding directly to the database. So it would be great if we could have an aligned set of functionality you have above and just make it dirt simple to use. Happy to help however I can.

[gabe-l-hart]

Awesome, I'm going to start some prototyping work and will keep this issue updated

[gabe-l-hart]

Current CLI work is up on my branch: https://github.com/gabe-l-hart/mcp-context-forge/tree/ClientCLI

Sample Screenshots so far:

[gabe-l-hart]

(NOTE: I plan to figure out how to get the security warnings to not show up when running in client mode)

[araujof]

Hi @gabe-l-hart , to disable the warnings, try this from your entrypoint module:

import logging
logging.getLogger("mcpgateway.config").setLevel(logging.ERROR)​
logging.getLogger("mcpgateway.observability").setLevel(logging.ERROR)​

@terylt we could add an option for this... I don't think there warnings are needed in the CLI. Only the gateway.

[gabe-l-hart]

Interesting, that could definitely work! I've been looking around at how config.Settings is used (related: #1421) and was thinking it would make sense to introduce a new client_mode field that could be used in the various validators. Your solution would certainly be cleaner, but would really just be hiding the warnings rather than skipping the checks which might make for a more responsive CLI as well. The real issue is the module-level instance of Settings that gets created here. This gets created on import, so if any module in the import tree imports config, the default-constructed Settings get made and the warnings get sent.