[Feature] Support for project-level MCP configuration files (.mcp.json)

[Avtrkrb]

[Feature] Support for project-level MCP configuration files (.mcp.json)

Description

This PR implements hierarchical configuration loading for MCP (Model Context Protocol) servers, enabling team collaboration through project-level configuration files. The implementation adds support for Claude Code's object-based MCP server format while maintaining full backward compatibility with existing configurations. Additionally, this PR adds CLI options for version and help information.

Key Features Added:

1. Project-Level Configuration Support:

   • Added support for .mcp.json, mcp.json, .nanocoder/mcp.json, .claude/mcp.json, and .nanocoder/mcp.local.json files
   • Project-level configs take precedence over global configs
   • Enables team collaboration by allowing MCP server configs to be committed to version control

2. Claude Code Format Compatibility:

   • Added support for Claude Code's object-based format: { "serverName": { ...serverConfig } }
   • Maintains full compatibility with traditional array format: [ {...serverConfig} ]
   • Both formats work in all supported configuration locations

3. Hierarchical Configuration Loading:

   • Configuration files are loaded with proper precedence (project overrides global)
   • Security validation for sensitive data in project-level configs
   • Environment variable substitution works across all configuration levels

4. Enhanced MCP Command Display:

   • /mcp command now shows configuration source levels (e.g., [project], [global])
   • Users can see where each MCP server configuration originates

5. Security Enhancements:

   • Validation to detect hardcoded credentials in project-level config files
   • Automatic .gitignore generation for sensitive config files
   • Warnings for security-sensitive configurations

6. CLI Version and Help Options:

   • Added --version/-v flag to display version information
   • Added --help/-h flag to show usage information and available options
   • Added comprehensive documentation for CLI options in README.md
   • Added integration tests for CLI version/help functionality

7. New Quit Command and UI Improvements:

   • Added /quit command as an alternative to /exit for exiting the application
   • Updated /help command display to show "Help" instead of "/help" as the title
   • Updated /mcp command display to show "Model Context Protocol Servers" instead of "/mcp" as the title
   • Enhanced /mcp command UI with improved color scheme using theme's tool color
   • Added graceful exit handling with goodbye message for the quit command

Type of Change

• New feature
• Bug fix (global providers not loaded when project config exists without providers)
• Breaking change (no breaking changes - fully backward compatible)
• Documentation update

Testing

Automated Tests

• New features include passing tests in .spec.ts files
• All existing tests pass (pnpm test:all completes successfully)
• Tests cover both success and error scenarios
• Added comprehensive tests for hierarchical configuration loading
• Added tests for Claude Code format compatibility
• Added integration tests for CLI version/help functionality

Manual Testing

• Tested with project-level .mcp.json files
• Tested with Claude Code object format
• Tested hierarchical loading precedence
• Tested backward compatibility with existing configs
• Verified global providers remain available when project config lacks providers
• Tested CLI --version and --help flags work correctly
• Verified version and help commands exit with proper codes
• Tested new /quit command works as expected
• Verified /help command title display is updated correctly
• Confirmed /mcp command UI improvements are visible

Files Changed

• source/config/mcp-config-loader.ts - New hierarchical configuration loading system
• source/config/mcp-config-loader.spec.ts - Comprehensive tests for new functionality
• source/config/validation.ts - Security validation for project configs
• source/config/validation.spec.ts - Tests for security validation
• source/config/index.ts - Updated to use hierarchical loading
• source/commands/mcp.tsx - Enhanced to show configuration source levels
• source/hooks/useAppInitialization.tsx - Updated MCP initialization
• source/client-factory.ts - Updated provider loading
• source/cli.tsx - Added CLI version and help functionality
• source/cli.spec.ts - Added tests for CLI version/help flags
• source/cli-integration.spec.ts - Added integration tests for CLI functionality
• source/commands/exit.ts - Added quit command functionality
• source/commands/help.tsx - Updated help command display title
• source/commands/mcp.tsx - Enhanced MCP command UI with improved color scheme
• source/hooks/useAppInitialization.tsx - Registered the new quit command
• README.md - Updated documentation with new configuration options and CLI usage
• docs/mcp-configuration.md - Detailed documentation for new features

