Put the MCP tool discovery and invocation steps in the correct order

**MCP** tool use follows one strict rule: you discover before you call. The model can only call a tool it already knows about, so the host has to fetch the menu first. The flow starts after the connection handshake. The host sends `tools/list` to the server. The server replies with an array of tools, each carrying a `name`, a `description`, and an `inputSchema` that spells out the arguments. The host then injects those tool descriptions into the LLM's context, usually as function-calling definitions. Now the model can see what is available. It decides a tool is needed and emits a structured request naming the tool and its arguments. The host turns that into a `tools/call` message and sends it to the server. The server runs the tool and returns a `content` array with the result, plus an optional `isError: true` flag if something went wrong. The model reads that result and continues.

The order is discovery first, invocation second. After the `initialize` handshake and capability negotiation, the host calls `tools/list`. The server returns an array of tool objects. Each carries a `name`, a `description`, and an `inputSchema` in JSON Schema form. The host injects those descriptions into the model's context as tool definitions. Now the model can act. It reads the available tools and decides one is needed. It emits a structured function-call request naming the tool and its arguments. The host receives that, maps it back to the owning server, and sends `tools/call` with the name and arguments over JSON-RPC. The server executes and returns a `content` array, optionally flagged with `isError: true`. The host feeds that result back into the next model turn. The key insight: the model never invokes a tool whose schema it has not seen. Discovery is what makes a valid call possible. Skip the list step and the model has no name to call and no schema to fill.