Building APIs for Agents vs Systems. Is MCP the answer?

When your API consumer can reason, everything you thought you knew about the contract between provider and caller gets tested. I’ve spent the last 24 years of building and commercialising web APIs, including Cronofy’s MCP server and Agentic products. I've learned that the instinct to reach for new abstractions before honestly asking why the existing ones failed is as strong as ever. This talk covers the real differences between designing for developers and designing for agents, where MCP earns its place and where it's inefficient. Why granularity choices that work for systems fail for agents. The tension between agent flexibility and keeping your platform predictable, secure, and auditable. Where the responsibility for behaviour should fall. Practical learnings from really doing it. What I will share - How the contract between API provider and consumer shifts when the consumer is non-deterministic — retry logic, error handling, and authentication all need rethinking. - The practical differences between designing for developer experience (DX) versus agent experience (AX) — documentation, discoverability, and affordances. - Where MCP fits in the stack: what it actually solves (tool discovery, context passing, standardised transport) and what your tool should claim. - Lessons from shipping an MCP server commercially — the gap between the spec and production reality. - Why "just wrap your REST API" is a trap — granularity, composability, and the temptation to expose too many tools versus too few. - The tension between giving agents flexibility and maintaining predictable, billable, auditable behaviour for your business. - What stays the same: rate limiting, versioning, backward compatibility, and the fundamentals that 24 years of API design and delivery have already taught me.