A text reply shows that the chat connection works. It does not establish whether the same deployment can call a tool and return a response in the required shape. List those requirements before comparing providers.
For an assistant that checks an order and returns a typed resolution, write down the checks:
| Capability | Requirement | Check on the candidate deployment |
|---|---|---|
Call GetOrderStatus | Required | Send a representative request. Confirm the tool call, supply a test result, and check that the model uses it. |
| Return a schema-constrained resolution | Required | Send the tool result with the real response schema and validate the final response. |
| Stream partial text | Optional | Buffer the complete response if streaming is unavailable. |
Use the model catalog to narrow the list. Test the required capabilities together on the model version, deployment, API path, and integration you plan to ship. Record what passed and repeat the test when one part changes. Then compare quality, latency, cost, and operational fit.
If the tool call works but schema output fails after you supply the result, the candidate does not meet the feature contract. Reject it or change the contract deliberately. Prompting for JSON is not an equivalent substitute for schema-constrained output. The application still needs to validate business values.
For one feature and a few candidates, keep this table with the deployment check results. The provider-independence article shows how to carry a qualified capability declaration into a .NET application after selection.