Checklist

• Code follows project style guidelines
• Self-review completed
• Documentation updated
• No breaking changes (fully backward compatible)
• Appropriate security validation added
• Proper environment variable handling for project configs
• Configuration merging with proper precedence
• Support for both Claude Code and traditional formats
• Team collaboration features enabled
• Security protections for sensitive data
• CLI version and help options implemented
• Integration tests for CLI functionality added
• Documentation for CLI options updated
• New quit command implemented and registered
• Help command UI improvements applied
• MCP command UI enhancements with improved color scheme

Backwards Compatibility

This implementation maintains full backward compatibility:

• Existing agents.config.json files continue to work unchanged
• All existing MCP server configurations remain functional
• No breaking changes to existing API or configuration format
• Project-level configs are optional additions that enhance functionality
• CLI version/help flags are additive features that don't affect existing functionality
• New /quit command is an optional addition alongside existing /exit command
• UI improvements to /help and /mcp commands are visual enhancements only

Security Considerations

• Added validation to detect hardcoded credentials in project-level configs
• Environment variable references (e.g., $API_KEY) are recommended over hardcoded values
• Sensitive configuration files are automatically added to .gitignore suggestions
• Security warnings are provided when sensitive data is detected in project configs
• CLI help output doesn't expose sensitive configuration details
• Version information is safely exposed without compromising security
• New quit command doesn't introduce security risks
• UI enhancements don't affect security posture

[Avtrkrb]

@will-lamerton Please review, approve & merge this PR when you get the time. Minor enhancements & improvements in this one

Closes #266 & #268

[will-lamerton]

Hey @Avtrkrb, thanks for putting this together! I like the direction of adding .mcp.json support for Claude Code compatibility - that's definitely something we should have.

I've been thinking about the overall config setup though, and I'm wondering if we're overcomplicating things a bit. Let me share my thinking:

The current situation:

• agents.config.json already supports project-level config (it checks cwd first)
• It handles providers, MCP servers, and LSP servers all in one place

What this PR adds:

• 6 different places to look for MCP config (.mcp.json, mcp.json, .nanocoder/mcp.json, .claude/mcp.json, .nanocoder/mcp.local.json, plus the existing agents.config.json)
• Two formats (array and object)
• Complex precedence rules between all these locations

I'm a bit worried this creates confusion for users - "where do I put my MCP config?" becomes a complicated question.

I'm wondering if we need to simplify this instead?

• .mcp.json - The ONE place for MCP config, using Claude Code's object format. This is cross-tool compatible (Claude Code, Nanocoder, and whatever else adopts the MCP standard).
• agents.config.json - Keeps providers and LSP config (nanocoder-specific stuff). We'd deprecate the mcpServers key here over time.

That would be it. Two files, clear separation, no precedence confusion.

The object format from Claude Code would be the only supported format in .mcp.json:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
    }
  }
}

This gives us cross-tool compatibility (which I really want) without the complexity of checking 6 different locations with merge logic.

If MCP servers are found in agents.config.json, we show a deprecation warning pointing users to move their config to .mcp.json. Something like:

"MCP servers in agents.config.json is deprecated. Please move your MCP configuration to .mcp.json for cross-tool compatibility."

This keeps things backward compatible while nudging users toward the simpler setup.

For the local overrides use case, users can just gitignore their .mcp.json or use environment variables for secrets - we don't necessarily need a separate .mcp.local.json.

What do you think? Happy to chat more about this if you want to discuss the tradeoffs. The core work you've done here on format parsing and the new loader is solid - I'm mainly suggesting we scope down the number of supported locations and how we handle the existing use of agents.config.json.

[Avtrkrb]

What do you think? Happy to chat more about this if you want to discuss the tradeoffs. The core work you've done here on format parsing and the new loader is solid - I'm mainly suggesting we scope down the number of supported locations and how we handle the existing use of agents.config.json.

Hey @will-lamerton I agree with you. I'll be honest, this was something that was on my mind since the very start of my journey with Nanocoder & would be up for an overhaul of configuration files if you agree to what I'm proposing.

Here's my thoughts:

