BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//programme.europython.eu//europython-2026//talk//BJBKRM
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-europython-2026-BJBKRM@programme.europython.eu
DTSTART;TZID=CET:20260717T122500
DTEND;TZID=CET:20260717T125500
DESCRIPTION:After months of maintaining the MCP Python SDK and reviewing ma
 ny community contributions\, I've seen some architectural hiccups in repea
 t. Developers struggle with questions that seem simple but have nuanced an
 swers: When should one tool become three? When does a server need to split
  into two? How do you test an MCP server without spinning up a full client
 ? When should you use resources or prompts instead?\n\nIn this talk\, we w
 ill explore my learnings and understand how to design tool boundaries that
  scale with your server's complexity\, structure your codebase for long-te
 rm maintainability\, and build a testing strategy for your MCP server that
  works. I'll share real examples from the wild\, both the antipatterns to 
 run away from and the implementations worth adopting.\n\nIn 2026\, the MCP
  Python SDK v2 will bring improved typing\, a refined API\, and better tes
 ting primitives. The architectural decisions you make today will determine
  whether that migration takes a day or a month.\n\nWhether you're maintain
 ing an internal tool or publishing to the community\, you'll leave with a 
 clear framework for evaluating your own server's design and concrete next 
 steps to improve it.
DTSTAMP:20260524T130554Z
LOCATION:Conference Hall Complex (S4)
SUMMARY:What I've Learned Maintaining the MCP Python SDK - Marcelo Trylesin
 ski
URL:https://programme.europython.eu/europython-2026/talk/BJBKRM/
END:VEVENT
END:VCALENDAR