Troubleshooting

What the AINOX App MCP server's errors mean and how to fix them.

Missing or invalid API key

Missing or invalid API key: send it as `Authorization: Bearer <key>`.

The server didn’t accept the key, so tools don’t know which account to act for. Check, in order:

The header. It must be Authorization: Bearer <key> or x-api-key: <key>. A header set to Bearer ${AINOX_API_KEY} means your client didn’t expand the variable: set it in the environment the client was launched from, then restart the client.
The key itself. On the Agent Access page, a key marked Disabled or Expired no longer works, and a revoked key no longer appears at all. Create a new one.
The rate limit. Each key allows 120 requests a minute. A key over the limit is refused until the minute passes. Poll more slowly, or give each tool its own key.

Thread not found

Thread <id> not found.

The thread doesn’t exist or belongs to a different account than the key. Keys only reach their owner’s threads, so a thread ID copied from someone else’s link won’t work. Call list_threads for IDs you can use.

The thread refuses a new message

The agent is still replying: wait for it, or stop it with stop_run.
The agent is waiting on a tool call: answer it with resolve_tool_call first.

A thread takes one turn at a time. Poll get_thread until status is idle. If it’s waiting, answer every entry in pendingToolCalls first; stop_run doesn’t clear them.

A pending tool call can’t be found

No pending tool call with that runId and toolCallId: get_thread lists the current ones.

The call was already answered, perhaps from the web app, or the IDs were copied from an older get_thread result. Call get_thread again and use the IDs it returns now.

Publishing fails

Message	Fix
`Name the app before publishing it: pass name.`	Pass `name` on the first publish.
`Nothing to publish yet: the thread has no files.`	Wait for the agent to write the app, then publish.

When deployment.status ends at failed, the build broke. Ask the agent to fix it with send_message, then publish again. unreachable means the upload server didn’t answer the status check; try get_thread again shortly.

list_files or read_file is slow

The thread’s sandbox stops when it sits idle, and these tools start it again. The first call after a pause can take a while; later calls are fast.