RFC-134: Forge Rovo Tools and MCP

General Request for Comments (RFC)
, ,
23

Thanks everyone for the feedback on this RFC. The discussion period has closed and we’re moving to resolve.

Key themes from feedback:

  1. Tool discovery and selection - How does Rovo pick between tools with similar descriptions? How does it handle overlap with native capabilities? No built-in priority today; clear descriptions win. This needs more thought as the ecosystem scales.

  2. Admin governance - Default state on install, what happens when new tools are added post-install, opt-in vs opt-out. Aligning with existing Connected Apps patterns but specifics need to be locked down.

  3. Description overloading - The description field serves both admin UI and LLM selection. These are different jobs and should likely be separated.

  4. Invocation attribution - Developers need a clear way to distinguish which surface invoked their tool (Rovo Chat, external MCP client, Automation) for adoption analytics.

  5. Crowded tool space - As more apps expose tools, we need better answers for grouping, namespacing, and contextual filtering beyond admin toggles.

  6. Async/long-running tools - Timeout contract for MCP-invoked actions needs to be specified, especially for heavy workloads like exports.

  7. Module limits - rovo:mcp is one module per manifest so it doesn’t blow the cap, but apps already near the limit should flag this.

What we’re doing next:

  • Proceeding with the rovo:mcp module design as proposed

  • Addressing the open questions above in implementation design docs

  • The companion rovo:skill RFC is live for feedback here: RFC-137: Forge Module for AI Skills

  • EAP targeting later next quarter