MCP support: Make Trove usable by AI coding agents

[Akshay1018]

Proposal: Add Model Context Protocol (MCP) Support to Trove

Overview

AI coding agents are becoming an important part of software development. I would like to explore making Trove available to these agents through the Model Context Protocol (MCP).

Instead of requiring developers to run Trove manually or requiring every AI agent to implement a custom integration, an MCP server could expose Trove's project-generation and validation capabilities through a standard interface.

The goal is to make Trove a reusable backend scaffolding tool within AI-assisted development workflows.

Proposed Use Case

A developer asks an MCP-compatible coding agent:

Create a Fastify backend with PostgreSQL, authentication, Docker, and integration tests using Trove.

The agent could discover Trove's capabilities, validate the requested configuration, prepare a project plan, request approval, generate the project, and run the available checks.

Proposed MCP Capabilities

Potential tools include:

trove_list_capabilities — discover supported frameworks, databases, and integrations.
trove_recommend_stack — recommend compatible stack options.
trove_plan_project — produce a structured project plan.
trove_validate_config — validate the requested configuration.
trove_create_project — generate a project using approved settings.
trove_validate_project — verify generated project structure and configuration.
trove_run_checks — execute supported validation commands with appropriate permissions.

Read-only resources could expose template metadata, configuration schemas, compatibility information, and usage documentation.

These names are proposals, not existing Trove tools.

Scope of the Initial Exploration

• Decide whether MCP should be an official part of Trove.
• Identify the capabilities that should be exposed to external agents.
• Define typed inputs and structured outputs.
• Determine how the MCP server will communicate with Trove's generation engine.
• Establish filesystem permissions and execution safeguards.
• Explore compatibility with different MCP clients.
• Keep the existing CLI usable independently of MCP.

Security and Reliability

The MCP server should not expose unrestricted shell execution or arbitrary filesystem access.

Project generation, dependency installation, file overwrites, and other sensitive operations should follow explicit permission rules. Tool calls should return clear results and errors so an external agent can make informed decisions.

Questions for the Community

1. Would you use Trove through an AI coding agent instead of running its CLI manually?
2. Which MCP clients and development environments should be supported first?
3. Which capabilities should be exposed as tools, and which should remain internal?
4. Should project generation require explicit confirmation by default?
5. Should the MCP server run locally alongside the CLI or eventually support a remote deployment?
6. What security and permission controls would you expect?
7. Would you prefer a minimal MCP server focused on scaffolding or a broader interface that also supports testing and debugging?

Suggested First Milestone

Implement a local MCP server that exposes capability discovery, configuration validation, project planning, and project generation through a small, well-defined set of tools.

The implementation should reuse Trove's trusted generation logic rather than duplicate its behavior.

This discussion is intended to gather feedback on the architecture and use cases before implementation work begins.

[bomtobe-hgkim]

BOMTOBE team here; we’re building Orke, a desktop workspace for Claude Code and Codex. For an MCP surface, I’d make project generation return a preview/diff first, then require an explicit approval token scoped to that one operation before writes or installs. Keep tools narrow (plan, validate, generate), expose allowed workspace roots and exact side effects in each tool description, and return structured errors plus changed paths. That gives clients a clear review boundary without granting shell access. I’d prioritize local stdio clients first, then test the same contract across clients.

[Akshay1018]

Thanks for the thoughtful feedback — really useful input from someone building in this space.
The preview/diff → scoped approval token flow makes a lot of sense. It gives the client a clear review boundary while still keeping generation deterministic and controlled. I’ll keep the initial MCP tool surface intentionally narrow (capability discovery, plan, validate, generate) and make sure every tool description is explicit about allowed roots and side effects. Starting with local stdio clients first also matches the direction I’m leaning toward for the first milestone.

Appreciate you taking the time to share this. Since you’re building Orke as a desktop workspace for Claude Code and Codex, I’d be curious if a clean MCP surface for backend scaffolding could be useful there at some point — or if there’s any natural overlap where it might make sense to collaborate. Happy to chat if it’s relevant on your side.

[bomtobe-hgkim]

Thanks for asking. From Orke’s public site, I can confirm it is a desktop workspace for Claude Code and Codex, but I can’t confirm an MCP integration or roadmap, and I haven’t tested Trove. Conceptually, a backend-scaffolding MCP surface could fit an agent workflow: preview the exact file diff and configuration, then bind approval to that specific plan and allowed project root before generation. That makes review and side effects clear. I’d be glad to revisit the overlap once there’s an implementation we can evaluate; I can’t promise a product integration or collaboration today.

[Akshay1018]

Thanks for the thoughtful response — that makes complete sense. I’ll focus on getting a solid first implementation of the MCP surface ready (with the preview/diff + scoped approval flow we discussed). Once there’s something concrete to try out, I’ll share it here in case it’s useful to revisit later.
Really appreciate you taking the time to engage on the design.