I'm wondering if we need to simplify this instead?

* `.mcp.json` - The ONE place for MCP config, using Claude Code's object format. This is cross-tool compatible (Claude Code, Nanocoder, and whatever else adopts the MCP standard).

* `agents.config.json` - Keeps providers and LSP config (nanocoder-specific stuff). We'd deprecate the `mcpServers` key here over time.

That would be it. Two files, clear separation, no precedence confusion.

• agents.config.json We keep this purely for provider configuration, LSP configuration & the proposed model & agent specific customization from [Feature] Enable mode-specific model and provider configuration for optimized performance #277. We keep the existing project level local & the user level global scopes.
• We can migrate the mcp server configuration to a new location: .nanocoder/mcp.json for project level & NANOCODER_CONFIG_DIR/mcp.json for the user level scope. No overrides of any sort, any & all mcp servers found at both levels are loaded.
• We reduce the scope of the number of supported locations to just:

1. NANOCODER_CONFIG_DIR/mcp.json
2. .nanocoder/mcp.json
3. PROJECT_ROOT_DIR/.mcp.json
4. PROJECT_ROOT_DIR/mcp.json.

• NANOCODER_CONFIG_DIR/mcp.json & .nanocoder/mcp.json will support just our native array structure while the .mcp.json/mcp.json located at project root will support either our native array structure or Claude Code's object structure at a time, but not both structures simultaneously.
• I suggest support for both .mcp.json & mcp.json at the project root level since it's an easy typo.

This is just a starting proposal, free to iterate on this further !

[will-lamerton]

What do you think? Happy to chat more about this if you want to discuss the tradeoffs. The core work you've done here on format parsing and the new loader is solid - I'm mainly suggesting we scope down the number of supported locations and how we handle the existing use of agents.config.json.

Hey @will-lamerton I agree with you. I'll be honest, this was something that was on my mind since the very start of my journey with Nanocoder & would be up for an overhaul of configuration files if you agree to what I'm proposing.

Here's my thoughts:

I'm wondering if we need to simplify this instead?

* `.mcp.json` - The ONE place for MCP config, using Claude Code's object format. This is cross-tool compatible (Claude Code, Nanocoder, and whatever else adopts the MCP standard).

* `agents.config.json` - Keeps providers and LSP config (nanocoder-specific stuff). We'd deprecate the `mcpServers` key here over time.

That would be it. Two files, clear separation, no precedence confusion.

• agents.config.json We keep this purely for provider configuration, LSP configuration & the proposed model & agent specific customization from [Feature] Enable mode-specific model and provider configuration for optimized performance #277. We keep the existing project level local & the user level global scopes.

• We can migrate the mcp server configuration to a new location: .nanocoder/mcp.json for project level & NANOCODER_CONFIG_DIR/mcp.json for the user level scope. No overrides of any sort, any & all mcp servers found at both levels are loaded.

• We reduce the scope of the number of supported locations to just:

1. NANOCODER_CONFIG_DIR/mcp.json

2. .nanocoder/mcp.json

3. PROJECT_ROOT_DIR/.mcp.json

4. PROJECT_ROOT_DIR/mcp.json.

• NANOCODER_CONFIG_DIR/mcp.json & .nanocoder/mcp.json will support just our native array structure while the .mcp.json/mcp.json located at project root will support either our native array structure or Claude Code's object structure at a time, but not both structures simultaneously.

• I suggest support for both .mcp.json & mcp.json at the project root level since it's an easy typo.

This is just a starting proposal, free to iterate on this further !

@Avtrkrb - awesome, glad we’re on the same page about simplifying!

I personally think we can go even simpler:

Just 2 locations, same filename:

• mcp.json in project root (project-level)
• ~/.config/nanocoder/.mcp.json (user-level global)

Just 1 format:

• Object format (Claude Code standard)

My reasoning:

1. Why not .nanocoder/mcp.json? - If someone’s using Claude Code too, they’d need to duplicate their config. The whole point of .mcp.json is cross-tool compatibility, so let’s lean into that fully.

