Your agent already runs the farm chat. Now let it run the farm.

Generic MCP client config

{
  "mcpServers": {
    "chaba": {
      "url": "https://mcp.chaba.me/mcp"
    }
  }
}

With an agent credential (full access)

{
  "mcpServers": {
    "chaba": {
      "url": "https://mcp.chaba.me/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_CHABA_AGENT_KEY"
      }
    }
  }
}

No header support? Use the sign-in prompt

Apps like Grok's connectors take just a URL. On connect they are redirected to Chaba's sign-in page: paste your Chaba agent key there and the app holds a token from then on (it renews automatically). No key yet? Just exploring on the same page unlocks the public tier below.

The same shape works in Claude Desktop's claude_desktop_config.json, Cursor, and most MCP clients that support remote servers. Once connected, ask your agent to call about_chaba — it returns an always-current brief on what the agent can do and how onboarding works.

It is an ordinary tool call that blocks until a device reports a change, then returns. No push channel, no plugins, nothing your MCP client has to support — because a language model is invoked, not an event loop, and a socket cannot wake one on its own.

Call it in a loop. The first call hands back the farm's current state as a baseline. Every answer includes a next_since value; pass it back as since and the next call blocks for the next change. That same cursor means changes you were too busy to see are replayed to you rather than lost — an event stream that quietly drops a pump's third flip of the night is worse than no stream at all.

One event tells you something moved. It does not tell you whether that was the schedule, a fault, or a relay cycling all day. list_device_state_history answers that from the recorded reports, and changes_only: true leaves just the transitions.

Automations that can't sit in a loop — a cron runner, a Zapier-style tool, anything that starts, acts and exits — get the third shape: register_webhook makes Chaba POST a signed event to your URL the moment a device changes. Heartbeats are never delivered; retries cover about a day; send_webhook_test proves the pipe before real events flow. Verify the Chaba-Signature header with the secret you're shown once at registration.

Events are filtered server-side to the key's farm. A key can never observe another farm's devices. Webhooks bind to the credential's own tenant — they take no phone parameter. On the free plan they point at demo devices only.