A developer wants to run the Terraform MCP server for an AI assistant inside a local IDE. Separately, a platform team plans a shared instance that many remote clients will reach over the network. Which transport choices fit HashiCorp's guidance?
Select an answer to reveal the explanation.
Short Explanation
stdio is a direct cable between the assistant and the server on your own machine; streamable HTTP is the network version for sharing. If you share it, you lock the door: TLS on the wire and only approved origins allowed in. The trap is the wide-open option, which hands your Terraform environment to anyone who finds the port.
Full Explanation
The Terraform MCP server supports two transports. With stdio, the MCP client launches the server as a local process and exchanges messages over standard input and output, which suits a single developer's IDE and is the default. Streamable HTTP serves the protocol over HTTP or HTTPS so remote clients can connect, which suits a shared service. HashiCorp's security guidance recommends running the server locally where possible, adding TLS when it is reachable remotely, keeping its strict cross-origin mode with an explicit allowed-origins list, and applying rate limits. stdio is a process pipe, not a network listener, so it cannot be exposed on a public port. The server clearly does support a network transport, which is why the shared service is possible at all. Binding to all interfaces with cross-origin checks disabled removes the protections the documentation calls for and exposes workspace operations to any client that can reach the port. Exam caveat: the token the server uses for HCP Terraform or Terraform Enterprise defines what any connected client can do, so the transport choice and the token scope must be designed together. Operational check: for the shared service, confirm the endpoint serves only HTTPS and that a request from an unlisted origin is rejected.