---
title: "Comment by Ahmet Özel on \"Connecting existing systems to AI agents with MCP: 3 strategies we run in production\" | Hashnode"
description: "For the error contract, isError should identify a failed tool execution without being treated as a universal instruction to retry. A missing required business v"
url: "https://hashnode.com/posts/connecting-existing-systems-to-ai-agents-with-mcp-3-strategies-we-run-in-production/6aed0869a794997172473ca1/comment/6af1579f54093141ee1cb0c6"
---

[Discussion](https://hashnode.com/posts/connecting-existing-systems-to-ai-agents-with-mcp-3-strategies-we-run-in-production/6aed0869a794997172473ca1)

Comment [Connecting existing systems to AI agents with MCP: 3 strategies we run in production](https://hashnode.com/posts/connecting-existing-systems-to-ai-agents-with-mcp-3-strategies-we-run-in-production/6aed0869a794997172473ca1)

[Ahmet Özel](https://hashnode.com/@ahmetozel)

[4d ago](https://hashnode.com/posts/connecting-existing-systems-to-ai-agents-with-mcp-3-strategies-we-run-in-production/6aed0869a794997172473ca1/comment/6af1579f54093141ee1cb0c6)

For the error contract, isError should identify a failed tool execution without being treated as a universal instruction to retry. A missing required business value, an upstream outage, and a terminal business rejection need different next steps even when all arrive as tool errors.

I would return a stable error category and an explicit recovery hint, then test that the client changes arguments only for correctable input failures and does not keep reissuing a terminal rejection. That preserves the useful self-correction path you describe while keeping recoverability a property of the actual failure, rather than of the flag alone.