MCP Personal Tools: When Overkill (2026)

The r/AI_Agents post "Stop Building MCP Servers for Personal Tools" made a fair point: wrapping a simple Python script in an MCP server so Claude can call it is over-engineering if you are the only user and Claude Desktop is the only runtime. But the post missed the case where MCP is not overkill. It is the right abstraction.

When MCP is genuinely overkill

You have a script that checks your AWS costs. You run it from the terminal. You want Claude to be able to run it too. The tempting path: build an MCP server, define tool schemas, handle JSON-RPC, deploy it. The simpler path: let Claude run the script via bash tool access. Same result. No MCP boilerplate.

MCP adds overhead. You need to define tool schemas with descriptions and parameter types. You need to handle the JSON-RPC transport. You need to keep the server running. For a single script used by one person in one runtime, this is unnecessary ceremony.

When MCP is the right choice

The decision hinge is one question: will this tool be used in multiple agent runtimes? If the answer is yes, MCP saves you from writing the integration twice. Claude Desktop, Cursor, VS Code Copilot, ChatGPT, and other agent hosts all speak MCP. One server, many clients.

# WITHOUT MCP: works in one runtime, duplicated per client
# claude_tool.py - only works in Claude Desktop
def check_serp_ranking(domain, keyword):
    import requests, os
    r = requests.post('https://api.scavio.dev/api/v1/search',
                      headers={'x-api-key': os.environ['SCAVIO_API_KEY']},
                      json={'query': keyword, 'num_results': 20})
    results = r.json().get('results', [])
    for i, result in enumerate(results):
        if domain in result.get('url', ''):
            return f"Position {i+1} for '{keyword}'"
    return f"Not found in top 20 for '{keyword}'"

# To use in Cursor: rewrite as Cursor extension
# To use in VS Code: rewrite as VS Code extension
# To use in ChatGPT: rewrite as OpenAI action

The multi-runtime test

Ask yourself three questions before building an MCP server. First: do I use more than one AI coding assistant? If yes, MCP lets the tool work in all of them. Second: will teammates use this tool in their own setups? If yes, MCP is the portable distribution format. Third: does this tool need structured input/output schemas? If yes, MCP's schema definitions are doing useful work, not just ceremony.

The middle ground: start without MCP, add it later

Write the function first. Test it as a plain script. If you find yourself copying it into a second agent runtime, that is your signal to wrap it in MCP. The wrapping takes 30 minutes for a simple tool. You are not losing time by starting simple.

# WITH MCP: works in any MCP-compatible runtime
# server.py - one server, works everywhere
from mcp.server import Server
import requests, os

app = Server("serp-checker")

@app.tool()
async def check_ranking(domain: str, keyword: str) -> str:
    """Check where a domain ranks for a keyword."""
    r = requests.post('https://api.scavio.dev/api/v1/search',
                      headers={'x-api-key': os.environ['SCAVIO_API_KEY']},
                      json={'query': keyword, 'num_results': 20})
    results = r.json().get('results', [])
    for i, result in enumerate(results):
        if domain in result.get('url', ''):
            return f"Position {i+1} for '{keyword}'"
    return f"Not in top 20 for '{keyword}'"

# Works in: Claude Desktop, Cursor, VS Code, ChatGPT, any MCP client

What the post got right

The original post was right that MCP has become a hammer looking for nails. Not every script needs a server. Not every function needs a JSON-RPC interface. The default should be simplicity.

What the post got wrong

The post framed MCP as always overkill. It is not. For tools that cross runtime boundaries, MCP is the only standard that works today. The alternative is maintaining N different integrations for N different agent hosts. That is more engineering, not less. The decision is not "MCP vs no MCP." It is "one runtime vs many runtimes."