2. Why not mcp.json (without the dot)? - Claude Code uses .mcp.json, so that’s the emerging standard. Supporting both just means users have to remember “wait, which one do I use?” Let’s pick one and stick with it.

3. Why object format only? - Again, cross-tool compatibility. Claude Code uses object format, and having different format rules for different locations (“array here, object there”) is the kind of thing that leads to confusing docs and bug reports. One format, everywhere.

4. Why not array format at all? - The object format is actually nicer anyway - server names as keys means no duplicate name bugs, and it’s more readable. We can convert existing array configs on load and show the deprecation warning.

So the mental model becomes super simple:

• MCP config? - .mcp.json
• Same filename globally and per-project
• Works with Claude Code? - Yes
• Works with Nanocoder? → Yes

The global fallback at ~/.config/nanocoder/.mcp.json is there for users who want default MCP servers across all projects, but project-level .mcp.json wins when present.

What do you think? I know it’s more opinionated, but I think simpler is better here - fewer decisions for users to make.

Everything else you stated in regards to agents.config.json I agree with as this is Nanocoder specific stuff.

[Avtrkrb]

I personally think we can go even simpler:

Just 2 locations, same filename:

* mcp.json in project root (project-level)

* ~/.config/nanocoder/.mcp.json (user-level global)

Just 1 format:

* Object format (Claude Code standard)

My reasoning:

1. Why not .nanocoder/mcp.json? - If someone’s using Claude Code too, they’d need to duplicate their config. The whole point of .mcp.json is cross-tool compatibility, so let’s lean into that fully.

2. Why not mcp.json (without the dot)? - Claude Code uses .mcp.json, so that’s the emerging standard. Supporting both just means users have to remember “wait, which one do I use?” Let’s pick one and stick with it.

3. Why object format only? - Again, cross-tool compatibility. Claude Code uses object format, and having different format rules for different locations (“array here, object there”) is the kind of thing that leads to confusing docs and bug reports. One format, everywhere.

4. Why not array format at all? - The object format is actually nicer anyway - server names as keys means no duplicate name bugs, and it’s more readable. We can convert existing array configs on load and show the deprecation warning.

So the mental model becomes super simple:

* MCP config? - .mcp.json

* Same filename globally and per-project

* Works with Claude Code? - Yes

* Works with Nanocoder? → Yes

The global fallback at ~/.config/nanocoder/.mcp.json is there for users who want default MCP servers across all projects, but project-level .mcp.json wins when present.

What do you think? I know it’s more opinionated, but I think simpler is better here - fewer decisions for users to make.

Sounds like a plan ! Ideally I'd like to keep all mcp servers from both the NANOCODER_CONFIG_DIR/mcp.json & project level mcp.json loaded. I personally go with this setup, a set of mcp servers globally available & a few selective mcp servers for specific projects. If you agree to this, then I can start working on the required changes.

[will-lamerton]

I personally think we can go even simpler:

Just 2 locations, same filename:

* mcp.json in project root (project-level)

* ~/.config/nanocoder/.mcp.json (user-level global)

Just 1 format:

* Object format (Claude Code standard)

My reasoning:

1. Why not .nanocoder/mcp.json? - If someone’s using Claude Code too, they’d need to duplicate their config. The whole point of .mcp.json is cross-tool compatibility, so let’s lean into that fully.

2. Why not mcp.json (without the dot)? - Claude Code uses .mcp.json, so that’s the emerging standard. Supporting both just means users have to remember “wait, which one do I use?” Let’s pick one and stick with it.

3. Why object format only? - Again, cross-tool compatibility. Claude Code uses object format, and having different format rules for different locations (“array here, object there”) is the kind of thing that leads to confusing docs and bug reports. One format, everywhere.

4. Why not array format at all? - The object format is actually nicer anyway - server names as keys means no duplicate name bugs, and it’s more readable. We can convert existing array configs on load and show the deprecation warning.

So the mental model becomes super simple:

* MCP config? - .mcp.json

* Same filename globally and per-project

* Works with Claude Code? - Yes

* Works with Nanocoder? → Yes

The global fallback at ~/.config/nanocoder/.mcp.json is there for users who want default MCP servers across all projects, but project-level .mcp.json wins when present.

