Two logistics agents both need shipment status, reroute, and proof-of-delivery actions. The platform team can publish those actions once on a Model Context Protocol server. Each agent team would rather paste its own copy of the API logic. What should the architect require?
Select an answer to reveal the explanation.
Short Explanation
Two kitchens should not each hide a private copy of the same recipe. You publish one Model Context Protocol server for the shipment tools and you have both agents call it. A private copy in each agent will drift as soon as one team changes a field.
Full Explanation
When two agents need the same shipment tools, one Model Context Protocol server is the shared tool surface, and each agent calls that server instead of embedding a private copy of the API logic. Status, reroute, and proof of delivery are published once. A private copy of the API logic inside each agent, with each team maintaining its own shipment calls, will diverge the moment one team changes a field the other team does not. Computer Use on the carrier website for both agents, leaving the shared shipment actions unpublished, drives a screen even though the actions can be published as tools. A custom model that memorizes last week's statuses and takes the place of the shipment tools replaces a live call with a stale memory and cannot reroute anything current. The server is the shared contract. The agents do not each own a private implementation of it. Exam caveat: both agents call the same server, and each agent still receives only the tools that agent is allowed to use. Sharing a server is not sharing every permission. Operational check: change one field in the shared tool, then call it from both agents and confirm both see the change without a second code paste.