A company already exposes REST APIs for everything. Make the case for adding a standard tool-integration protocol on top, and then argue the other side.

1. Frame the combinatorial problem: N applications integrating M services means N×M bespoke integrations, each with its own auth, schema translation, and error handling. 2. Reduce it to N+M: services expose one protocol-conformant interface, clients speak that one protocol, and each side is written once. 3. Name what the protocol standardises that REST deliberately does not — machine-readable capability discovery, a uniform tool-and-argument schema, and consistent result and error shapes an autonomous caller can consume. 4. Point out the real gap: REST assumes a developer reads docs and writes a client, while an agent must discover and invoke at runtime with no such step. 5. Add the operational benefit: a new client gains every existing integration for free, and a new service becomes available to every existing client. 6. Argue the other side honestly — the protocol is another layer to run and secure, it can be thinner than the underlying API's real capabilities, the ecosystem is young, and a well-documented OpenAPI spec plus a generator covers many cases. 7. Set the decision rule: worth it when the number of client-service pairs is genuinely growing and callers are autonomous; not worth it for one client and two services. 8. Flag the security surface it creates — a broker holding credentials for many services and executing tool calls on behalf of a model is a high-value target and needs per-tool authorization.