How J.W. Pepper centralized MCP tools without slowing teams down

Interest in AI agents at J.W. Pepper did not begin as a centralized IT initiative. Teams across the business were experimenting with MCP to move faster, often before formal guardrails were in place. As Marcus Dubreuil, Director of Systems Architecture, explained, “people outside of the IT department, perhaps with a little bit less governance, were moving faster than we were within IT and actually creating these useful AI agents.”

What started as exploration quickly changed the nature of IT requests. “What used to be ‘this service has an API, can we integrate it?’ turned into ‘this service has MCP,’” Marcus said. That shift made it clear that MCP was not just another integration pattern. It was a new access layer that could touch real systems across the business.

As MCP usage spread, J.W. Pepper began to see risks that felt familiar from earlier waves of shadow IT. MCP tools often inherited the full permissions of the user running them, without clear ownership or visibility. “One of the challenges with how MCP works that I learned really quickly is that it effectively forwards any access control that the user has to the AI agent,” Marcus noted. “You’re effectively saying, ‘you’re me now.’”

For an organization with established security and integration standards, that model did not scale.

Rather than exposing large numbers of raw MCP tools directly to agents, J.W. Pepper focused on introducing more structure. The team began shifting toward smaller, purpose-built workflows that represented specific business actions. “Instead of trying to give the agent 500 different MCP tools and saying ‘good luck,’ we shifted to fine-tuned workflows that represent specific actions like looking up an order or updating a ticket,” Marcus explained.

This approach reduced risk while making agents more reliable. “Any AI agent is not going to know as much as you do about the company,” Marcus said. “Even if it has access to systems, it doesn’t know how to use them.” Encoding business logic into workflows helped close that gap without relying entirely on prompting.

Centralizing MCP with Agent Gateway

To support this shift, J.W. Pepper centralized its MCP servers and tools using Tray Agent Gateway. This allowed IT to control which tools were available, how they were exposed, and under what conditions they could be used. Over time, Marcus began to see these workflows as building blocks for agent access.

By centralizing MCP in a managed environment, the team could scale usage while maintaining visibility and control, rather than reacting to issues after the fact.

Adoption was also a key consideration. At J.W. Pepper, most employees were already using Microsoft Copilot, and the team wanted to avoid introducing yet another interface. “One of the beautiful things about Agent Gateway is that we can meet our employees back where they already were, which for us is Microsoft Copilot,” Marcus said.

At the same time, access remained intentional. “We’re not even giving users the option to turn everything on,” he explained. “We opt tools in. We restrict them to reads where that makes sense.” This balance helped employees get value from MCP while keeping sensitive systems protected.

With Agent Gateway in place, J.W. Pepper now has a repeatable model for MCP adoption that aligns with enterprise expectations. Governance no longer feels like a blocker to progress. “We’ve removed a lot of risk,” Marcus said. “There’s governance around that now.”

For the IT team, the shift has also changed how they engage with the business. “We’re becoming more of a service org again,” Marcus noted, “helping people empower their use of AI instead of being fearful of it.” MCP is no longer just an experiment at J.W. Pepper. It is part of a governed foundation for how agents interact with the company’s systems.

Watch how J.W. Pepper builds and manages MCP with Agent Gateway