Why we're looking at this
Before MCP, every agent integration with an internal system was a bespoke function-calling schema, hand-maintained per project. We've built enough of these one-off integrations to know how much duplicated effort that creates. MCP standardizes the interface between an agent and a tool, and we now treat MCP server creation as a core service line — see our write-up on MCP and AI agents for the mechanics.
What we're seeing
- Clients who expose their internal systems as MCP servers once can reuse that surface across multiple agents and tools — Claude, internal automations, even other vendors' agents — instead of rebuilding the integration each time.
- The protocol's discovery mechanism (agents can inspect what a server offers before calling it) meaningfully reduces the prompt-engineering overhead of describing every tool by hand.
- Our engagement with Upfreq Robotics is a direct example: exposing their simulation and testing infrastructure as an MCP server means their own AI Robotics Testing Engineer, and any future agent they build, can call it the same way.
Open questions we're still chasing
Versioning and backward compatibility for MCP servers as they evolve is still an open design problem industry-wide. We're erring toward small, single-purpose servers over large monolithic ones, for the same reasons that pattern won out in traditional API design.