Cross-Harness Tool Parity: Build One Custom MCP Tool, Deploy It Everywhere

Tired of maintaining separate AI coding tool configs for Claude Code, Cursor, and Windsurf? Discover how the Model Context Protocol (MCP) and TormentNexus enable true "write once, run anywhere" tool parity across six major AI development environments.

The "One Config to Rule Them All" Problem in Modern AI Tooling

As an AI-assisted developer, your workflow likely involves a hybrid toolkit. You might use Claude Code for its deep architectural reasoning in the terminal, Cursor for its powerful inline edits and chat, and Windsurf for its seamless cloud integration. Add in Copilot for quick completions, Codex for exploration, and the Gemini CLI for its unique capabilities, and you're managing at least six different AI "harnesses."

The core inefficiency? Each harness often requires its own bespoke tool configuration. A custom script you built to query your internal database needs one setup for Cursor, a slightly different one for Claude Code, and a third for Windsurf. This "tool fragmentation" creates cognitive overhead, configuration drift, and duplicated effort. The promise of AI augmentation is hampered by the very tools meant to deliver it. The goal is clear: achieve tool parity—the state where a single, powerful custom tool works identically across all your chosen AI environments.

Enter the Model Context Protocol (MCP): The Universal Adapter

The Model Context Protocol (MCP) is an open standard that solves this fragmentation problem at the architectural level. Think of it as a universal adapter for AI tooling. It defines a clean, standardized interface for how an AI model (the "host") can request capabilities from an external tool (the "server"). Instead of building six vendor-specific integrations, you build one MCP-compliant tool server.

A robust MCP tool is more than a simple API wrapper. It includes a clear schema definition, detailed tool descriptions for the AI to understand its purpose, and robust input/output handling. This standardization is the key that allows any harness that speaks the MCP protocol to seamlessly discover, understand, and utilize your tool. The magic happens when a single, well-crafted tool can be invoked by any compliant host with zero reconfiguration.

A Practical Example: Building a Unified Project Intelligence Tool

Let's move from theory to practice. Imagine a common need: a tool that provides deep, real-time context about your current project, far beyond what `git status` can offer. It could aggregate build health, dependency risks, and recent code churn metrics from your CI pipeline and SonarQube instance.

Here is a simplified Python example of such a tool built as an MCP server using the official `mcp` library:

# project_intel_mcp_server.py
import json
from mcp.server import Server
from mcp.types import Tool, TextContent

# Our single source of truth for project intelligence
def get_project_intelligence(project_root: str) -> dict:
    # Complex logic to query CI, static analysis, and git
    # Returns a structured dictionary
    return {
        "project": project_root,
        "ci_status": "passing (12/12 recent builds)",
        "security_hotspots": 2,
        "technical_debt_hours": 14.5,
        "most_churned_file": "src/core/payment_processor.py (18 commits last week)"
    }

app = Server("project-intel")

@app.tool()
async def analyze_project_context(project_path: str) -> list[TextContent]:
    """Gathers comprehensive project health intelligence. Use this when discussing architecture, onboarding, or debugging systemic issues."""
    data = get_project_intelligence(project_path)
    return [TextContent(type="text", text=json.dumps(data, indent=2))]

if __name__ == "__main__":
    # Initialize and run the stdio-based MCP server
    import asyncio
    asyncio.run(app.run_stdio())

This single script is our entire tool. Its configuration is now defined by the harness it's run within, not by the tool itself.

From One Tool to Six Harnesses: The Configuration Dance

With the MCP server built, achieving tool parity is a matter of pointing each AI harness to run it. The configuration is minimal and declarative. Here’s how you’d declare this same `project-intel` tool for three different environments:

1. For Claude Code (via `.claude/settings.json`):

{
  "mcpServers": {
    "project-intel": {
      "command": "python",
      "args": ["path/to/project_intel_mcp_server.py"],
      "env": { "SOME_VAR": "value" }
    }
  }
}

2. For Cursor (via `cursor_mcp.json` in project root):

{
  "mcpServers": {
    "project-intel": {
      "command": "python",
      "args": ["./path/to/project_intel_mcp_server.py"]
    }
  }
}

3. For Windsurf (via its MCP configuration UI or `.windsurfmcp` file):

{
  "servers": {
    "project-intel": {
      "type": "stdio",
      "command": "python",
      "args": ["path/to/project_intel_mcp_server.py"]
    }
  }
}

Notice the pattern: the tool (`project_intel_mcp_server.py`) remains completely untouched. We only change the "address" in each harness's configuration file to point to it. This is the essence of tool parity.

Beyond the Basics: Achieving True Parity Across All Six Harnesses

The same principle extends to the full sextet. Cursor, Claude Code, and Windsurf are early MCP leaders, but the protocol's design makes integration feasible for others. Copilot is evolving towards tool use, and both Codex and the Gemini CLI could be extended to speak MCP, either natively or via a thin adapter. The goal is not to force a single harness, but to ensure your custom capabilities are harness-agnostic. A critical benefit is maintainability: when you need to update the tool's logic (e.g., adding a new data source to the `project_intel` analysis), you update it in one place. Every AI environment—from Copilot in your IDE to Codex in your notebook—inherits the improvement instantly.

The Future is Composable: TormentNexus as Your Parity Hub

While manual configuration is a huge step forward, a platform like TormentNexus is designed to be the orchestration layer that makes this workflow seamless. It acts as a central registry and deployment hub for your MCP tool portfolio. You can define, version, and manage all your custom tools in one place. TormentNexus then simplifies the distribution of configuration snippets to any harness, ensuring consistent environment variables and secrets management. It transforms the "build once, run everywhere" mantra from a manual process into an automated, governed pipeline, accelerating your team's journey to full tool parity.

Stop wrestling with redundant configurations. Centralize your AI tooling with TormentNexus and unlock true MCP-powered parity across your entire development stack. Learn more and get started.

---

Originally published at tormentnexus.site