# 한도는 무엇이며, 거부는 어떤 모습입니까?

REST API · 하나의 요청 한도, 유형화된 타임아웃, 사용 중인 슬롯, 수정 방법이 담긴 입력 오류

*에이전트용 · 6분 · 고급 · 개발자 · 호출 간격 조절*

분당 1,200 요청의 토큰 버킷 요청 한도 하나(에이전트 카드의 `rateLimits`. 스킬은 같은 것을 초당 20, 버스트 40으로 표현합니다). 마감 시간을 넘긴 조회는 REST에서 `error.code: timeout`과 `Retry-After: 5`가 붙은 `503`, A2A에서 `data.retryable`이 붙은 `-32050`, MCP에서 `timeout`을 지정하는 도구 오류로 답합니다. MCP의 무거운 도구는 `busy`로 답할 수도 있습니다. 형식이 잘못된 입력은 코드와 메시지 안의 수정 방법이 붙은 `400`입니다. 모든 응답에는 `X-Request-Id`가 붙습니다.

## 한도

*하나의 토큰 버킷 요청 한도(분당 1200 요청, 에이전트 카드의 `rateLimits`에 공개) — 요청에 대한 한도이지, 무거운 조회가 마감 시간 안에 들어온다는 약속이 아닙니다.* SKILL.md 파일은 이를 초 단위로 밝힙니다: *IP당 초당 20 요청(버스트 40)*. [MCP](https://stablescan.achivx.com/mcp) 호출에는 같은 속도의 별도 예산이 있어 REST와 분리됩니다: MCP를 쓰는 에이전트와 `/v1`을 쓰는 스크립트는 서로를 느리게 하지 않습니다. `429`는 `rate_limited`입니다: *`Retry-After`에 따라 간격을 두십시오 — 쉬지 않고 반복하지 마십시오.* 모든 조회는 요청 마감 시간 아래에서도 실행됩니다: 그 안에 끝낼 수 없는 조회는 유형화된 타임아웃으로 거부되며, 예산에 도달한 [탐색](https://achivx.kr/academy/reference/glossary/#g-walk)은 완전한 척하지 않고 멈춘 뒤 응답에서 그렇다고 밝힙니다.

## 접근 경로별 타임아웃

*요청 마감 시간 안에 끝나지 않은 조회는 REST에서 `error.code: "timeout"`과 `Retry-After: 5`가 붙은 `503`(메시지는 경로를 지정하고 재시도하면 성공할 수 있다고 말합니다), A2A에서 `data: {"reason": "timeout", "retryable": true, "read": "<skill>"}`가 붙은 `-32050` `"deadline exceeded"`(스킬 메서드와 `SendMessage` 모두), MCP에서 도구 오류 `timeout: the read did not finish within the deadline; retrying may succeed`로 답합니다. 간격을 둔 뒤 재시도하십시오 — 무거운 조회는 다시 시간 초과될 수 있으므로 반복하지 마십시오.* 타임아웃은 상태가 아니라 `error.code`로 구별하십시오: 2026-09-24까지는 `504`였고, `503`은 `snapshot_pending`과 `not_ready`에도 쓰입니다. 본문이 이 JSON이 아니고 `request_id`가 없는 `5xx`는 엣지에서 온 것입니다: *대상에 대해 아무것도 말하지 않습니다 — 간격을 두고 재시도하되, 결코 빈 응답으로 읽지 마십시오.* 시간 초과된 쓰기는 `Retry-After` 없이 `503`으로 답합니다: 반복하기 전에 그 효과를 확인하십시오.

## MCP의 busy

무거운 도구 여섯 개 — `get_address_risk`, `get_address_exposure`, `get_address_compliance`, `get_address_approvals`, `get_wallet_graph_walk`, `get_recent_transactions` — 는 서버당 고정된 수의 슬롯을 공유합니다. *잠시 안에 빈 슬롯을 찾지 못한 호출은 아무것도 읽지 않고 `busy: too many concurrent reads on this server; retry shortly`로 답합니다*. 형식이 잘못된 입력은 호출이 슬롯을 기다리기 전에 거부됩니다.

## 입력

*형식이 잘못된 매개변수는 메시지에 수정 방법이 담긴 유형화된 오류로 답합니다 — REST에서는 코드(`invalid_chain`, `invalid_address`, `invalid_limit`, `unknown_param`, …)가 붙은 `400`, A2A에서는 `-32602`(예: `Invalid params: address required`), MCP에서는 문제를 지정하는 도구 오류 — 고쳐서 다시 보내십시오.* 2026-10-13 `?chain=0x1`은 허용 형식 — id, 문자열로 쓴 id, 슬러그, CAIP-2 id — 을 메시지에 지정하며 `invalid_chain`으로 답했습니다. 네 개의 경로가 알 수 없는 쿼리 매개변수를 `400 unknown_param`으로 거부합니다 — `/v1/transfers`, `/v1/verify`, `/v1/freezes/proposals`, `/v1/freezes/acts`. 그 밖의 모든 곳에서는 알 수 없는 매개변수가 무시되므로, 필터는 매뉴얼에 적힌 그대로 정확히 쓰십시오.

## 요청 id와 가동 여부

*모든 REST, A2A, MCP 응답에는 `X-Request-Id`가 붙습니다(직접 보내면 그대로 되돌려 줍니다). 응답을 보고할 때 이를 인용하십시오.* 매뉴얼 §6이 나열하는 엣지 캐시 조회 — `GET /v1/transfers`, `GET /v1/addresses/…`, `GET /v1/subscriptions`, `/v1/networks`, `/v1/tokens`, [`/v1/methodology`](https://stablescan.achivx.com/v1/methodology), 카드, `/.well-known/jwks.json`, `robots.txt`, `llms.txt`, `llms-full.txt`, 사이트맵, 두 개의 `/a2a-ext/…` 명세, *정확한 경로 기준이며 `/v1/tokens/{…}`는 해당하지 않음* — 에서 id는 응답의 Cloudflare ray `<16 hex>-<colo>`이며, 보낸 id는 되돌려 주지 않습니다. 그 옆에 `cf-cache-status`를 인용하십시오. `/health`와 `/ready`는 프로세스 가동 여부입니다: *둘 다 `200`으로 답하는 동안에도 네트워크는 몇 시간 뒤처져 있을 수 있습니다* — 최신성은 `/v1/sync/status?chain=`입니다. 세 접근 경로가 답할 수 있는 모든 상태와 코드, 그리고 각각의 메시지는 [응답은 어떤 것일 수 있습니까?](https://achivx.kr/academy/for-agents/every-answer-code-on-every-door/)에 나열되어 있습니다. `/v1/stats/slo`는 서비스 자체의 지연 시간 예산(note에 따르면 API 프로세스별)과 최신성 기준점(`ofac_sanctions`는 일일·전역, `graph_batch`는 주간·예산 8일·체인별)이며, 네트워크의 [인덱싱 지연](https://achivx.kr/academy/concepts/coverage-and-freshness/)이 아닙니다.

## Stablecoin scanner ACHIVX에서

[에이전트 카드 열기 ↗](https://stablescan.achivx.com/.well-known/agent-card.json)

- 카드의 `rateLimits`에 있는 한도: [/.well-known/agent-card.json](https://stablescan.achivx.com/.well-known/agent-card.json). 매뉴얼 §6: [/agents.md](https://stablescan.achivx.com/agents.md).
- 이더리움(Ethereum)에 대한 서비스 자체의 예산: [/v1/stats/slo?chain=1](https://stablescan.achivx.com/v1/stats/slo?chain=1). 가동 여부: [/health](https://stablescan.achivx.com/health).

## 출처

- [에이전트 매뉴얼 — agents.md (버전 2026-10-05)](https://stablescan.achivx.com/agents.md)
- [A2A 에이전트 카드 (1.4.0)](https://stablescan.achivx.com/.well-known/agent-card.json)
- [REST 인터페이스의 OpenAPI 3.1 명세 (API 1.4.0)](https://stablescan.achivx.com/openapi.json)
- [stablescan-screening SKILL.md — 오류와 호출 간격](https://stablescan.achivx.com/.well-known/agent-skills/stablescan-screening/SKILL.md)

## 더 알아보기

- [한도](https://achivx.kr/academy/reference/limits/)
- [레슨: 탐색과 호출 간격 조절](https://achivx.kr/academy/courses/the-scanner-for-agents/the-scanner-for-agents-05-the-walk-and-pacing/)

## 관련 질문

- [페이지 나누기와 캐시는 어떻게 합니까: 커서, ETag, If-None-Match?](https://achivx.kr/academy/for-agents/how-to-page-and-cache/)
- [Stablecoin scanner ACHIVX MCP 서버는 어떻게 연결합니까?](https://achivx.kr/academy/for-agents/how-to-connect-the-mcp-server/)
- [get-sync-status는 무엇을 반환합니까?](https://achivx.kr/academy/for-agents/get-sync-status/)

REST API · 호출 간격 조절 · 2026-10-13 작성, 스캐너 자체의 기계용 문서와 그날 조회한 실시간 응답을 바탕으로 했습니다. 구조는 그대로 인용했으며, 수치는 날짜 기준이고 인덱스에 따라 바뀝니다.

---

출처: https://achivx.kr/academy/for-agents/what-are-the-limits-and-refusals/ · 영어 원문: https://achivx.com/academy/for-agents/what-are-the-limits-and-refusals.html
