Install Arbor for Graph-Native MCP Code Analysis

What Arbor does and where Localtonet fits

Arbor analyzes source code as a graph rather than treating an entire repository as an unstructured collection of text. Its graph can represent program entities such as functions, classes, and modules as nodes, with calls, imports, and other relationships represented as edges. This structure supports questions that depend on relationships between symbols, including which functions call a symbol, which code can be reached transitively, and which parts of a repository may be affected by a change.

The distinction matters when an engineer or coding assistant needs structural context. A text search can find a matching name, but a graph can describe how identified symbols are connected. Arbor exposes this functionality through its command-line interface and through an MCP bridge that can be connected to a compatible coding assistant.

Arbor's default MCP workflow uses standard input and output, commonly called stdio. In that mode, the MCP client starts the local arbor bridge process and communicates with it directly. No network listener is required, so a Localtonet tunnel is unnecessary for a normal same-device stdio configuration.

Remote access becomes relevant only when Arbor is deliberately started with its optional HTTP transport. The documented command arbor bridge --http --port 3333 starts that mode on port 3333. Once the HTTP service is working on the same device as our client, a Localtonet HTTP tunnel can forward a public HTTPS address to the local listener. The Localtonet client creates an outbound connection to our relay infrastructure, so the workflow does not require inbound router port forwarding, firewall changes, a VPN, or a public IP address.

Prerequisites and decisions to make first

The documented installation command uses Cargo, the Rust package manager. You therefore need a working Rust toolchain that includes Cargo. The available Arbor evidence does not state a minimum supported Rust version, so this guide does not invent one. If installation fails because your compiler is too old, update through the method used to manage Rust on your system and retry.

You also need a local source repository that you are permitted to analyze. Run Arbor's setup command from the repository you intend to index, not from an unrelated home or downloads directory. If the repository contains confidential code, review how every connected coding assistant or remote consumer handles project information before giving it access.

For local command-line analysis, no listening port is needed. For a same-device MCP integration, use stdio unless your MCP client specifically requires an HTTP endpoint. For remote HTTP access, install the Localtonet client on the same device that runs Arbor. Keeping both processes on one device allows the tunnel target to remain local instead of exposing Arbor directly on the LAN.

Confirm Cargo is available

Open a terminal and run:

cargo --version

A version response confirms that the shell can find Cargo. If the shell says that the command is missing, install a current Rust toolchain using the official method appropriate for your operating system, then open a new terminal so that environment changes take effect.

Choose the MCP transport deliberately

The transport determines whether networking is involved. Stdio is process-local and is the simplest choice when supported. HTTP creates a listening service and therefore requires additional decisions about binding, authentication, remote reachability, and service lifetime.

Install the Arbor CLI with Cargo

Arbor's documented package installation uses the package name arbor-graph-cli. Cargo downloads and builds the package, then places its executable in Cargo's configured binary directory.

cargo install arbor-graph-cli

Do not substitute an unverified package name or download command. The package name and executable name are different in this workflow: Cargo installs arbor-graph-cli, while the commands shown in Arbor's documentation use the arbor executable.

A Cargo installation compiles software locally, so completion time depends on the machine and whether dependencies are already cached. Compiler output is not itself an error. Look for the final success or failure result rather than interpreting normal build messages as a problem.

Initialize Arbor in the repository you want to analyze

Installing the binary and preparing a repository are separate operations. Installation makes the command available. Project setup allows Arbor to initialize its analysis for the current codebase.

Change into the root directory of the repository you want Arbor to inspect. The exact directory is specific to your machine, so replace the placeholder below with the real repository path:

cd /path/to/your/repository
arbor setup

The available evidence does not provide a definitive list of all supported programming languages, generated-file rules, ignore patterns, setup prompts, or files created by arbor setup. Observe the output from the installed version instead of assuming that behavior from an older release or another project. If your repository uses an unusual language or build layout, verify the resulting graph with known symbols before relying on broad impact conclusions.

Verify Arbor locally before adding MCP or remote access

Always verify the smallest local workflow first. This separates installation and indexing problems from MCP client configuration, HTTP transport, and tunnel configuration. If a local query fails, adding a public URL will not fix the underlying graph.

Arbor documents a callers query in this form:

arbor callers your_function

Replace your_function with a real function name from the repository you initialized. Pick a symbol whose callers you already understand. A familiar symbol gives you a practical baseline for deciding whether the graph appears plausible.

How to interpret the result

Check whether the command identifies expected direct or indirect callers, depending on the output and query behavior of the installed release. If an expected relationship is absent, inspect whether the call is dynamic, reflective, generated, or otherwise difficult to infer statically. If unrelated symbols with the same name appear, inspect module and import context instead of assuming that every name match refers to the same definition.

