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.

[ivelin]

OAuth support for interactive MCP login would be helpful. Currently the official Vercel MCP server does not allow static bearer token, which prevents connecting KiloCode. Workaraounds are possible with community vercel mcp servers, but not ideal.
https://grok.com/share/bGVnYWN5LWNvcHk_916b26d7-7810-4b20-bbf4-e2d0f4b33168

[Mooncake911]

Feature Request: Support for MCP server configuration directory (one file per server)

Problem

Currently, Kilo Code requires all MCP servers to be configured in a single file (e.g., .kilocode/mcp.json or opencode.jsonc). This creates several issues:

• Users must manually merge configurations from different servers into one file
• There's no way to easily enable/disable a specific server without editing the shared file
• Debugging is difficult — errors in one server's config can affect the entire MCP setup
• The global MCP config is stored in VS Code Application Support, making it hard to version-control and share across projects

Proposed Solution

Add support for a configuration directory (e.g., ~/.kilocode/mcp_servers/ or .kilocode/mcp_servers/ per project) where each MCP server is defined in its own separate file (JSON, YAML, or TOML). Kilo Code would scan this directory at startup and load all valid server configurations automatically.

Benefits

• Modularity: Each server can be version-controlled and shared independently
• Easy toggling: Users can enable/disable servers by simply renaming or moving files (or with an enabled: false flag)
• Better error handling: Issues in one config file won't break the entire MCP setup; errors are logged per file
• Consistency: This approach already exists for other features like .kilocode/rules/, making it intuitive

Example Structure

~/.kilocode/mcp_servers/
├── github.json
├── postgres.json
└── figma.json

Example File Content (github.json):

{
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-github"],
  "env": {
    "GITHUB_TOKEN": "your-token-here"
  }
}

Acceptance Criteria

• Kilo Code scans a configurable directory for MCP server config files on startup
• Each file is validated and loaded independently
• Invalid files are logged with clear error messages but do not prevent other servers from loading
• Falls back to the existing single-file behavior if the directory doesn't exist
• The UI reflects all loaded servers correctly in the MCP panel

Additional Context

This addresses the pain points mentioned in issues #1745 (global config location) and #7868 (difficulty adding MCP servers), and would significantly improve the developer experience.

Related Discussions

• Change default global MCP settings location to home directory or add this as option #1745: "Change default global MCP settings location to home directory"
• MCP servers cannot be added in Kilo Code 7.1.9 #7868: MCP servers not being detected/added
• Issues with MCP #1360: Issues with MCP configuration