← ALL POSTS
MCPAI ToolsDeveloper ProductivityLLMs

MCP for Developers: Connecting LLMs to Real Tools Without Custom Glue Code

·Srinivasa Varma·5 min read

Most AI assistants begin as a chat box. That is useful for explaining code, drafting SQL, reviewing snippets, or summarizing documentation. But real engineering work rarely lives in one text window.

A developer investigating a production issue may need logs, recent commits, database records, deployment metadata, error traces, and configuration files. Copying all of that into a chat manually is slow, incomplete, and risky.

That is the problem Model Context Protocol, or MCP, is designed to solve.

MCP is an open protocol that lets AI applications connect to external systems in a standard way. It gives AI assistants controlled access to tools, data, and workflows without every team having to build custom integrations for every AI client.

MCP is not a model. It is not a prompt framework. It is infrastructure for connecting models to the systems where real work happens.

Why MCP Exists

Before MCP, integrations were usually custom-built.

If an AI assistant needed GitHub access, someone built a GitHub connector. If it needed database access, someone built another connector. If it needed access to internal documentation, logs, cloud services, or ticketing tools, more glue code followed.

That approach does not scale well across teams, vendors, or tools.

MCP introduces a shared structure:

  • MCP Host: The AI application, such as an IDE assistant, desktop app, or agent platform.
  • MCP Client: The connector inside the host that talks to an MCP server.
  • MCP Server: A service that exposes tools, resources, and prompts.
  • Tools: Functions the assistant can call.
  • Resources: Data the assistant can read.
  • Prompts: Reusable workflow templates.

Conceptually:

User request
   -> AI application
      -> MCP client
         -> MCP server
            -> Database, API, logs, files, SaaS tools

The AI app does not need to understand every backend system directly. It only needs to speak MCP.

Real-World Example: Global Checkout Debugging

Imagine a global e-commerce platform. Customers can pay in USD, EUR, JPY, GBP, and many other currencies.

After a deployment, payment failures increase for several markets. A developer asks:

Investigate why card payments are failing after the latest checkout release.

Without MCP, the developer would open dashboards, logs, GitHub, deployment tools, and payment records manually.

With MCP, the AI assistant can use approved tools such as:

  • get_recent_deployments
  • search_payment_failures
  • get_order_payment_status
  • read_checkout_config
  • find_related_commits

The assistant can gather evidence instead of guessing.

It might discover that a recent code change incorrectly handles currencies with different decimal rules. For example, USD commonly uses two decimal places, while JPY does not. If the checkout service sends the wrong amount format to the payment provider, some payments will fail.

That is where MCP becomes useful: the assistant can connect the alert, logs, code change, and payment records into one investigation flow.

A Small MCP Server Example

Here is a simple Python MCP server for a payment investigation workflow.

from mcp.server.fastmcp import FastMCP
 
mcp = FastMCP("global-payment-support", json_response=True)
 
PAYMENTS = {
    "pay_1001": {
        "market": "US",
        "currency": "USD",
        "amount_minor": 2599,
        "status": "paid",
        "failure_reason": None,
    },
    "pay_1002": {
        "market": "JP",
        "currency": "JPY",
        "amount_minor": 2599,
        "status": "failed",
        "failure_reason": "invalid_amount_format",
    },
    "pay_1003": {
        "market": "DE",
        "currency": "EUR",
        "amount_minor": 4999,
        "status": "paid",
        "failure_reason": None,
    },
}
 
 
@mcp.tool()
def get_payment_status(payment_id: str) -> dict:
    """Return payment status for a payment ID."""
    payment = PAYMENTS.get(payment_id)
 
    if not payment:
        return {"found": False, "message": "Payment not found"}
 
    return {"found": True, "payment_id": payment_id, **payment}
 
 
@mcp.tool()
def search_failed_payments(currency: str) -> list[dict]:
    """Return failed payments for a currency."""
    return [
        {"payment_id": payment_id, **payment}
        for payment_id, payment in PAYMENTS.items()
        if payment["currency"] == currency and payment["status"] == "failed"
    ]
 
 