What do you think? I know it’s more opinionated, but I think simpler is better here - fewer decisions for users to make.

Sounds like a plan ! Ideally I'd like to keep all mcp servers from both the NANOCODER_CONFIG_DIR/mcp.json & project level mcp.json loaded. If you agree to this, then I can start working on the required changes.

Let's do it :)

[Avtrkrb]

Updates to /setup-config Wizard for Dual-File Configuration

Following the architectural decision to split configuration into two separate files, I've updated the /setup-config wizard (configuration wizard) to properly handle the dual-file approach:

Changes Made

1. source/wizard/validation.ts

• Split buildConfigObject() into two separate functions:
  • buildProviderConfigObject() - for agents.config.json (providers only)
  • buildMcpConfigObject() - for .mcp.json (MCP servers only)
• Kept deprecated buildConfigObject() for backward compatibility

2. source/wizard/config-wizard.tsx

• Changed from single configPath state to dual paths:
  • providerConfigPath - path to agents.config.json
  • mcpConfigPath - path to .mcp.json
• Updated handleLocationComplete() to set both paths based on location
• Added migration logic for old configs:
  • Converts old array format to object format
  • Handles MCP servers still in agents.config.json
  • Shows deprecation warnings when old format is detected
• Updated handleSave() to save to both files separately
• Updated openInEditor() to save and reload both files

3. source/wizard/steps/summary-step.tsx

• Changed props from configPath to providerConfigPath and mcpConfigPath
• Updated display to show "Configuration files:" with both file paths

4. source/wizard/steps/location-step.tsx

• Updated onComplete signature to only pass location (removed path parameter)
• Both files are now saved to the same location (project or global)

5. source/wizard/steps/summary-step.spec.tsx

• Updated all 31 tests to use new props
• Fixed transport type issues with as const assertions
• Updated regex assertions for "Configuration files:" and both file paths

Test Results

• ✅ All 4242 tests pass
• ✅ No lint fixes needed
• ✅ No security issues found

Manual Testing

The wizard has been manually tested and works correctly:

• ✅ Creates agents.config.json with providers configuration
• ✅ Creates .mcp.json with MCP servers configuration
• ✅ Both files are created in the same location (project or global)
• ✅ Migration from old configs works correctly
• ✅ Editor functionality saves and reloads both files

[Avtrkrb]

✘ Timed out while running tests Failed to exit when running source/services/bash-executor.spec.ts

I think we might need to provide support for additional shell like zsh, fish, powershell etc. I remember this was failing sometime last week & I had fixed it as well. Not sure how it has resurfaced

[will-lamerton]

✘ Timed out while running tests Failed to exit when running source/services/bash-executor.spec.ts

I think we might need to provide support for additional shell like zsh, fish, powershell etc. I remember this was failing sometime last week & I had fixed it as well. Not sure how it has resurfaced

Fixed :)

[Avtrkrb]

Fixed :)

That's awesome ! Please review it & let me know if anything needs to change

[will-lamerton]

Hey @Avtrkrb - looking great :)

A few things I spotted:

1. Platform-specific path in deprecation warning

The deprecation warning hardcodes the Linux path:

logError('Please migrate to ~/.config/nanocoder/.mcp.json');

But the actual config path varies by platform:

Linux: ~/.config/nanocoder/.mcp.json
macOS: ~/Library/Preferences/nanocoder/.mcp.json
Windows: %APPDATA%\nanocoder.mcp.json

Windows and macOS users would see a path that doesn't exist on their system. Should be an easy fix (I think):

import {getConfigPath} from '@/config/paths';
import {join} from 'path';

function showAgentsConfigDeprecationWarning() {
    const configPath = join(getConfigPath(), '.mcp.json');
    logError('Warning: MCP servers in agents.config.json are deprecated.');
    logError(`Please migrate to ${configPath}`);
}

Same thing for the array format warning if it mentions a path anywhere.

2. Separate /setup-mcp command?
   Now that MCP config lives in its own file, should we have a dedicated /setup-mcp command? This would let users manage providers and MCP servers separately, which feels cleaner than bundling everything in /setup-config. Just a thought and curious to hear your thoughts as I might be wrong.

3. Bug: Can't remove all MCP servers
   I noticed if I add one MCP server globally, then try to remove it and save, I can't get back to having 0 MCPs. The wizard seems to require at least one entry. Users should be able to have an empty MCP config if they want.

4. Missing test coverage
   A few test cases that would be good to add (unless I have missed them):

• Verify the deprecation warning is actually shown when loading from agents.config.json
• Verify the deprecation warning is shown for array format
• Test the platform-specific path in the warning message (once fixed)
• Test that empty .mcp.json files are handled gracefully

Let me know thoughts :D

[Avtrkrb]

Hey @will-lamerton I've pushed a fix for the hardcoded Linux config path, forgot about it while I was investigating the CI issue.

2. Separate /setup-mcp command?
   Now that MCP config lives in its own file, should we have a dedicated /setup-mcp command? This would let users manage providers and MCP servers separately, which feels cleaner than bundling everything in /setup-config. Just a thought and curious to hear your thoughts as I might be wrong.

This sounds logical. I'll take a look into this. I was also thinking having a feature where users can add mcp servers while in non interactive mode, something like nanocoder mcp add ... similar to how claude code supports. But we could address this in a future PR.

3. Bug: Can't remove all MCP servers
   I noticed if I add one MCP server globally, then try to remove it and save, I can't get back to having 0 MCPs. The wizard seems to require at least one entry. Users should be able to have an empty MCP config if they want.

I think you are testing an edge case here & the wizard might not currently support this. Will look into it.

4. Missing test coverage
   A few test cases that would be good to add (unless I have missed them):


* Verify the deprecation warning is actually shown when loading from agents.config.json

* Verify the deprecation warning is shown for array format

* Test the platform-specific path in the warning message (once fixed)

* Test that empty .mcp.json files are handled gracefully

These are good coverage, will add them in. I did manually test an empty .mcp.json from the project directory & it worked, will add this to the ava tests as well.

[will-lamerton]

This sounds logical. I'll take a look into this. I was also thinking having a feature where users can add mcp servers while in non interactive mode, something like nanocoder mcp add ... similar to how claude code supports. But we could address this in a future PR.

Sounds good :) if you like the idea of a /setup-mcp wizard then I think we should add this for this PR? I agree the non-interactive mode addition can be in a future one though!

Awesome on the rest of it! Will keep tabs on this :D

[Avtrkrb]

Sounds good :) if you like the idea of a /setup-mcp wizard then I think we should add this for this PR? I agree the non-interactive mode addition can be in a future one though!

Awesome on the rest of it! Will keep tabs on this :D

Yes I'll be adding the /setup-mcp as part of this PR.

[Avtrkrb]

@will-lamerton I've made the necessary changes & added the new /setup-mcp command. I've been thinking, since /setup-config now only handles providers, would it be wise to rename it to /setup-providers ? Let me know your thoughts...

[Avtrkrb]

Today's Changes Summary

1. Removed MCP Functionality from /setup-config Command

File: source/wizard/config-wizard.tsx

• Removed all MCP-related imports (McpStep, buildMcpConfigObject, etc.)
• Updated WizardStep type to remove 'mcp' and 'editing' steps
• Removed mcpConfigPath and mcpServers state
• Converted to inline summary rendering for provider configuration only
• Added new SummaryStepActions component

2. Fixed /setup-mcp Auto-completion

File: source/hooks/useAppInitialization.tsx

• Added setupMcpCommand import
• Registered with commandRegistry.register() so typing "/setup" now lists both commands

3. Fixed Global Config Path Display in MCP Wizard

Files: source/wizard/mcp-wizard.tsx, source/wizard/steps/location-step.tsx

• Added configFileName prop to LocationStep component
• MCP wizard now passes ".mcp.json" instead of default "agents.config.json"
• Global config path now correctly shows NANOCODER_CONFIG_DIR/.mcp.json

4. Fixed Arrow Key Navigation Bug

File: source/app/App.tsx

• Added isMcpWizardMode to ChatInput exclusion condition
• Arrow keys in MCP wizard no longer activate main input area

5. Fixed Template String Bug in Deprecation Warning

