Skip to content

Give unknown MCP calls an explicit recovery path - #958

Draft
Y1fe1Zh0u wants to merge 2 commits into
dataelement:002-tool-runtime-contractfrom
Y1fe1Zh0u:fix/mcp-unknown-reconciliation
Draft

Give unknown MCP calls an explicit recovery path#958
Y1fe1Zh0u wants to merge 2 commits into
dataelement:002-tool-runtime-contractfrom
Y1fe1Zh0u:fix/mcp-unknown-reconciliation

Conversation

@Y1fe1Zh0u

Copy link
Copy Markdown
Collaborator

Summary

  • expose unknown dynamic MCP receipts through the existing Direct Chat reconciliation flow
  • require explicit user confirmation that the external action was applied or not applied
  • settle the old receipt before allowing the Run to resume
  • never replay an unknown MCP call automatically

Validation

  • 47 Tool ledger and Direct Chat runtime-state tests passed
  • 17 targeted unknown/reconciliation tests passed
  • scoped Ruff and git diff checks passed

Boundaries

  • no database migration
  • no automatic MCP retry
  • no new reconciler service
  • browser UI and live MCP ambiguity were not exercised

Set the existing protocol repair, safe-read replay, and model-visible Tool episode limits to ten while preserving their current independent state and execution semantics. Update focused tests and planning artifacts to make the off-by-one behavior explicit.

Constraint: Tool-related retry and repair limits must be ten without restructuring the existing counters

Rejected: Unify protocol, Receipt, and model-visible repair state now | counter redesign is intentionally deferred

Confidence: high

Scope-risk: moderate

Directive: Keep the independent counters until the planned repair-control refactor; do not infer identical attempt semantics from the shared numeric limit

Tested: 911 Runtime and Tool pytest cases; scoped Ruff; fatal-level caller Ruff; py_compile; git diff --check

Not-tested: Live Provider credentials
Unknown dynamic MCP receipts now use the existing audited Direct Chat reconciliation flow. A user must confirm whether the external action happened before the old receipt is settled and the Run may resume; the Runtime never replays the original MCP call automatically.

Constraint: Dynamic MCP Tools are conservatively classified external_write with retry policy never.

Rejected: Automatically retry an unknown MCP call | could duplicate an external side effect.

Rejected: Add a separate MCP reconciler service | unnecessary while explicit human confirmation provides a real recovery outlet.

Confidence: high

Scope-risk: narrow

Directive: Do not make unknown MCP receipts retryable without an explicit idempotency contract.

Tested: 47 Tool ledger and Direct Chat runtime-state tests; 17 targeted unknown/reconciliation tests; scoped Ruff; git diff --check.

Not-tested: Browser UI interaction and a live MCP server with an ambiguous transport outcome.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant