Minor fixes

[msanatan]

Description

It was quicker to make some minor adjustments after the PRs were merged in than to go back and forth with the devs

Type of Change

• Refactoring (no functional changes)

Changes Made

• Better experience with incorrect local addresses
• Add a warning when we change the websocket URL, in case the implicit behaviour causes problems

Testing/Screenshots/Recordings

N/A

Related Issues

#542
#587

Additional Notes

Summary by Sourcery

Improve handling of local HTTP and WebSocket connection edge cases and add helper scripts for keeping forks up to date.

Enhancements:

• Refine the HTTP local server command UI for invalid or non-local URLs, disabling input and using clearer styling for error states.
• Log a warning and safely substitute localhost when the WebSocket base URL uses bind-only addresses like 0.0.0.0 or :: to avoid client connection issues.

Chores:

• Add cross-platform helper scripts to update a local fork from the upstream main branch.

[sourcery-ai]

Reviewer's Guide

Refines the HTTP local command UI handling for invalid/non-local URLs, adds logging when WebSocket URLs are implicitly rewritten from bind-only hosts to localhost, and introduces helper scripts for updating a forked repository from upstream.

Sequence diagram for WebSocket URL build with bind-only host rewrite

sequenceDiagram
  participant Client
  participant WebSocketTransportClient
  participant McpLog

  Client->>WebSocketTransportClient: BuildWebSocketUri(baseUrl)
  WebSocketTransportClient->>WebSocketTransportClient: Parse baseUrl as httpUri
  alt Invalid baseUrl
    WebSocketTransportClient->>Client: Throw InvalidOperationException
  else Valid baseUrl
    WebSocketTransportClient->>WebSocketTransportClient: host = httpUri.Host
    alt Host is bind-only (0.0.0.0 or ::)
      WebSocketTransportClient->>McpLog: Warn [WebSocket] Base URL host is bind-only, using localhost
      WebSocketTransportClient->>WebSocketTransportClient: host = localhost
    else Host is normal
      WebSocketTransportClient->>WebSocketTransportClient: Keep original host
    end
    WebSocketTransportClient->>WebSocketTransportClient: Build ws/wss Uri with host
    WebSocketTransportClient->>Client: Return WebSocket Uri
  end

Loading

Flow diagram for update_fork helper scripts

flowchart TD
  A[Run update_fork script] --> B[git checkout main]
  B --> C[git fetch -ap upstream]
  C --> D[git fetch -ap origin]
  D --> E[git rebase upstream/main]
  E --> F[git push]
  F --> G[Fork main branch updated from upstream]

Loading

File-Level Changes

Change	Details	Files
Adjust HTTP local command UI behavior for non-local/invalid URLs.	Disable the HTTP server command field when HTTP local is disabled or the URL is not local instead of showing a placeholder error value. Clear the HTTP server command field value and tooltip when no valid local command is available. Switch invalid URL styling to use new http-local-specific USS class names on the section and hint label, including separate add/remove class calls for error styling. Ensure the section state is reset (enable/disable, classes, hints) appropriately when the URL becomes valid again.	MCPForUnity/Editor/Windows/Components/Connection/McpConnectionSection.cs MCPForUnity/Editor/Windows/Components/Common.uss
Improve WebSocket URI construction for bind-only hosts and add explicit logging.	Generalize replacement of bind-only hosts so both 0.0.0.0 and :: are mapped to localhost for client WebSocket connections. Add a warning log when a bind-only host is rewritten to localhost to make this implicit behavior visible during debugging. Retain the existing URI-building logic while using the potentially rewritten host.	MCPForUnity/Editor/Services/Transport/Transports/WebSocketTransportClient.cs
Add helper scripts to sync local fork with upstream main branch.	Introduce a Windows batch script that checks out main, fetches from upstream and origin with pruning, rebases onto upstream/main, and pushes. Introduce a Unix shell script doing the same operations with strict error handling via set -euo pipefail.	tools/update_fork.bat tools/update_fork.sh

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• The new update_fork scripts assume an upstream remote and a main branch exist; consider adding checks (or parameters) so they fail with a clear message when those preconditions are not met instead of exiting with a generic git error.
• The logic for detecting/handling bind-only hosts (0.0.0.0, ::) in BuildWebSocketUri and the HTTP-local URL validation in the editor code are conceptually similar; consider centralizing the allowed/denied host checks to avoid these rules drifting apart over time.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The new `update_fork` scripts assume an `upstream` remote and a `main` branch exist; consider adding checks (or parameters) so they fail with a clear message when those preconditions are not met instead of exiting with a generic git error.
- The logic for detecting/handling bind-only hosts (`0.0.0.0`, `::`) in `BuildWebSocketUri` and the HTTP-local URL validation in the editor code are conceptually similar; consider centralizing the allowed/denied host checks to avoid these rules drifting apart over time.

## Individual Comments

### Comment 1
<location> `MCPForUnity/Editor/Services/Transport/Transports/WebSocketTransportClient.cs:688-690` </location>
<code_context>
+            // Replace bind-only addresses with localhost for client connections
+            // 0.0.0.0 and :: are only valid for server binding, not client connections
+            string host = httpUri.Host;
+            if (host == "0.0.0.0" || host == "::")
+            {
+                McpLog.Warn($"[WebSocket] Base URL host '{host}' is bind-only; using 'localhost' for client connection.");
+                host = "localhost";
+            }
</code_context>

<issue_to_address>
**suggestion:** Warning log on bind-only host might be too noisy for common configurations

Since `0.0.0.0`/`::` is a very common bind address, this warning will fire on every WebSocket connection and clutter logs, even though the situation is handled by remapping to `localhost`. Consider reducing it to info/debug level, or ensuring it only logs once (e.g., per process or per URL) instead of per connection.
</issue_to_address>

### Comment 2
<location> `tools/update_fork.sh:5-6` </location>
<code_context>
+git checkout main
+if errorlevel 1 exit /b 1
+
+git fetch -ap upstream
+if errorlevel 1 exit /b 1
+
+git fetch -ap
+if errorlevel 1 exit /b 1
+
</code_context>

<issue_to_address>
**suggestion (performance):** Avoid redundant fetch/prune operations in update script

Running `git fetch -ap upstream` followed by `git fetch -ap` performs two full fetch/prune cycles. One `git fetch -ap` is enough to update and prune all remotes (including `upstream`), or you can just fetch `upstream` if that’s the only remote needed here.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

suggestion: Warning log on bind-only host might be too noisy for common configurations

Since 0.0.0.0/:: is a very common bind address, this warning will fire on every WebSocket connection and clutter logs, even though the situation is handled by remapping to localhost. Consider reducing it to info/debug level, or ensuring it only logs once (e.g., per process or per URL) instead of per connection.

[sourcery-ai]

suggestion (performance): Avoid redundant fetch/prune operations in update script

Running git fetch -ap upstream followed by git fetch -ap performs two full fetch/prune cycles. One git fetch -ap is enough to update and prune all remotes (including upstream), or you can just fetch upstream if that’s the only remote needed here.