@mcp.resource("schema://payments")
def payment_schema() -> str:
    """Describe payment fields exposed by this server."""
    return """
    Payment fields:
    - payment_id: Unique payment identifier
    - market: Market or country code
    - currency: ISO currency code
    - amount_minor: Amount in the smallest currency unit
    - status: paid | failed | pending
    - failure_reason: Provider or internal failure reason
    """
 
 
@mcp.prompt()
def investigate_payment_failures(currency: str) -> str:
    """Create a reusable payment investigation prompt."""
    return f"""
    Investigate failed payments for {currency}.
    First read the payment schema.
    Then search failed payments.
    Look for patterns in market, amount format, provider errors, and recent releases.
    Return likely cause, supporting evidence, and next debugging step.
    """
 
 
if __name__ == "__main__":
    mcp.run(transport="streamable-http")

Run it:

uv run --with mcp server.py

Then inspect it:

npx -y @modelcontextprotocol/inspector

An MCP-compatible client can now discover the server's tools, resources, and prompts.

What the AI Assistant Can Do

The assistant may call a tool like this:

{
  "tool": "search_failed_payments",
  "arguments": {
    "currency": "JPY"
  }
}

The server returns structured data:

[
  {
    "payment_id": "pay_1002",
    "market": "JP",
    "currency": "JPY",
    "amount_minor": 2599,
    "status": "failed",
    "failure_reason": "invalid_amount_format"
  }
]

From there, the assistant can reason over real operational context:

The failures appear related to amount formatting for JPY payments.
JPY has no minor decimal unit, but the checkout service appears to be treating it like a two-decimal currency.
Check the latest currency normalization change in the checkout service.

The important point is not that the model became magically smarter. It simply received better, structured context through a controlled interface.

Tools, Resources, and Prompts

MCP becomes easier to understand when you separate its primitives.

Use a resource when the assistant needs to read context:

@mcp.resource("config://checkout")
def checkout_config() -> str:
    return """
    payment_provider = global-card-provider
    amount_format = minor_units
    retry_attempts = 2
    """

Use a tool when the assistant needs to perform an action:

@mcp.tool()
def create_refund_request(payment_id: str, reason: str) -> dict:
    """Create a refund request for review."""
    return {
        "payment_id": payment_id,
        "status": "queued_for_review",
        "reason": reason,
    }

Use a prompt when you want to standardize a workflow:

@mcp.prompt()
def write_incident_summary(service: str) -> str:
    return f"""
    Write an incident summary for {service}.
    Include impact, timeline, root cause, resolution, and follow-up actions.
    Keep the language clear for engineering, support, and operations teams.
    """

Simple rule:

Resource = read data
Tool     = take action
Prompt   = guide workflow

Why Developers Should Care

MCP is useful because engineering context is scattered.

A developer-friendly MCP setup can help AI assistants:

  • Read repository files.
  • Inspect pull requests.
  • Query logs.
  • Search documentation.
  • Look up database schemas.
  • Analyze failed jobs.
  • Review deployment history.
  • Summarize incidents.
  • Call safe internal APIs.

Instead of pasting context into a chat, developers can connect the assistant to approved sources of truth.

Security Still Matters

MCP gives assistants access to real systems, so tool design must be careful.

Avoid broad tools like:

run_any_sql(query)
execute_shell_command(command)
delete_file(path)
send_email(to, body)

Prefer narrow, auditable tools:

get_failed_payment_count(currency)
read_checkout_config()
create_refund_request(payment_id, reason)
search_recent_errors(service, time_range)

Good MCP servers should include:

  • Clear tool names.
  • Input validation.
  • Authentication.
  • Authorization.
  • Human approval for risky actions.
  • Audit logs.
  • Read-only access where possible.

The goal is not to give the model unlimited access. The goal is to give it the smallest useful set of capabilities.

Final Thought

MCP matters because it gives AI applications a standard way to work with real-world systems.

For developers, that means fewer custom connectors, less copy-paste context, and more practical assistants. The best MCP servers will not be huge or flashy. They will be focused adapters around real workflows: debugging payments, reviewing pull requests, checking logs, querying safe data, or summarizing incidents.

That is where MCP becomes valuable: not as hype, but as a clean bridge between language models and the tools developers already use.

References: Official MCP docs · MCP specification · MCP Python SDK · GitHub MCP docs