BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//talks.devopsdays.org//halifax-2026//speaker//HKLEFS
BEGIN:VTIMEZONE
TZID:America/Halifax
BEGIN:DAYLIGHT
DTSTART:20250929T000000
TZNAME:ADT
TZOFFSETFROM:-0300
TZOFFSETTO:-0300
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20251102T020000
RDATE:20261101T020000
TZNAME:AST
TZOFFSETFROM:-0300
TZOFFSETTO:-0400
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20260308T030000
RDATE:20270314T030000
TZNAME:ADT
TZOFFSETFROM:-0400
TZOFFSETTO:-0300
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
SUMMARY:Design Principles: API vs MCP - RobBarnes
DTSTART;TZID=America/Halifax:20260929T093000
DTEND;TZID=America/Halifax:20260929T103000
DTSTAMP:20260922T222444Z
UID:pretalx-halifax-2026-HHRBLC@talks.devopsdays.org
DESCRIPTION:As adoption of the Model Context Protocol (MCP) accelerates\, 
 many teams are building MCP servers using familiar API design patterns - C
 RUD-style tools\, exposed resources\, and thin wrappers over existing APIs
 . While this approach can function\, it does not maximize the value MCP is
  designed to unlock. MCP is not an API replacement\; it introduces a diffe
 rent model built around capabilities\, constraints\, and agent-driven orch
 estration.\n\nThis talk explains why API-oriented designs limit MCP’s ef
 fectiveness\, even when they “work”. We’ll contrast traditional API 
 principles\, where deterministic clients orchestrate workflows with MCP de
 sign principles\, where autonomous agents reason over narrowly scoped capa
 bilities. Using vendor-neutral examples from deployment and operations wor
 kflows\, I’ll show how to design MCP tools that are minimal\, safe\, and
  agent-native\, and clarify when MCP provides more value than an API.
LOCATION:Volta HQ
URL:https://talks.devopsdays.org/halifax-2026/talk/HHRBLC/
END:VEVENT
END:VCALENDAR