Cowork: connected local MCP server's tools missing from tool-discovery on first turn (search-before-connect race); agent then wrongly reports the connector 'not installed'

## What happened?

In Claude Cowork (Claude Desktop local agent mode), a **connected, installed, and enabled local (stdio) MCP server's tools are not in the agent's tool-discovery set on the first turn of a fresh chat** — and the agent then *wrongly concludes the connector isn't installed*.

Concretely, in a fresh chat the agent's deferred-tool search returns `No matching deferred tools found` for **every** query — the server's display name **and exact tool-name keywords** — even though the connector is installed and toggled on. The agent then searches the public MCP *install registry* (for connectors to add), finds only unrelated entries, and reports something like *"there's no connector available — it isn't a supported integration."*

The server's tools (`mcp____*`) **do** appear, and work, on a **subsequent** turn — they show up in the agent's system context once the server finishes connecting. The agent's own self-diagnosis matched this: its tool-search only returns *already-registered* deferred tools, and the server was still connecting when it searched.

There are two compounding problems:
1. **Search-before-connect race:** a freshly-spawned MCP server's tools are not in the searchable tool set when the agent runs its first discovery search; they register a moment later (next turn).
2. **Faulty fallback:** an empty tool-search is interpreted as *"no connector installed → search the install registry,"* instead of *"a connected server may still be initializing → wait/retry / check connected servers."* This sends the user down a dead end and produces a confidently-wrong "not installed" conclusion.

## What did you expect to happen?

- The agent's tool set should be populated with a connected server's tools before (or its first search should account for the server still initializing), so a first-turn request can use them; **and**
- An empty deferred-tool search should **not** be treated as "no connector installed." When a connector is connected/enabled but its tools aren't yet searchable, the agent should wait for connection / re-check connected servers — not pivot to the public install registry and declare the integration unsupported.

## Steps to reproduce

1. Install and **enable** a local **stdio** MCP server in Claude Cowork/Desktop (reproduced with a binary server installed as a `.mcpb` extension).
2. Open a **fresh** chat.
3. As the **first** message, ask the agent to use the connector (e.g. *"List my items using the installed connector — don't search the registry."*).
4. Observe: the agent's tool-discovery search returns `No matching deferred tools found` for the server name **and** for exact tool-name keywords; it then searches the MCP registry and reports the connector isn't available / not supported.
5. Send any **second** message. The `mcp____*` tools are now present in context and work normally.

Reliable workaround: a throwaway first turn (to let the server finish connecting), **then** the real request — the tools are loaded by the second turn.

## Area

Tool discovery / connected-server initialization (cold-start race), plus agent fallback reasoning (empty tool-search → wrongly inferring "not installed").

## MCP Server (if applicable)

A custom local **stdio** server (self-built binary), installed via `.mcpb`. The server is healthy — its own log shows a successful `initialize` + full `tools/list` response shortly after spawn — so this is a client-side discovery/timing issue, not a server fault.

## Error messages or logs

Deferred-tool search responses on the first turn (all of these returned nothing, despite the connector being installed + enabled):

```
query "" -> No matching deferred tools found
query "" -> No matching deferred tools found
query "" -> No matching deferred tools found
query "" -> No matching deferred tools found
```

Server-side log (same server, moments later) shows it connected and served its tools fine:

```
[] Server started and connected successfully
[] Message from client: {"method":"initialize",...}
[] Message from server: {... "serverInfo":{"name":"",...}}
[] Message from client: {"method":"tools/list",...}
[] Message from server: {... full tools list ...}
```

## Additional context

The tools are correctly namespaced by the client as `mcp____*` once they appear, so this is purely a *timing/availability* gap in the agent's searchable tool set on the first turn, compounded by the "empty search ⇒ not installed ⇒ search the install registry" fallback. The net user experience is that a perfectly-configured local connector looks broken/unsupported on first use, until a warm-up turn passes.