Hanzo
Cloud MCPsync

get_v1_sync_id

Get returns one sync by id.

Get returns one sync by id. It is org-scoped: an id belonging to another tenant is the same 404 an unknown id gives, so a probe learns nothing about what exists.

Toolget_v1_sync_id
Doorhttps://api.hanzo.ai/v1/mcp
Methodtools/call (JSON-RPC 2.0)
Arguments1
OperationGET /v1/sync/{id}
Productsync

Arguments

FieldTypeRequiredDefaultDescription
idstringID is the sync to act on, from the path.

This tool's schema does not declare which fields are required, nor any default, nor any enumerated value set. The columns above are empty because the door publishes nothing there, not because the answer is "none" — where a field is constrained, the constraint is stated in that field's own description.

Call it

A tools/call carries every argument in one flat object — nothing binds to a path or a query string. Every declared argument is shown, because the door marks none of them required.

curl -X POST https://api.hanzo.ai/v1/mcp \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
       "jsonrpc": "2.0",
       "id": 1,
       "method": "tools/call",
       "params": {
         "name": "get_v1_sync_id",
         "arguments": {
           "id": "<id>"
         }
       }
     }'

Values are placeholders derived from each field's declared type. tools/list needs no credential; tools/call does — called without one the door answers HTTP 200 with a JSON-RPC result whose isError is set and whose text says what was missing. How to get a key →

The operation behind it

OperationRouteProductSummary
cloud_get_v1_sync_idGET /v1/sync/{id}syncGet returns one sync by id.

The same capability over plain HTTP is in the sync API reference, on https://api.hanzo.ai.


All 834 tools · The door · API reference

Generated from tools/list on https://api.hanzo.ai/v1/mcp — 834 tools captured 2026-08-01 (this build read the vendored copy; the door was unreachable).

How is this guide?

On this page