Execute approved tool calls

docs/mcp-interface.md

@@ -181,6 +181,13 @@ curl https://crank.example.com/mcp/v1/default/sales/approvals \
   -H 'Authorization: Bearer <approval_api_key>'
 ```
 
+Статус конкретного запроса:
+
+```bash
+curl https://crank.example.com/mcp/v1/default/sales/approvals/<approval_id> \
+  -H 'Authorization: Bearer <approval_api_key>'
+```
+
 Подтверждение:
 
 ```bash
@@ -190,6 +197,8 @@ curl https://crank.example.com/mcp/v1/default/sales/approvals/<approval_id>/appr
   --data '{ "approve": "yes", "note": "Пользователь подтвердил действие" }'
 ```
 
+После подтверждения Crank выполняет исходный REST-запрос с тем payload, который был сохранен при первом `tools/call`. Если запрос прошел успешно, заявка получает статус `completed`, а результат сохраняется в `response_payload`. Если upstream вернул ошибку, заявка получает статус `failed`, а в `response_payload` сохраняется код и текст ошибки.
+
 Отклонение:
 
 ```bash
@@ -201,6 +210,8 @@ curl https://crank.example.com/mcp/v1/default/sales/approvals/<approval_id>/deny
 
 Ключ MCP-клиента не подходит для этих endpoints. Ключ подтверждения, наоборот, не подходит для `initialize`, `tools/list` и `tools/call`.
 
+Текущая реализация возвращает `approval_required` сразу и не держит исходный `tools/call` открытым до решения пользователя. Поэтому внешний интерфейс может восстановить результат через `GET /approvals/<approval_id>`. Долгое ожидание через Streamable HTTP/SSE запланировано отдельно.
+
 ## Как формируется каталог инструментов
 
 MCP-клиент видит только опубликованные операции, которые привязаны к опубликованному агенту.