File: source/config/mcp-config-loader.ts (line 33)

• Changed from regular string to template literal
• Before: logError('Please migrate to ${_configPath}');
• After: logError(\Please migrate to ${_configPath}`);`

6. Added 7 New Test Cases

File: source/config/mcp-config-loader.spec.ts

All new tests pass (14 total tests in file):

• ✅ Array format deprecation warning
• ✅ No deprecation warning for Claude Code object format
• ✅ agents.config.json deprecation warning
• ✅ Platform-specific path interpolation (verifies actual path shown, not literal)
• ✅ Empty .mcp.json file handling
• ✅ Empty mcpServers array handling
• ✅ Empty mcpServers object handling

Test Results

✔ 14 tests passed in mcp-config-loader.spec.ts
✔ 4251 total tests passed

Files Modified

• source/wizard/config-wizard.tsx - Removed MCP functionality
• source/wizard/mcp-wizard.tsx - Added configFileName prop
• source/wizard/steps/location-step.tsx - Added configFileName prop
• source/hooks/useAppInitialization.tsx - Registered setupMcpCommand
• source/app/App.tsx - Fixed ChatInput exclusion
• source/config/mcp-config-loader.ts - Fixed template string bug
• source/config/mcp-config-loader.spec.ts - Added 7 test cases

New Files (No Tests - Following Existing Pattern)

• source/wizard/mcp-wizard.tsx - MCP wizard component
• source/commands/setup-mcp.tsx - Command registration

[will-lamerton]

@will-lamerton I've made the necessary changes & added the new /setup-mcp command. I've been thinking, since /setup-config now only handles providers, would it be wise to rename it to /setup-providers ? Let me know your thoughts...

I think this is a good idea... makes sense and is clearer for the user :)

[will-lamerton]

@will-lamerton I've made the necessary changes & added the new /setup-mcp command. I've been thinking, since /setup-config now only handles providers, would it be wise to rename it to /setup-providers ? Let me know your thoughts...

Let me know and I can work on this if you need 😎

[Avtrkrb]

@will-lamerton I've made the necessary changes & added the new /setup-mcp command. I've been thinking, since /setup-config now only handles providers, would it be wise to rename it to /setup-providers ? Let me know your thoughts...

Let me know and I can work on this if you need 😎

Works ! I think apart from this change there is nothing else to be done in this PR

[will-lamerton]

@will-lamerton I've made the necessary changes & added the new /setup-mcp command. I've been thinking, since /setup-config now only handles providers, would it be wise to rename it to /setup-providers ? Let me know your thoughts...

Let me know and I can work on this if you need 😎

Works ! I think apart from this change there is nothing else to be done in this PR

I agree! Looks great :D I'll work on this now quick

[Avtrkrb]

@will-lamerton I think when this PR gets merged, we need to bump the version to 1.30.0 due to some of the breaking changes that are introduced. The older agents.config.json & the array format mcp servers configuration won't work anymore. What do you think ?

[will-lamerton]

@will-lamerton I think when this PR gets merged, we need to bump the version to 1.30.0 due to some of the breaking changes that are introduced. The older agents.config.json & the array format mcp servers configuration won't work anymore. What do you think ?

I agree, but, I was going to do just version 1.21.0 - any specific reason to go to 1.30.0? :)

[Avtrkrb]

I agree, but, I was going to do just version 1.21.0 - any specific reason to go to 1.30.0? :)

Sorry, it was a typo on my end. I meant 1.21.0, but got distracted by another number on my screen & typed 30 instead of 21. 😅 I originally meant could we do 1.21.0 instead of 1.20.5...

[will-lamerton]

@Avtrkrb - pretty happy to merge if you are :)

[Avtrkrb]

@Avtrkrb - pretty happy to merge if you are :)

Let's go for it !👍🏻

[will-lamerton]

Hey @Avtrkrb - resolved conflicts, can you test one more time? Everything passes this end

[Avtrkrb]

Hey @Avtrkrb - resolved conflicts, can you test one more time? Everything passes this end

Thanks for your help in resolving the conflicts, I did another round of test on my end, everything looks good. I think we're good to go ! 👍🏻