2026-09-26에이전트

MCP 도구 호출 타임아웃: 긴 영상 Job은 jobs_wait로

Sume 호스팅 MCP 서버에서 jobs_wait 호출 한 번은 최대 55초까지 대기합니다. 긴 영상 Job은 나눠서 기다리고, id는 최대 20개까지 묶되 다시 제출하지 마세요.

읽는 시간 5분Sume

https://mcp.sume.com/mcp의 Sume 호스팅 MCP 서버에서 jobs_wait 호출 한 번은 최대 55초까지 대기하므로, 에이전트는 몇 분 걸리는 영상 Job을 슬라이스로 나눠 기다립니다. Job id로, 또는 최대 20개의 id로 jobs_wait를 호출하고, 슬라이스가 wait_slice_expired로 끝나면 같은 id로 다시 호출하세요. 유료 create는 절대 다시 제출하지 마세요. 지켜보는 사람이 있든 없든 Job은 계속 실행되고 계속 청구됩니다.

이 규칙은 Sume의 Job과 결과 (영문), 인증, MCP 도구와 게이트 페이지를 바탕으로 하며, 2026-09-26에 확인했습니다. 현재 동작으로 설명한 응답 필드는 호스팅 서버의 코드에서 가져왔습니다. 기초 페이지는 CLI와 호스팅 MCP가 여전히 동작하지만 현재 주 연동 경로는 아니라고 설명합니다. 백엔드는 대신 HTTP로 GET /v1/jobs/{id}/status를 폴링합니다. 이 글은 AI 영상 API 멱등성 키의 MCP 편입니다.

긴 MCP 도구 호출은 왜 타임아웃되나요?

대기 한 번은 아무것도 전송하지 않은 채 열려 있는 HTTP 요청 하나이며, 어떤 엣지든 그런 요청을 결국 끊습니다. 그러면 호출자는 도구 결과를 전혀 받지 못하지만, Job은 계속 실행되고 계속 청구됩니다. 그래서 모든 원격 POST /mcp 호출자에게 jobs_wait 한 번은 최대 55초까지만 대기합니다. 서버는 대기를 600초 동안 붙잡아 두지 않습니다. 그렇게 오래 붙잡힌 요청은 응답하기 전에 엣지에서 502나 Transport send error로 끊깁니다.

십 분짜리 렌더는 더 긴 대기를 요청하지 말고 대기를 반복해서 기다리세요. timeout_seconds의 기본값은 50이고 상한은 55입니다. 600까지의 값은 받아들이지만 상한으로 잘라 내며, 응답의 wait_slice_clamped가 그 사실을 알려 줍니다. 현재 이 필드에는 requested_timeout_seconds와 applied_timeout_seconds가 담깁니다.

jobs_wait는 어떻게 호출하나요?

두 가지 형태 중 정확히 하나를 보내세요.

Job 하나에는 job_id를 보냅니다. 응답은 object: "job_wait"입니다.
job_ids에는 id를 1–20개 넣고, 선택적으로 wait_for를 all(기본값)이나 any로 보냅니다. 응답은 object: "job_wait_batch"이며, 요청한 모든 id의 상태 스냅샷을 담습니다.
timeout_seconds는 선택입니다. 생략하면 50이고, 최대 55까지 보낼 수 있습니다.
대기는 Job이 종료 상태(completed, failed, canceled)가 되는 즉시 반환됩니다.

{
  "job_ids": ["job_123", "job_124", "job_125"],
  "wait_for": "all",
  "timeout_seconds": 50
}

슬라이스는 무엇을 반환하고, 그다음엔 무엇을 하나요?

병렬 fan-out 뒤에는 단건 대기 N번 대신 배치 대기 한 번을 쓰세요. 대기가 반환할 수 있는 결과와 그다음 할 일은 다음과 같습니다.

Job과 결과 (영문) 기준, 2026-09-26 확인. `outcome` 필드는 현재 서버 동작입니다.
받은 결과	의미	다음 단계
`outcome: "terminal"`	대기 조건 충족. 모든 id가 종료 상태이거나, `wait_for: "any"`라면 하나 이상이 종료 상태	`jobs_result`로 결과 읽기. 아직 끝나지 않은 id는 계속 대기
`wait_slice_expired`	폴링 창이 닫힘. 끝나지 않은 Job은 여전히 실행되고 청구되는 중	같은 id로 `jobs_wait` 다시 호출. 현재 그 id는 `wait_slice_expired.pending_job_ids`에 나옴
어느 결과와도 함께 올 수 있는 `wait_slice_clamped`	55초를 넘게 요청해서 서버가 상한을 적용함	대기는 그대로 실행됨. 다음에는 55 이하로 보내기
HTTP `524`, `522`, `523` 또는 `525`	전송 실패. Job 결과가 아님	같은 id로 `jobs_wait`를 다시 호출하거나 `jobs_status`를 한 번 읽기. Job이 막혔다고 보고하지 않기
호출 전체가 실패	목록에 알 수 없는 id나 다른 워크스페이스의 id가 있음	id 목록을 고친 뒤 다시 대기

배치 전체의 결과는 어떻게 읽나요?

jobs_result도 같은 1–20개 상한으로 job_ids를 받으므로, 한 번의 호출로 기다린 wave는 한 번의 호출로 다시 읽을 수 있습니다. 응답은 job_result_batch입니다. results[]는 요청 순서대로 id당 한 항목씩 담기고, 각 항목에는 ok와 함께 value 또는 형식화된 error가 있습니다.

부분 성공은 정상입니다. 아직 실행 중인 id는 job_not_completed로 돌아오고, 끝난 id는 모두 결과를 반환합니다.
partial_failure.failed_job_ids는 다시 읽을 만한 id를 정확히 알려 줍니다. 항목마다 ok를 확인하세요. 한 id의 실패는 다른 id에 대해 아무것도 말해 주지 않습니다.
wait_for: "any"여도 모든 id를 보고하며, 기다리지 않은 Job도 계속 실행되고 계속 청구됩니다.
Job 자체의 상태가 failed라면 그 입력에 대한 판정입니다. 현재 도구 설명은 error.public_reason과 error.message를 보려면 jobs_get을 쓰라고 안내합니다. 지목된 입력을 고치기 전에는 똑같은 create를 다시 제출하지 마세요.

기다리는 데도 비용이 드나요?

대기는 읽기입니다. 호스팅 MCP는 jobs_wait를 유료 도구가 아니라 읽기 도구와 함께 나열합니다. 요청 한도에서 MCP 도구 호출은 그 호출이 만드는 실행에 대해 쓰기 예산을 한 번 쓰며, 호출을 실어 나른 JSON-RPC 요청에는 쓰지 않습니다. MCP로 하는 jobs_status 폴링은 쓰기 예산을 전혀 쓰지 않습니다. 읽기는 별도 버킷에서 플랜 쓰기 숫자의 마흔 배를 받습니다.

청구되는 것은 Job입니다. 클라이언트 쪽 타임아웃은 아무것도 취소하지 않으며, 취소는 생성 작업이 시작되기 전에만 성공합니다. 그 뒤에는 API가 409 job_generation_already_started로 응답합니다. MCP에서 jobs_cancel는 idempotency_key가 필요한 쓰기입니다.

script_run도 jobs_wait를 호출할 수 있지만 스크립트 전체가 요청 하나로 제한되므로, 긴 렌더는 여전히 스크립트 밖에서 기다립니다. script_run을 이용한 프로그래밍 방식 도구 호출을 참고하세요.

출처

작성자 Sume