The two common mistakes
Doubling the word Bearer. Some tools have a “token” field and add Bearer for you. Others take the raw header value and do not. Paste Bearer au_live_… into the first kind and the header reads Bearer Bearer au_live_…. That is a 401 that looks exactly like a bad token. Every connection page says which kind its tool is.
Leaving out the transport. Several clients read a bare url with no type as a stdio command and skip the server without a useful error. Claude Code needs "type": "http", Cline needs streamableHttp, Roo needs streamable-http, Goose needs streamable_http, and Cursor takes no type field at all. They are not interchangeable. Each connection page has the exact string.
There is no SSE endpoint. --transport sse and "type": "sse" look like they are accepted, then never connect.
The tools never appear
No send_message in the client means the server was skipped, not rejected. That is a config-shape problem, not a credential one. Check three things in order: the top-level key (mcpServers, servers, mcp and mcp_servers are all real keys in different tools), the transport string, and whether you edited the file the tool actually reads. A project config and a global config with the same server name is a common cause of “it worked yesterday”.
Some tools need a nudge after you save the file. VS Code wants MCP: List Servers → Start. Claude Desktop wants a full quit and relaunch. A project-scoped Claude Code server wants one interactive approval.
Every call returns 401
Take the client out of it and ask the API directly.
curl -s -o /dev/null -w "%{http_code}\n" https://api.tryagentupdate.com/v1/agent/whoami \
-H "Authorization: Bearer $AGENT_UPDATE_TOKEN"
# 200 → the token is fine and the problem is in your client's config
# 401 → the token is wrong, rotated, or the header is malformed200 means the token is good and the client is mangling the header. Usually that is an environment variable that is not set in the process that launched the tool. Most clients send an unresolved ${VAR} literally, and OpenCode resolves an unset variable to an empty string, giving a header of exactly Bearer . On macOS, an editor launched from the Dock often does not inherit your shell environment at all. Hard-code the token for one run to rule it out.
401 means the token itself is bad. Tokens are shown once and stored hashed, so there is no way to look one up. Rotate the agent in the app and paste the new token.
It sends, but nothing arrives
A 200 from POST /v1/agent/messages means we accepted the message, so the problem is on the phone. Three candidates: notifications are not allowed for Agent Update, a Focus mode is blocking that agent, or the phone is signed into a different account than the one that owns the agent.
Also check you are not deduplicating yourself. A repeated nonce returns the original message instead of sending a new one. That is what it is for, but a loop that reuses one constant nonce will only ever deliver the first message.
I reply, and the agent never sees it
If you wrote the polling client yourself, check the field name first. You send text, and you read body. A client that reads reply.text gets undefined for every message — and if it treats empty text as “nothing to deliver”, your reply is dropped without an error anywhere. Print the raw JSON once and compare it against the reply shape.
curl -s "https://api.tryagentupdate.com/v1/agent/messages?limit=5" \
-H "Authorization: Bearer $AGENT_UPDATE_TOKEN"
# { "messages": [ { "id": "msg_…", "role": "user", "body": "Ship it" } ] }
#
# The words are in `body`. A reply has no `text` field at all.Then check when you advance after. Advance it only once a message is actually processed. Nothing is consumed by reading, so a cursor moved too early is the one way to lose a reply: ours still has it, yours will never ask for it again. Recovery is to drop after and re-read from the start.
And remember this endpoint returns the human’s messages only. Sending yourself a message and polling for it proves nothing — it will never come back.
Everything returns 429
The ceiling is 60 messages per minute per agent. Reads are capped separately. Limits are fixed-window, so back off and the next window starts clean. If a polling loop is hitting it, poll every 5 to 30 seconds instead of continuously, and pass after so each call returns only what is new. The full list is on the REST API page.
If you are waiting on one specific question, do not poll. Long-poll GET /v1/agent/messages/:id/answer?wait=45, which returns the moment you answer and costs one request.
Still stuck? agentupdate@trytemperance.com. Include the tool, the config you pasted with the token removed, and the exact error.