Mac mini 上的 Codex 刚写好一个功能，MacBook 上的 Claude 却不知道。

# Let Claude Code use an existing provider function

The user already has a working function on a provider such as a Mac mini and
wants Claude Code on their MacBook to reuse it. Do not install another model,
copy the provider's environment, or build a second implementation merely to
make this demonstration pass. Do not create a second device requirement when
the actual work is on one device.

This guide covers Claude Code's local stdio MCP connection, not claude.ai or
Claude Desktop. Official client setup reference:
https://code.claude.com/docs/en/mcp

## Establish the real function before changing client configuration

Ask for the provider's existing code or its version-matched function guide,
actual publication metadata, intended caller and approved test input. A proposed
JSON object with input_ref is not an implemented image reader. Confirm how the
provider reads the image and how the caller retrieves the output. A local
MacBook path does not name a file on the Mac mini.

Use an existing non-sensitive sample with a known local result. If the function
removes backgrounds, retain the original and its verified transparent PNG as
the comparison. Do not invent a successful image or install a new model without
approval. If no function or sample exists, report that missing prerequisite.

Confirm the provider Runtime and function are running and that the intended
caller is authorized. Do not borrow the provider's account or copy credentials.
Read installed CLI help. Publication, ability discovery and invocation are
separate checks; document each with actual results.

## Connect the MacBook client after approval

Run on the MacBook:

```bash
easynet mcp status
```

Inspect the status text: the current command may return exit 0 even when it
reports that the Runtime is not running. Do not treat exit status alone as
proof that tools can be served. Do not restart shared services automatically.

Read `claude mcp add --help`. In the project where the user wants this
connection, set EASYNET_CLI_PATH to the actual absolute installed CLI path.
Ask before adding client configuration. Check whether the name easynet is
already used, without dumping unrelated configuration or environment values.
If it exists, inspect that entry with the user's approval rather than replacing
it or adding duplicates. For a new approved entry:

```bash
claude mcp add --scope local --transport stdio easynet -- \
  "${EASYNET_CLI_PATH:?Set the actual absolute EasyNet CLI path}" mcp serve
```

This configures a local subprocess on the MacBook. It is not an HTTP endpoint
on the Mac mini. Remote execution still depends on EasyNet publication, routing
and authorization. The command writing a config entry is not a tool-call test.
Use Claude Code's `/mcp` UI to review connection status and the actual exposed
tools. Confirm client-specific permissions before running any tool or model.

The current EasyNet bridge constructs its tool list from a daemon catalogue
snapshot when the bridge starts. A list loaded before publication may be stale.
Reconnect this MCP entry with approval; do not restart the shared Runtime as a
shortcut. Do not assume a newly published remote ability appears automatically
as a direct tool. Inspect what this client actually sees and how that tool
routes to the intended provider. In the inspected source, EasyRemote publishes
on the provider locally, whereas the MCP bridge reads the consumer's local
host catalogue. Remote publication does not automatically add a direct MCP
tool. `learn`/`acquire` imports declarations, not an executable remote proxy;
do not offer it as a fix. A catalogue entry alone can lack a runtime binding.
Generic discovery can inspect advertised candidates but does not install them
as direct MCP tools. Verify the installed version's actual supported route;
if none exists, stop and report the missing integration. Do not invent tool
names or use a prompt to pretend the function is installed.

## Check three distinct outcomes

1. Tool visibility: record the actual tool name, description, input schema and
   identified provider or discovery route. Seeing an easynet server entry is
   not the same as seeing the required function. If it is absent, stop here and
   report publication/catalogue/refresh evidence without claiming discovery.
2. Explicit invocation: after authorization, call the observed interface once
   with the approved image. Obtain and inspect the actual output. Preserve a
   sanitized invocation reference when available. A success sentence or private
   provider path does not deliver an image to the MacBook.
3. Model selection: only after the first two pass and the user approves a model
   call, start a fresh task with the approved sample and ask for the image result
   without naming the tool. Observe whether Claude chooses the existing
   capability rather than rebuilding it. Do not preselect a tool and count that
   as autonomous discovery. No single trial guarantees future selection.

For the image example, a suitable request is: "Remove the background from the
approved product image I attached and give me a PNG with transparency. If the
required input or access is missing, tell me what you need before proceeding."
This is a proposed test prompt, not a record of a completed call.

Test a denied test identity and provider unavailability separately, with
approval. Stop only a demo process you own, not the user's shared Runtime.
No retries for unknown outcomes, no permission bypass and no fabricated output.

Report configuration written, bridge connected, target found, explicit call,
output retrieved, model selection and failure checks individually. This guide
does not claim these were already exercised on two real devices. If the exact
remote capability cannot be exposed through the installed MCP surface, report
the gap instead of silently replacing the task with a local copy.