Connect over MCP

Advibly's MCP server is at:

https://advibly.com/mcp

Transport is Streamable HTTP. Authentication is OAuth 2.1 with dynamic client registration and PKCE. There is no API key to create, copy or leak - you sign in in a browser once and the client holds the token.

This page is the client-independent setup. If the client has its own page under Clients, follow that page first and return here for the connection contract and first calls.

Adding it

claude mcp add --transport http advibly https://advibly.com/mcp

For ChatGPT, add it as a connector rather than a config file - see ChatGPT. The Clients section contains the complete setup for every supported client.

How the auth works

You do not need to know this to use it, but it helps when something goes wrong:

1. The client calls the endpoint unauthenticated and gets a 401.
2. The 401 points at /.well-known/oauth-protected-resource/mcp.
3. That points at Advibly's authorization server metadata, which registers the client dynamically and then hands off to the sign-in flow.
4. The client gets a token and uses it as a bearer on every call.

Every tool call acts as the signed-in Advibly account, and generation tools spend that account's credits.

First calls

Verify the connection with advibly_list_brands. It proves that tool discovery, OAuth, and account access all work without spending credits:

{
  "name": "advibly_list_brands",
  "arguments": {
    "context": "Finding the available brand contexts and identifiers before starting the user's requested creative production workflow through Advibly."
  }
}

which gives you the brand_id every generation tool needs.

The setup is complete when the call returns the user's brands—or an empty list for a new account—without an authentication error. Then call advibly_check_credits before planning billable work.

Onboarding a brand without the app

If the account has no brand yet, a new user still never has to open a browser tab. advibly_onboard_brand runs the real onboarding from a URL and returns a brand that behaves exactly like one created in the app.

advibly_onboard_brand {
  url: "acme.com",
  context: "Creating the account's primary brand context from its public website before producing the requested campaign assets."
}

It is idempotent: re-running it with a URL the account already has returns the existing brand rather than creating a second one. On the account's first brand it also returns plan options, because that is the point at which the brand limit starts to matter.

After onboarding, keep the returned brand_id; do not guess it from the brand name or URL.

Connection failures

Discovery endpoints