The Video Assistant · Lesson 9 — The Away Fixture ← Course

The away fixture — shipping to production.

From a program on your laptop to a service others can call — same tool, new plumbing.

“Deploying” an MCP server sounds heavy, but it is not a special act. It just means deciding where the server runs and how clients reach it. The tool code you already wrote — the @mcp.tool() functions — does not change at all.

There are three stages, and they are the same server each time. On your machine, over stdio, the client launches it as a local program (where we have been so far). Across your machine, you run it as a small web service on localhost, so several local apps share one running copy. In production, you host that same web service so authorized people can reach it over the internet.

Only two things change as you move outward: the transport line at the bottom of your file, and where you run it. Going to production adds the ordinary duties of any web service — HTTPS, authentication, hosting — but nothing about the tool itself.

Flip between the three stages and watch exactly what changes — and what stays untouched.

Where does it run?
unchanged in all three @mcp.tool() · async def offside_calls(player, season) -> str
your server — the last line


      
how a client connects

      


      

        
shipping checklist — production

        
    
          
  • Switch transport to Streamable HTTP and bind to 0.0.0.0 so the host can accept outside connections.
    • 
          
  • Serve over HTTPS. Terminate TLS at a reverse proxy or load balancer in front of the server.
    • 
          
  • Require authentication. Only authorized clients may call — MCP supports OAuth 2.1 for HTTP; at minimum, check an API token.
    • 
          
  • Host it like any service: a container or VM kept alive by a process manager (Docker, systemd, or a cloud platform).
    • 
          
  • Validate every input. Never trust arguments blindly — a caller could send anything. Guard, limit, and sanitise.
    • 
          
  • Log and monitor calls, and version your tools so changing one does not break clients already using it.
    • 
        

      

    


    

      
Same tool. Different plumbing.

      

        A local stdio server, a localhost web service, and a hosted production service are the same
        MCP server — the difference is one transport line and where it runs. The model, the client,
        and your tool functions behave identically; only the address and the framing change.
      

      

        So build once over stdio, prove it works, then take it on tour: flip the transport to
        Streamable HTTP, put it behind HTTPS and auth, and host it. Production is not a rewrite — it
        is the same server, wired to reach further.
      

      

        Next: the team sheet →
        
      

    


  


  

    

      ▸ Go deeper — the two transports and what production really adds optional
      

        
The two standard transports

        

          MCP defines exactly two standard ways to carry its messages. stdio: the client
          launches your server as a subprocess and they exchange newline-delimited JSON-RPC over
          standard input/output. Streamable HTTP: each message is an HTTP POST to a
          single MCP endpoint (e.g. /mcp), and replies come back as JSON or a short
          server-sent-events stream. Same protocol, same tool definitions — only the framing differs.
        

        
Local vs remote is just an address

        

          Streamable HTTP bound to 127.0.0.1 is local; bound to 0.0.0.0 behind
          a public hostname it is remote. There is no separate “remote mode” to learn — production is
          the HTTP transport plus the usual web-service concerns.
        

        
Authentication

        

          A local stdio server inherits your machine's trust — it runs as you. The moment it is
          reachable over a network, that is gone: you must decide who may call it. MCP specifies OAuth
          2.1 for HTTP-based auth; a smaller internal tool might start with a shared token checked on
          every request. Either way, unauthenticated public tools are an open door.
        

        
Deploy it like any web service

        

          Once it speaks HTTP, an MCP server is a normal backend: put it in a container, run it behind
          a reverse proxy that terminates TLS, keep it alive with a process manager, and watch its
          logs. Nothing here is MCP-specific — which is the point.
        

        
The tool code never moves

        

          Across all of this, your @mcp.tool() functions are byte-for-byte identical. That
          is the payoff of the standard socket: you write the tool once and change only how it is
          reached.