Arbor's recent graph work distinguishes resolution confidence and explicitly acknowledges ambiguity. In version 3.0.0, import context was added to improve the selection of the correct symbol when identical bare names occur in different modules. A written import can provide stronger evidence than directory adjacency, while a local definition can still shadow an import. This improves an important class of resolution, but it does not eliminate all ambiguity.

Arbor also documents known limitations. Dynamic and reflective imports cannot always be resolved by construction. The available release evidence states that inheritance relationships are not represented as edges in the discussed version, so changing a base class can produce an incomplete blast-radius result. Small targets can also be over-reported. These limitations are reasons to inspect and test, not reasons to discard the graph entirely.

A practical verification checklist

• Run the query from the repository that was initialized with arbor setup.
• Use a real, known symbol rather than leaving your_function unchanged.
• Compare the result with at least one relationship you can verify directly in source code.
• Check imports and module context when multiple symbols share the same name.
• Expect gaps around dynamic loading, reflection, generated behavior, and unsupported relationships.
• Use automated tests and runtime checks before treating an impact result as a release decision.

Configure Arbor as a local MCP server

If command-line analysis works, the next optional step is connecting Arbor to an MCP-compatible coding assistant. The default command is:

arbor bridge

This default bridge uses stdio. The MCP client starts Arbor as a child process and communicates through the process streams. Because no public endpoint is created, this is generally the better starting point for a coding assistant running on the same machine.

Claude Code project-scoped configuration

Arbor documents the following command for adding the stdio bridge to Claude Code at project scope:

claude mcp add --transport stdio --scope project arbor -- arbor bridge
claude mcp list

The first command registers Arbor as a project-scoped MCP server. The second lists configured MCP servers so you can confirm that the entry is present. Within Claude Code, Arbor's documentation also directs users to run /mcp to inspect MCP connectivity.

Cursor configuration

For Cursor, the documented project configuration uses .cursor/mcp.json:

{
  "mcpServers": {
    "arbor": {
      "command": "arbor",
      "args": ["bridge"]
    }
  }
}

The MCP client must be able to find the arbor executable. A common source of failure is launching a graphical application with a different PATH from the terminal where Cargo works. If that happens, fix the application's executable environment using a path appropriate to your own Rust installation. Do not copy a path from another operating system or user account.

VS Code configuration

Arbor documents this project configuration in .vscode/mcp.json:

{
  "servers": {
    "arbor": {
      "type": "stdio",
      "command": "arbor",
      "args": ["bridge"]
    }
  },
  "inputs": []
}

These examples use local stdio transport. They do not require port 3333, a Localtonet tunnel, or a public URL. Keep the configuration simple unless the MCP consumer is genuinely remote or specifically requires HTTP.

Start Arbor's optional HTTP MCP server

Arbor's documented HTTP example starts the bridge on port 3333:

arbor bridge --http --port 3333

Run this command from the prepared project context and keep the process running. Closing the terminal, interrupting the command, logging out in a way that terminates the process, or stopping the service will make the HTTP endpoint unavailable.

The supplied Arbor evidence establishes the HTTP mode and port but does not establish a specific MCP URL path, root-page response, health-check route, authentication option, TLS option, or expected response body. For that reason, this guide does not invent a path such as /mcp, /health, or /sse. Use the startup output from the installed release and the HTTP transport settings expected by your MCP client.

A browser request to the port is not always a complete MCP verification. MCP clients may use specific methods, headers, sessions, or streaming behavior. A plain browser page can be empty or return an error even while the intended protocol endpoint works. The most reliable test is an MCP-compatible client configured with the exact endpoint reported by Arbor.

Expose the working Arbor HTTP service with Localtonet

Add Localtonet only after the HTTP bridge works locally. Our client runs on the device that can reach Arbor and creates an outbound connection to a Localtonet relay server. The resulting HTTP tunnel provides a public HTTPS address and forwards requests to the selected local IP address and port.

This removes the need for inbound router port forwarding, firewall changes, VPN setup, or a public IP address. It does not add missing application authentication to Arbor, validate MCP requests, or decide who should have access. Connectivity and authorization remain separate concerns.

For current dashboard details, consult our Localtonet HTTP tunnel documentation. Exact client installation commands, relay availability, custom-domain DNS requirements, and account-specific options can change, so check the current dashboard rather than relying on guessed values.

Understand the complete request path

In the same-device configuration, a remote MCP request reaches the assigned Localtonet public HTTPS address. Our relay forwards it through the outbound client connection to Arbor's local HTTP listener on port 3333. Arbor processes the MCP request using the repository context prepared on that device.

If the public address works while the Localtonet client, tunnel, and Arbor process are active but stops later, verify all three lifecycle states. A tunnel cannot reach a process that has exited, and a running Arbor process is not remotely reachable through a stopped tunnel.

HTTP tunnel process types

All three HTTP process types serve the configured local content at a public HTTPS address. They do not change Arbor's graph, MCP protocol behavior, repository permissions, or application-level authorization.

