Skip to main content
Connect your assistant to the MCP endpoint and choose an agent during sign-in.

​
Connection URL

Point your client at the Streamable HTTP endpoint:
Configure this full URL — including the /mcp path — rather than the bare domain. OAuth discovery lives at the domain root, so a client pointed at https://mcp.bizzyco.ai completes sign-in but then fails on its first request. The server now redirects MCP requests from the root to /mcp automatically, but configuring the endpoint directly is the most reliable.

​
Authentication

Modern MCP clients (Claude Desktop, Claude Code, Cursor, Windsurf) handle OAuth 2.1 + PKCE automatically — point them at the connection URL above and they walk you through sign-in and consent. See Authentication for the full flow.

​
Transport

The MCP server speaks Streamable HTTP at https://mcp.bizzyco.ai/mcp. The earlier HTTP+SSE transport is not available; a client that only supports SSE cannot connect.

​
Health Check

Verify the MCP server is available before connecting:
Response:
The health check endpoint doesn’t require authentication. Use it to verify connectivity before attempting to establish an authenticated connection.

​
Troubleshooting

Possible causes:
  • Network connectivity issues
  • Firewall blocking outbound HTTPS
  • Incorrect URL
Solutions:
  1. Verify network connectivity: curl https://mcp.bizzyco.ai/health
  2. Check firewall rules allow outbound HTTPS (port 443)
  3. Ensure you’re using https:// not http://
If the browser consent flow completes but your client reports a failure (often HTTP 405) on its first request, the client is almost certainly pointed at the domain root instead of the transport endpoint. OAuth discovery lives at the root, so sign-in succeeds and only the first transport request reveals the wrong path.Solution: set your connection URL to the explicit endpoint — https://mcp.bizzyco.ai/mcp. The server redirects MCP requests from the root to /mcp automatically, but configuring the endpoint directly is the most reliable.
A 401 is the canonical signal that your client needs to run (or re-run) the OAuth flow. The WWW-Authenticate header on the response points to a route-scoped protected-resource metadata URL (e.g. /.well-known/oauth-protected-resource/mcp), which a spec-compliant client uses to start discovery.Solutions:
  1. Confirm your client supports OAuth 2.1 + PKCE. Most current MCP clients do.
  2. Make sure you completed the consent screen in your browser. If you cancelled it, retry the connection from your client.
  3. If the client looks stuck after a successful consent, remove and re-add the Bizzy server in the client so it starts the flow over.
  4. If a connection that used to work now returns 401 with error_description="The agent this token was issued for no longer exists", the agent your token was bound to was deleted, deactivated, or moved. Clear the saved authentication for the Bizzy server in your client and authorize again — see When a working connection starts returning 401.
  5. See Authentication for the full handshake.
Possible causes:
  • Insufficient permissions for the requested tool
  • The selected agent’s resource action is set to Ask or Deny
  • Account suspended
  • The business agreement hasn’t been accepted — an owner or admin accepts it in Bizzy
Solutions:
  1. Check the error message for details
  2. Open the selected agent’s Tools tab and allow the resource action you need
  3. Check your agent’s permissions in the dashboard
Throttling shows up in two different shapes — check the response body, not just the status code.A tool call returns a JSON-RPC error with code: -32004. You’ve spent your plan’s per-minute MCP allowance (Free 10, Starter 30, Professional 100, Enterprise 300). The HTTP response is otherwise normal, so a client that only inspects status codes will miss this.The request returns HTTP 429. You’ve hit the per-(user, client) transport backstop of 600 requests per 60 seconds — well above any plan’s tool-call limit, so this usually means a runaway retry loop.Solutions:
  1. Wait data.retryAfter seconds (JSON-RPC error) or the Retry-After header (HTTP 429) before retrying
  2. Implement request queuing or throttling, with exponential backoff as a fallback
  3. See Rate limits for the full breakdown
The server was briefly unable to handle the request. Your token is still valid — do not re-authorize.The response carries a Retry-After header and a JSON-RPC error with code: -32005 and data.retryAfter.Solution: wait the number of seconds in Retry-After, then repeat the same request. If every retry over a few minutes returns 503, check status.bizzyco.ai.

​
Connections

Each request is authorized by its own access token, and the server issues no session ID. Reconnecting after a network drop or a client restart needs no re-authorization: send the next request with the same token.
Last modified on October 3, 2026