interop-mcp-server
Advanced tools
MCP (Model Context Protocol) server for Interop - Run commands and manage projects via AI assistants
Interop is a powerful command-line interface tool designed to improve developer productivity by providing a unified interface for managing projects, executing commands, and integrating with AI assistants.
Interop serves as a bridge between your development projects, custom commands, and AI assistants. It allows you to:
brew install yigitozgumus/formulae/interop
git clone https://github.com/yigitozgumus/interop.git
cd interop
go build -o interop ./cmd/cli
Interop uses a TOML configuration file at ~/.config/interop/settings.toml. To edit it:
interop edit
# Global settings
log_level = "verbose" # Options: error, warning, verbose
executable_search_paths = ["~/.local/bin", "~/bin"]
command_dirs = ["~/.config/interop/commands.d", "~/projects/shared/interop-commands"]
mcp_port = 8081 # Default MCP server port
# MCP Server Configurations
[mcp_servers.domain1]
name = "domain1"
description = "Domain-specific commands"
port = 8082
[mcp_servers.domain2]
name = "domain2"
description = "Another domain for commands"
port = 8083
# Project Definitions
[projects.project1]
path = "~/projects/project1"
description = "Project 1 description"
commands = [
{ command_name = "build", alias = "b" },
{ command_name = "test" }
]
[projects.project2]
path = "~/projects/project2"
description = "Project 2 description"
commands = [
{ command_name = "deploy", alias = "d" }
]
# Command Definitions
[commands.build]
cmd = "go build ./..."
description = "Build the project"
is_enabled = true
is_executable = false
# Assign to a specific MCP server
mcp = "domain1"
[commands.test]
cmd = "go test ./..."
description = "Run tests"
is_enabled = true
is_executable = false
[commands.deploy]
cmd = "deploy.sh"
description = "Deploy the project"
is_enabled = true
is_executable = true
mcp = "domain2"
# Command with Arguments, Version, and Examples
[commands.build-app]
cmd = "go build -o ${output_file} ${package}"
description = "Build a Go application"
version = "1.1.0"
is_enabled = true
is_executable = false
arguments = [
{ name = "output_file", type = "string", description = "Output file name", required = true },
{ name = "package", type = "string", description = "Package to build", default = "./cmd/app" }
]
examples = [
{
description = "Build the main application",
command = "interop run build-app output_file=my-app"
},
{
description = "Build a specific package",
command = "interop run build-app output_file=my-tool package=./cmd/tool"
}
]
Projects are the core organizational unit in Interop.
interop projects
Output example:
PROJECTS:
=========
📁 Name: project1
Path: ~/projects/project1
Status: Valid: ✓ | In $HOME: ✓
Description: Project 1 description
Commands:
⚡ build (alias: b)
Build the project
⚡ test
Run tests
📁 Name: project2
Path: ~/projects/project2
Status: Valid: ✓ | In $HOME: ✓
Description: Project 2 description
Commands:
⚡ deploy (alias: d)
Deploy the project
Each project includes:
Interop supports loading configuration definitions from multiple directories, enabling better organization and scalability for large configuration collections.
Add command_dirs to your global settings to specify directories containing configuration definition files:
command_dirs = [
"~/.config/interop/config.d",
"~/projects/shared/interop-configs"
]
Each directory can contain multiple *.toml files with configuration definitions:
~/.config/interop/config.d/
├── git-commands.toml
├── docker-commands.toml
├── dev-projects.toml
└── ai-prompts.toml
Example git-commands.toml:
[commands.git-status]
cmd = "git status"
description = "Show the working tree status"
version = "1.0.0"
is_enabled = true
mcp = "dev-tools"
[commands.git-pull]
cmd = "git pull --rebase"
description = "Fetch from and integrate with another repository"
version = "1.0.0"
is_enabled = true
mcp = "dev-tools"
Example dev-projects.toml:
[projects.my-api]
path = "~/projects/my-api"
description = "Main API project"
commands = [
{ command_name = "build", alias = "b" },
{ command_name = "test", alias = "t" }
]
Configuration files in these directories can contain:
[commands.name]) - Command definitions[projects.name]) - Project configurations[prompts.name]) - AI prompt templates[mcp_servers.name]) - MCP server definitionsWhen configuration names conflict, Interop follows a clear precedence order:
settings.toml (highest priority)command_dirsThis ensures predictable configuration resolution and allows for easy overriding of shared configurations.
Interop includes a powerful remote configuration system that allows you to fetch and manage configurations from Git repositories. This enables teams to share command definitions, maintain centralized configuration libraries, and keep local setups synchronized with remote sources.
The remote configuration system:
config.d.remote and executables.remote directories# Add a remote Git repository
interop config remote add my-team https://github.com/myteam/interop-configs.git
# Add with SSH (recommended for private repositories)
interop config remote add my-team git@github.com:myteam/interop-configs.git
interop config remote show
Output example:
Remote Configurations:
======================
🔗 my-team
URL: git@github.com:myteam/interop-configs.git
Status: ✓ Valid Git URL
🔗 shared-tools
URL: https://github.com/company/shared-tools.git
Status: ✓ Valid Git URL
# Fetch from all configured remotes
interop config remote fetch
# Fetch from a specific remote
interop config remote fetch my-team
The fetch process:
config.d and/or executables folders)# Remove a specific remote
interop config remote remove my-team
# Clear all remote configurations and cached files
interop config remote clear
Remote repositories must follow this structure:
your-repo/
├── config.d/ # Configuration files (required)
│ ├── commands.toml # Command definitions
│ ├── projects.toml # Project configurations
│ └── mcp-servers.toml # MCP server definitions
└── executables/ # Executable files (optional)
├── deploy.sh
├── build-tool
└── scripts/
└── helper.py
config.d/team-commands.toml:
[commands.team-deploy]
cmd = "deploy.sh"
description = "Deploy using team standards"
is_executable = true
mcp = "team-tools"
version = "2.1.0"
arguments = [
{ name = "environment", type = "string", required = true, description = "Target environment" },
{ name = "force", type = "bool", default = false, description = "Force deployment" }
]
[commands.team-test]
cmd = "run-team-tests.sh"
description = "Run standardized team tests"
is_executable = true
mcp = "team-tools"
[mcp_servers.team-tools]
name = "team-tools"
description = "Team standardized tools"
port = 8084
Remote configurations are automatically integrated into your local setup:
~/.config/interop/
├── settings.toml # Your local settings
├── config.d/ # Local configurations
│ └── personal.toml
├── config.d.remote/ # Remote configurations (auto-managed)
│ ├── team-commands.toml
│ └── shared-tools.toml
├── executables/ # Local executables
├── executables.remote/ # Remote executables (auto-managed)
│ ├── deploy.sh
│ └── build-tool
└── versions.toml # Remote tracking metadata (auto-managed)
When configurations conflict, Interop follows this precedence:
config.d/) - highest priorityconfig.d.remote/) - lower priorityThis ensures your local customizations always take precedence while still benefiting from shared remote configurations.
The validation system provides comprehensive conflict detection:
interop validate
Example output with conflicts:
Configuration Overview
=====================
Configuration Sources:
---------------------
🏠 Main Settings: /Users/user/.config/interop/settings.toml
🏠 Command Directories:
🏠 /Users/user/.config/interop/config.d (2 files)
☁️ Remote Configuration:
✓ config.d.remote: Available (3 files)
✓ executables.remote: Available (5 files)
✓ Remote tracking: Active
⚠️ Potential Conflicts:
⚠️ Command 'deploy' exists in both local and remote configs
⚠️ Command 'test-suite' exists in both local and remote configs
→ Local configurations take precedence
Commands:
--------
🌐 ✓ deploy (Shell) (🏠 Local)
└─ My custom deploy script
└─ 🔌 Default MCP server (Port: 8081)
🌐 ✓ team-deploy (Shell) (☁️ Remote)
└─ Deploy using team standards
└─ 🔌 Assigned to MCP server: team-tools (Port: 8084)
Interop maintains detailed tracking of remote configurations:
The system tracks:
Subsequent fetches are optimized:
The system validates Git URLs to ensure compatibility:
SSH Format:
git@github.com:user/repo.git
git@gitlab.com:user/repo.git
git@bitbucket.org:user/repo.git
HTTPS Format:
https://github.com/user/repo.git
https://gitlab.com/user/repo.git
https://bitbucket.org/user/repo.git
Custom Git Servers:
https://git.company.com/team/configs.git
git@git.company.com:team/configs.git
# Set up team-wide configurations
interop config remote add company-standards git@github.com:company/interop-standards.git
interop config remote fetch
# Now all team members have access to:
# - Standardized deployment scripts
# - Common development commands
# - Shared MCP server configurations
# - Team-specific project templates
# Different configurations for different environments
interop config remote add prod-tools git@github.com:company/prod-tools.git
interop config remote add dev-tools git@github.com:company/dev-tools.git
# Fetch environment-specific tools
interop config remote fetch prod-tools
interop config remote fetch dev-tools
# Add community-maintained tool collections
interop config remote add awesome-dev-tools https://github.com/community/awesome-dev-tools.git
interop config remote fetch
Repository not found:
# Check URL and access permissions
git clone <your-repo-url> # Test manually
Invalid repository structure:
# Ensure repository has config.d/ or executables/ directory
# Check repository contents match expected structure
Conflicts with local configurations:
# Use validation to identify conflicts
interop validate
# Rename local commands if needed
# Or remove remote repository if not needed
Network issues:
# Check internet connectivity
# Verify Git credentials are set up
# Try fetching manually: git clone <repo-url>
Interop provides a flexible command system that adapts to your workflow.
interop commands
Output example:
COMMANDS:
=========
⚡ Name: build
Status: Enabled: ✓ | Source: Script
Description: Build the project
MCP Server: domain1
⚡ Name: test
Status: Enabled: ✓ | Source: Script
Description: Run tests
⚡ Name: deploy
Status: Enabled: ✓ | Source: Executable
Description: Deploy the project
MCP Server: domain2
Shell Commands: Run through the system shell
[commands.list]
cmd = "ls -la"
Executable Commands: Run directly from configured paths
[commands.deploy]
cmd = "deploy.sh"
is_executable = true
Project-bound Commands: Run in the context of a specific project
[projects.project1]
commands = [{ command_name = "build" }]
Commands with Arguments: Templated commands with validation
[commands.build-app]
cmd = "go build -o ${output_file} ${package}"
arguments = [
{ name = "output_file", type = "string", required = true },
{ name = "package", type = "string", default = "./cmd/app" }
]
Run a command by name or alias:
# Simple command
interop run build
# Command with alias
interop run b # Runs the build command
# Command with arguments
interop run build-app output_file=myapp.exe
For project-bound commands, Interop automatically:
Interop includes robust support for AI integration via MCP (Model Context Protocol) servers.
MCP servers expose your commands as tools that can be invoked by AI assistants like Claude. Each server can provide a different set of commands, allowing domain-specific organization.
# Start servers
interop mcp start # Start default server
interop mcp start domain1 # Start specific server
interop mcp start --all # Start all servers
# Check status
interop mcp status # Default shows all servers
interop mcp status domain1 # Check specific server
# Stop servers
interop mcp stop domain1 # Stop specific server
interop mcp stop --all # Stop all servers
# Restart servers
interop mcp restart domain1 # Restart specific server
interop mcp restart --all # Restart all servers
# Port management
interop mcp port-check # Check if ports are available
# Get configuration for AI tools
interop mcp export # Export JSON configuration
You can organize commands by domain:
[mcp_servers.work]
name = "work"
description = "Work-related commands"
port = 8082
[mcp_servers.personal]
name = "personal"
description = "Personal project commands"
port = 8083
[commands.work-task]
cmd = "work-script.sh"
mcp = "work" # This command is available on the work server
[commands.personal-task]
cmd = "personal-script.sh"
mcp = "personal" # This command is available on the personal server
Each server exposes only the commands assigned to it, creating a clean separation between different domains.
When an AI assistant connects to an MCP server, it can:
This creates a powerful interface where the AI can help you execute tasks based on natural language instructions.
Commands can have typed arguments with validation:
[commands.generate]
cmd = "generate.sh ${type} ${name} ${force}"
description = "Generate a new component"
arguments = [
{ name = "type", type = "string", description = "Component type", required = true },
{ name = "name", type = "string", description = "Component name", required = true },
{ name = "force", type = "bool", description = "Overwrite if exists", default = false }
]
--key)# Named arguments
interop run generate type=component name=Button
# Positional arguments (in order of definition)
interop run generate component Button true
Prefixed arguments allow you to define command-line arguments with specific prefixes (such as --keys or -f). This is especially useful when working with scripts or tools that expect arguments in a specific format:
[commands.update-strings]
cmd="python3 scripts/update_strings.py"
description="Update localization strings"
arguments=[
{name = "keys", type="string", required = false, description = "Keys to update", prefix = "--keys"},
{name = "language", type="string", required = false, description = "Language code", prefix = "--language"},
{name = "verbose", type="bool", required = false, description = "Verbose output", prefix = "--verbose"}
]
When executing:
interop run update-strings --keys "key1 key2" --language en --verbose true
The actual command executed will be:
python3 scripts/update_strings.py --keys key1 key2 --language en --verbose
${arg_name} placeholderstrue, only the prefix is added; otherwise, the argument is omittedInterop supports rich metadata for commands to improve AI assistant integration and documentation.
Add version tracking to your commands:
[commands.deploy]
cmd = "deploy.sh"
description = "Deploy the application"
version = "2.1.0"
is_enabled = true
Provide concrete examples of how to use commands:
[commands.create-component]
cmd = "generate.sh ${type} ${name}"
description = "Generate a new component"
version = "1.0.0"
arguments = [
{ name = "type", type = "string", description = "Component type", required = true },
{ name = "name", type = "string", description = "Component name", required = true }
]
examples = [
{
description = "Create a React component",
command = "interop run create-component type=react name=Button"
},
{
description = "Create a Vue component",
command = "interop run create-component type=vue name=Header"
}
]
When commands include version and examples:
interop validate
The validation system provides comprehensive analysis of your configuration:
settings.toml exists and is accessibleconfig.d/config.d.remote/ and executables.remote/Configuration Overview
=====================
Configuration Sources:
---------------------
🏠 Main Settings: /Users/user/.config/interop/settings.toml
🏠 Command Directories:
🏠 /Users/user/.config/interop/config.d (2 files)
☁️ Remote Configuration:
✓ config.d.remote: Available (3 files)
✓ executables.remote: Available (5 files)
✓ Remote tracking: Active
⚠️ Potential Conflicts:
⚠️ Command 'deploy' exists in both local and remote configs
→ Local configurations take precedence
MCP Servers:
-----------
🔌 Default MCP Server (Port: 8081)
└─ Commands: (commands with no MCP field)
🔌 team-tools MCP Server (Port: 8084)
└─ Team standardized tools
└─ Commands: 5
Commands:
--------
🌐 ✓ deploy (Shell) (🏠 Local)
└─ My custom deploy script
└─ 🔌 Default MCP server (Port: 8081)
🌐 ✓ team-deploy (Shell) (☁️ Remote)
└─ Deploy using team standards
└─ 🔌 Assigned to MCP server: team-tools (Port: 8084)
Legend:
-------
🌐 Global Command 🏠 Local Configuration
📂 Project-bound Command ☁️ Remote Configuration
🔄 Command Alias ⚠️ Warning/Conflict
✓ Enabled Command 🔌 MCP Server Association
❌ Disabled Command
✅ Configuration is valid!
interop mcp port-check
This shows:
Configure verbosity in settings:
log_level = "verbose" # Options: error, warning, verbose
Interop searches for executables in:
~/.config/interop/executables/)executable_search_paths = ["~/.local/bin", "~/bin"]
.
├── cmd/
│ └── cli/ # Main application entry point
├── internal/
│ ├── command/ # CLI command implementations
│ ├── display/ # Output formatting utilities
│ ├── edit/ # Project editing functionality
│ ├── logging/ # Logging with color control
│ ├── mcp/ # MCP server implementation
│ ├── project/ # Project management core
│ ├── settings/ # Configuration management
│ └── util/ # Shared utilities
├── dist/ # Distribution files
└── .github/ # GitHub workflows and templates
Run the test suite:
go test ./...
# Remote repository management
interop config remote add <name> <git-url> # Add remote repository
interop config remote remove <name> # Remove remote repository
interop config remote show # List all remotes
interop config remote clear # Remove all remotes and cached files
# Fetching configurations
interop config remote fetch # Fetch from all remotes
interop config remote fetch <name> # Fetch from specific remote
# Validation and diagnostics
interop validate # Comprehensive configuration validation
interop mcp port-check # Check MCP server port availability
~/.config/interop/settings.toml # Main configuration file
~/.config/interop/config.d/ # Local configuration directory
~/.config/interop/config.d.remote/ # Remote configurations (auto-managed)
~/.config/interop/executables/ # Local executable files
~/.config/interop/executables.remote/ # Remote executables (auto-managed)
~/.config/interop/versions.toml # Remote tracking metadata (auto-managed)
This project is licensed under the MIT License - see the LICENSE file for details.
FAQs
MCP (Model Context Protocol) server for Interop - Run commands and manage projects via AI assistants
The npm package interop-mcp-server receives a total of 6 weekly downloads. As such, interop-mcp-server popularity was classified as not popular.
We found that interop-mcp-server demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Company News
Socket won two 2026 Reppy Awards from RepVue, ranking in the top 5% of all sales orgs. AE Alexandra Lister shares what it's like to grow a sales career here.
Security News
NIST will stop enriching most CVEs under a new risk-based model, narrowing the NVD's scope as vulnerability submissions continue to surge.
Company News
/Security News
Socket is an initial recipient of OpenAI's Cybersecurity Grant Program, which commits $10M in API credits to defenders securing open source software.