hkalbert71

Thanks, that makes sense. Treating "can't tell" as an explicit outcome seems important, rather than counting an unconfirmed write as success.

Does that state get returned to the calling agent as structured output, or does it stay inside your repair workflow?

If it's exposed, trace-based diagnostics could distinguish verified writes, failed writes, and uncertain writes without assuming HTTP 200 means success.

One distinction worth measuring is transport success versus actual operation success.

A tool can return HTTP 200 while making no useful progress. The agent may then repeat the same call with identical arguments.

We're exploring this from an observability angle with KORA Doctor. It can flag repeated tool calls using privacy-preserving fingerprints, but it doesn't block live retries or determine whether caching is safe.

Do your generated MCP tools expose operation-level status or state-change evidence so external tools can distinguish a successful repair from another no-op retry?