What discovery replaces
In a traditional integration, someone writes code for each supported action. Adding a capability means a development cycle on both sides.
With discovery the capability list is data. Publish a new tool and the agent can use it in the next conversation.
The selection process, step by step
- The client connects and requests the tool catalog.
- The model reads names, descriptions and schemas.
- The user's request is matched against those descriptions.
- Arguments are extracted from the conversation and prior tool results.
- The call is made; the result feeds the next decision.
Why descriptions decide accuracy
The model has no other information about your system. Two tools described as 'update a record' are indistinguishable; 'reschedule an existing appointment to a new time slot' and 'change the assigned technician on an appointment' are not.
Stating what a tool must not be used for is as valuable as stating what it does.
Chaining discovered tools
Real requests span several tools: find the customer, list their open jobs, create an invoice, send it. The output of one call becomes the input of the next.
This is only reliable when tools return canonical identifiers rather than display names.
What discovery does not grant
Discovery reveals capability, not permission. A tool can appear in the catalog and still be refused at call time because the session lacks the required scope. Visibility and authorisation are separate layers.