Troubleshooting installation, analysis, MCP, and tunnel problems

Cargo is not recognized

If cargo --version fails, the Rust toolchain is either missing or its binary directory is not available to the current shell. Install or repair Rust using the official toolchain method for your operating system, then open a new terminal. Avoid guessing a fixed Cargo binary path because it can differ by operating system, user, and installation method.

Cargo fails while building Arbor

Read the first relevant compiler or dependency error rather than only the final failure line. Confirm that the Rust toolchain is current, that the machine can download package dependencies, and that the user has permission to write to Cargo's installation directories. The evidence does not specify a minimum Rust version or a complete list of native build dependencies, so use the actual error from the installed environment to guide remediation.

The installation succeeds but arbor is not found

Cargo can install a binary successfully while the shell cannot locate it. Reopen the terminal and check the PATH associated with the same user who ran Cargo. Graphical MCP clients may inherit a different environment from interactive shells, so success in a terminal does not guarantee that Cursor or VS Code can find the executable.

Setup analyzed the wrong directory

Stop and return to the intended repository root before running arbor setup. Do not assume that changing directories later automatically transfers project context. Verify the current directory and repeat the documented setup operation for the correct repository if necessary.

A known caller is missing

Inspect the source relationship. Dynamic imports, reflection, generated code, untyped receiver calls, language features, or incomplete indexing may prevent a static edge from being created. Inheritance is also a documented gap in the supplied release information. Confirm important relationships using source review and tests.

The callers result points to the wrong same-named symbol

Confirm the Arbor version and inspect the importing file. Version 3.0.0 specifically improved resolution when bare names collide across modules by consulting import context before falling back to same-directory proximity. Existing cached graphs, stored node identifiers, and centrality baselines from older releases can differ after this correction, so compare results carefully after upgrading.

The HTTP bridge reports that port 3333 is unavailable

Another process may already be listening on that port, or an earlier Arbor process may still be running. Stop the conflicting process if appropriate. Arbor allows a port to be selected with --port, but if you choose a different value, use exactly the same port as the Localtonet tunnel target. Do not expose an unrelated service accidentally.

The port responds, but the MCP client does not connect

Confirm that the client supports Arbor's HTTP MCP transport and that it is using the correct endpoint path, request method, and protocol behavior. The available evidence does not establish a universal path, so pointing a client at the server root may be insufficient. Review Arbor's startup output and the client's HTTP MCP requirements.

The local endpoint works, but the public endpoint does not

• Confirm that the Arbor HTTP process is still running.
• Confirm that Arbor is reachable from the same device as the Localtonet client.
• Check that the HTTP tunnel targets the correct local IP address and port 3333, or the alternative port you deliberately selected.
• Confirm that the selected Localtonet device is connected.
• Confirm that the tunnel was started, not merely created.
• Use the current assigned public address rather than an old or deleted tunnel address.
• Preserve any endpoint path required by Arbor when forming the public MCP URL.

The public endpoint stopped working later

Check the lifecycle from the inside out. First verify Arbor, then the local HTTP listener, then the Localtonet client, then the tunnel state. Localtonet tunnels are available only while the selected client or device is connected and the tunnel is running. Restarting one component does not automatically prove that every other component is active.

The graph result looks unexpectedly risky or unexpectedly safe

Treat both extremes as prompts for investigation. Small targets can be over-reported, while missing static relationships can under-report impact. Centrality and blast radius describe the analyzed graph, not every possible runtime execution. Inspect the paths, compare them with imports and calls in source, and run the repository's test suite before making a release decision.

Routine operation and safe shutdown

A reliable workflow keeps repository analysis, the Arbor service, and the Localtonet tunnel as distinct layers. This makes failures easier to diagnose and reduces accidental exposure.

1. Open the intended repository and verify that Arbor's project setup is valid.
2. Run a known local query when you need to confirm graph behavior.
3. Use arbor bridge for a local stdio MCP client.
4. Use arbor bridge --http --port 3333 only when HTTP transport is required.
5. Start the Localtonet HTTP tunnel only after the local listener is healthy.
6. Test the remote client with a low-risk query.
7. Stop or delete the tunnel when remote access is no longer required.
8. Stop the Arbor HTTP process when no HTTP consumers need it.

When upgrading Arbor, repeat local verification against symbols whose relationships are already understood. Graph corrections can move edges to different nodes, change stored node identifiers, and alter centrality or blast-radius results. A changed result is not automatically a regression, especially when an earlier release resolved a symbol incorrectly.

If Arbor or its tunnel must run unattended, use a service-management method appropriate to your operating system. The supplied evidence does not define an official Arbor service unit, startup task, background flag, or process supervisor configuration, so this guide does not invent one. Whatever manager you choose should run Arbor in the correct repository context, expose only the intended port, preserve logs needed for diagnosis, and stop cleanly.

Frequently asked questions