Shrutam CCA-F Crash › Domain 2 › d2-l04-service-mesh-gateway English Hinglish →

Tool Boundary Discipline — Why Tools Shouldn't Reason

Domain 2 · 20% ~12 min English narration

Scenario anchor

Aap Aaranya IT BFSI ke ek large-scale Claude deployment mein tool layer design kar rahe hain — trade reconciliation ke liye ek "fetch_position" tool hai jo ASX-India ke downstream APIs se connect karta hai. Suddenly production mein inconsistent results aa rahe hain: tool kabhi stale data return karta hai, kabhi retry logic khud decide karta hai, aur kabhi business rules apply karke filtered output deta hai. Yeh lesson resolve karega ki tool ka kaam sirf structured execution hai — reasoning, retry arbitration, aur business logic Claude ke context window mein rehni chahiye, tool ke andar nahin.

Key Takeaways

A tool is a deterministic execution boundary — it calls, transforms, and returns structured data; all conditional logic and decision-making stays in Claude's context window.
Tool schemas act as the service-mesh gateway contract: inputs and outputs must be fully specified via JSON schema so Claude can validate before dispatch and after response, not inside the tool itself.
Side effects (writes, state mutations, downstream triggers) must be explicit in the tool's schema declaration — undeclared side effects break Claude's ability to reason about idempotency and rollback.
Memory anchor: treat every MCP tool like an Envoy sidecar proxy — it routes and enforces the contract, but policy decisions live in the control plane, which is Claude.

← Previous lesson Same lesson in Hinglish Next lesson → Back to overview