Remote Access
By default, the MCP server listens on the loopback interface only. In this state it can be reached exclusively by processes running on the same machine as Cinema 4D — from the perspective of the surrounding network, the port does not exist. This is the appropriate configuration for the common case, in which the MCP Client (for example a desktop AI assistant application) runs on the same workstation as Cinema 4D.
The Remote Access settings govern the exceptions to that default. They become relevant in two situations:
-
An MCP Client runs on a different machine and needs to reach Cinema 4D across the network.
-
An MCP Client runs inside a web browser, in which case the browser's security model requires an explicit grant even when the request originates from the same machine.
The master switch for network access. While it is disabled, the server remains bound to the loopback interface and no connection from another host can be established, regardless of the other settings on this page.
Enabling it binds the server to a network-reachable interface, making the configured port available to other hosts. The Host field on the Server page becomes available at the same time, so that the interface the server listens on can be specified explicitly.
Opening the server to another machine takes three steps, and the first on its own achieves nothing:
-
Enable Allow Remote Connections and confirm the warning (see previous figure).
-
Set Host on the Server page to an address the other machine can reach.
-
Set Whitelisted IPs to the other machine’s address. The field is pre-filled with a default that should be reviewed rather than left as it stands — see below.
An allowlist of source addresses permitted to connect. It takes effect only when Allow Remote Connections is enabled, and it applies in addition to the Authentication Token: a connection from an address that is not on the list is rejected even if it presents a valid token. The address is examined first: a request from an address that is not on the list is refused before the token is looked at. While Allow Remote Connections is disabled the field cannot be edited.
The machine running Cinema 4D is always permitted and does not need to be listed. The field is not empty to begin with: enabling Allow Remote Connections makes it editable and reveals a default of 127.0.0.1, ::1, 192.168.1.0/24. The first two entries are the loopback addresses of the local machine, which are permitted in any case; the third is a CIDR range covering a private address block widely used by home and small-office routers. Where that range matches the network the workstation is attached to, every device on it is admitted as soon as the server is bound to a reachable interface. Treat the default as a starting point to be edited, not as a value to be accepted: replace it with the addresses that genuinely require access before the machine is exposed to a shared network.
Entries are separated by commas and may be given as individual addresses or as CIDR ranges:
| Entry | Meaning |
|---|---|
127.0.0.1
|
IPv4 loopback — the local machine |
::1
|
IPv6 loopback — the local machine |
192.168.1.42
|
A single host |
192.168.1.0/24
|
An entire subnet, 192.168.1.1 through 192.168.1.254 |
Restrict this list to the addresses that genuinely require access. Granting a whole subnet admits every present and future device on that network segment, including any guest or compromised host that joins it.
This setting addresses cross-origin resource sharing (CORS) rather than network location, and is required for MCP Clients that run as a web page inside a browser.
When a browser issues a request to a server other than the one that served the current page, it attaches an Origin header and will only pass the response back to the page if the server explicitly names that origin as permitted.
This field holds the list of origins to be granted, written as a scheme, host and — where it is not the default — a port:
https://example.com, http://localhost:3000
Because the page itself may be served from anywhere while the request still reaches Cinema 4D over the loopback interface, this setting is independent of the address allowlist and may be needed even when remote connections are disabled. Unlike Whitelisted IPs, this field therefore stays editable while Allow Remote Connections is switched off.
Security considerations
The MCP Server accepts connections over plain HTTP. On a network, the authentication token is therefore transmitted without encryption and can be observed by anyone able to capture traffic on that segment.
The consequences of an unauthorised connection depend on which capabilities have been granted in the Security settings. With Python execution enabled, a client that reaches the port with a valid token can run arbitrary code with the privileges of the Cinema 4D process, and can store Python into the scene file itself — code that runs whenever Cinema 4D evaluates the scene.
Accordingly:
-
Leave remote connections disabled unless a client on another machine genuinely requires access.
-
When remote connections are enabled, review Whitelisted IPs in the same step. The field arrives pre-filled with a private subnet range, and that range takes effect the moment the server is reachable.
-
Keep Browser Client Origins empty unless a browser-based client is in use. Unlike the address allowlist, this field is not governed by Allow Remote Connections: an origin listed here is granted access even while remote connections are disabled, because such a client reaches the server over loopback.
-
Where remote access is needed, list individual host addresses in preference to broad CIDR ranges.
-
Treat the authentication token as a credential: keep it out of screenshots, shared documents and version control, and reissue it if it may have been exposed.
-
For access across untrusted networks, prefer an SSH tunnel or a VPN over opening the port directly. Both encryption and authentication are then handled outside the adapter, and the server itself can remain bound to loopback.