MCP Feature Requests | Consolidated Discussion

[bturcotte520]

Hi Everyone!

Please leave your feature requests regarding MCP configuration/capabilities here, to increase visibility and reduce redundancy.

Thanks for being a part of the Kilo Code Community!

[bturcotte520]

@sebsebseb1982 asked:

Could it be possible that Kilocode support MCP prompts so as to offer /commands in ask mode ?
I've implemented a prompt on my MCP server, I can see it with MCP inspector but it does not appear in Kilocode.

[bturcotte520]

From @joaoeudes7:

Description:
Currently, the MCP integration only supports running commands through npx or Node-based executors. However, many modern JavaScript environments (especially Bun-based projects) use [bunx](https://bun.sh/docs/cli/bunx) as a faster and more lightweight alternative to npx.

Adding first-class support for bunx would allow developers who rely on Bun to seamlessly run MCP-compatible commands (e.g., cursor-talk-to-figma-mcp@latest) without requiring Node or npm.

---

Proposed Behavior

• Detect when Bun is available in the environment (bun or bunx in PATH).

• Prefer bunx over npx when executing MCP commands, or allow explicit configuration via:

  "command": "bunx",
  "args": ["cursor-talk-to-figma-mcp@latest"]

• Fallback gracefully to npx if Bun is not installed.

---

Benefits

• Improves performance (Bun installs and runs faster than npm).
• Enables modern toolchains and environments to use MCP without Node overhead.
• Provides better cross-runtime compatibility between Bun and Node projects.

---

Acceptance Criteria

• ✅ MCP extensions can run successfully using bunx.
• ✅ Automatic detection or configurable option to choose between npx and bunx.
• ✅ Proper error handling if bunx is missing on system.

---

Example

"talkToFigma": {
  "command": "bunx",
  "args": ["*****-mcp@latest"]
}

[bturcotte520]

@MMOStars said:

Please make it so if MCP call is expanded manually it is always kept expanded, it's super annoying to keep constantly manually expanding this boxes to see what's the toolcall is being made.

[bturcotte520]

From @prmichaelsen :

For MCP servers that are docker containers its easy to view logs in the container, but for MCP servers that are just node scripts for instance, the only way to view logs for MCP failures is via the VS Code developer tools. It would be nice if we could expose these logs somehow to the end user.

[bturcotte520]

From @prmichaelsen:

Problem Statement

When configuring MCP servers in Kilo Code, there's currently no way to provide metadata or guidance on how specific tools should be used by the AI. This limits the ability to customize tool behavior and provide usage preferences without modifying the MCP server implementation itself.

Use Case

As a developer who creates and configures MCP servers, I want to provide metadata and usage guidance for specific tools so that:

1. The AI can make more informed decisions about how to use each tool effectively
2. I can set default parameters and preferences without modifying server code
3. I can provide usage hints and best practices directly in the configuration
4. Tool behavior can be customized for different environments without code changes

For example, when using the Jira and Confluence tools, I might want to:

• Specify default fields to return for Jira searches
• Set preferred formatting options for Confluence content
• Provide usage hints about when to use certain parameters
• Configure environment-specific limits or thresholds

Benefits

Implementing this feature would:

• Improve AI tool usage: The AI would have more context about how tools should be used
• Reduce configuration friction: Less need to modify server code for customization
• Enable environment-specific behavior: Same server code could behave differently based on configuration
• Provide better guidance: Help the AI make better decisions about parameter values
• Standardize best practices: Encode recommended usage patterns directly in configuration
• Reduce repetitive prompting: Users won't need to repeatedly instruct the AI on how to use tools
• Ensure consistent behavior: Tools will be used consistently across different sessions
• Reduce dependency on local configs: Less reliance on other mechanisms like Kilo Code memory
• Enable team collaboration: Tool metadata configurations can be shared across teams

Potential Implementation Approaches

While I'm focused on the use case rather than implementation details, here are some approaches that could work:

1. Extended Configuration Schema: Add a toolMetadata section to the MCP server configuration that allows specifying metadata for each tool.

2. Tool Response Enhancement: Extend the MCP protocol to allow servers to include metadata in their tool descriptions when tools are discovered.

3. Environment Variable Convention: Establish a convention for environment variables that influence tool behavior (e.g., TOOL_NAME_DEFAULT_PARAM).

Example Usage

Here's how this feature might be used in practice:

{
  "mcpServers": {
    "jira-server": {
      "command": "...",
      "args": ["..."],
      "env": { "..." },
      "toolMetadata": {
        "jira_search": {
          "defaultParameters": {
            "fields": "summary,status,assignee,priority",
            "limit": 15
          },
          "usageGuidance": "Always include a project filter when possible to improve performance",
          "examples": [
            {
              "description": "Search for high priority bugs",
              "jql": "project = PROJ AND issuetype = Bug AND priority = High"
            }
          ]
        },
        "confluence_get_page": {
          "defaultParameters": {
            "convert_to_markdown": true,
            "include_metadata": true
          },
          "usageGuidance": "Prefer using page_id over title/space_key when possible"
        }
      }
    }
  }
}

Conclusion

Adding support for tool-specific metadata in MCP server configurations would significantly enhance the flexibility and usability of MCP tools. It would allow for better guidance to the AI without requiring code changes to the MCP server implementation, resulting in more effective and customized tool usage.

[edujuan]

TL;DR; UTCP adds support to do tool calling to any API without any additional servers or setup. Should this be added to Kilo?

UTCP is a tool calling protocol that enables AI agents to call external APIs without any middleman servers, and which supports a variety of transport layers, from CLI tools to REST to sockets to GraphQL.

• Specification: https://www.utcp.io/docs
• Github: https://github.com/universal-tool-calling-protocol

The tool calls are done identically to how MCP calls tools, give the tool name and the arguments, and receive a response.
Examples: https://github.com/universal-tool-calling-protocol/utcp-examples

Idea

Support Kilo Agent to also call tools using UTCP in addition to MCP.

Benefits

•⁠ ⁠Any API is supported, even if it doesn't have an MCP server
•⁠ ⁠APIs with built-in security maintain those security guarantees, and there's no need to trust third-party servers with any data
•⁠ ⁠Could support a large number of tools using tool searching functionalities
•⁠ ⁠Very low effort to add support for a new tool (copy paste the location on your PC or URL to a json manual)

Challenges

•⁠ ⁠There is a bit of implementation needed to add the UTCP Client
•⁠ ⁠UTCP is still quite young

Mitigations

•⁠ ⁠The UTCP maintainer team has volunteered to make the PR themselves if the Kilo community wants it
•⁠ ⁠Feedback to UTCP is to be taken into consideration and implemented very fast, as it's not that large

MVP

Make UTCP return its calls alongside MCP in a way that it looks like it's just another MCP server. This requires very little implementation. It doesn't leverage the tool search capabilities of UTCP, but it still is good as a starting point.