Hard20 minAI Engineering
UpdatedAug 6, 2026
Edit

MCP: Evolving a Tool Contract

Question Variations

  • "When should a tool name change rather than its schema?"
  • "How do you safely make a field required?"
  • "How would you add a required project field to `create_ticket` while older MCP clients remain deployed?"

Why This Is Asked

This tests whether a candidate can evolve a tool contract without breaking independently deployed clients. Interviewers assess additive schema design, explicit version boundaries, server validation, and telemetry-led deprecation.

Key Concepts

  • Additive change: New optional fields and safe defaults preserve older clients.
  • Versioning: Breaking input changes require a new tool or negotiated version.
  • Schemas: Validate inputs and outputs at the server boundary.
  • Telemetry: Measure old contract use before deprecation.

Question Variations

  • “When should a tool name change rather than its schema?”
  • “How do you safely make a field required?”
  • “How would you add a required project field to create_ticket while older MCP clients remain deployed?”

Answers by Technology

+ Add Variant
System DesignImprove this answer ✏️

Expected Answer

I evolve tools additively where possible: optional fields and safe defaults preserve existing clients. If a new project field changes semantics and must be required, I expose a new versioned tool, support both versions during migration, validate at the server, and use telemetry to retire the old one. Silent meaning changes are worse than an explicit break.

Why It Matters

Tool clients update independently and a breaking schema can halt automated work.

Common Mistakes

  • Making an old field required: Existing clients fail immediately.
  • Changing a field’s meaning: Silent incorrect actions are worse than an error.

Follow-up Questions

  • When add a tool? (Answer: When compatibility cannot be preserved.)
  • How is retirement safe? (Answer: Observe remaining version usage.)