An MCP client discovers available tools during the initial handshake when it connects to the MCP server. As soon as the connection is established, the server sends a structured message describing all available tools, including their names, descriptions, and schemas. This is known as the “tool list” or “capabilities” discovery phase. The model then parses this metadata to understand what actions it can perform, which tools accept what inputs, and how the results of each tool call will be formatted. This ensures that tool discovery is automated rather than relying on hardcoded knowledge.
The discovery process is dynamic, meaning the server can add or remove tools at runtime and notify the client through events or capability updates. For example, if a vector indexing service comes online, the server may expose a new tool like “create_index.” If an embedding model is temporarily offline, the server can disable or hide the corresponding tool. The client always works with the current set of valid capabilities, which prevents reasoning based on outdated assumptions.
In vector databases like Milvus, this discovery mechanism is extremely useful because the available operations may depend on system state or current indexing configuration. A model can discover tools such as “milvus_search,” “milvus_insert,” or “milvus_compact” and reason about which actions are possible based on the schema descriptions. This eliminates guesswork and ensures that retrieval workflows remain aligned with the actual capabilities of the vector infrastructure exposed through MCP.