Agents, APIs, and Advertising: Lessons from Engineering Our MCP Server (medium.com)

Criteo is building a public MCP (Model Context Protocol) server on top of its existing REST API so clients can manage advertising workflows directly through their LLM of choice — e.g., asking an agent to “create a full-funnel campaign” or fetch performance forecasts. They prototyped an “MCP OpenAPI proxy” (partly using the official C# SDK) that extracts OpenAPI operation descriptions and JSON schemas into MCP tools, and are exposing a subset of endpoints under a dedicated MCP API version while running a closed beta. The project highlights practical engineering trade-offs: MCP makes tools plug-and-play for LLMs (supporting local STDIO and remote HTTP streaming transports) but requires tool definitions to be unambiguous. Criteo adjusted docs, renamed operationIds, added sensible defaults, and hid irrelevant inputs to avoid overwhelming LLMs with large, noisy payloads — since models struggle with extraneous IDs and bulk data even as context windows grow. They also emphasize designing tools with LLM consumers in mind (small, composable primitives and JSON-only outputs where appropriate). Security and ecosystem fragmentation remain hurdles. MCP’s remote servers rely on OAuth2 PKCE and Dynamic Client Registration for client-to-server auth, which many clients implement variably; Criteo currently uses header-based auth while enabling parts of the OAuth metadata stack. Overall, the work shows how MCP can democratize ad ops but forces API teams to rethink schemas, docs, and auth for robust LLM-driven automation.