Connect Claude, ChatGPT, Copilot or Cursor over MCP

The MCP setup for the four assistants people ask about most, and what to do with any other client.

Two ways in, and the first one is easier

Every MCP client needs the server URL, which is https://lynkarr.com/mcp. What it needs after that depends on the client, and there are two answers.

Sign in. Most clients will offer to authorize the connector: you are sent to Lynkarr in a browser, you sign in if you are not already, and you are shown exactly what the assistant will be able to do before you allow it. Nothing is typed and no token is copied anywhere. This is the path to take wherever the client offers it.

Or use a token. If the client has no sign-in step, make an API token — Settings, then API tokens — and send it as a request header. That works everywhere, and it is what the per-client instructions below cover.

Either way it ends the same way: the connection appears in Settings, API tokens, named after the application, and revoking it there disconnects the assistant immediately.

Whichever route you take, grant as little as the job needs. A read-only connection — codes:read, links:read, analytics:read — cannot change where anything points.

Signing in, step by step

This is the route the connector dialogs are built around. You do not need to know what it is called; you only need to know what you will see.

After you give the client the URL, it sends you to Lynkarr. If you are already signed in there is nothing to type. The page names the application asking, the account it will act on, and lists in plain words what it will be able to do — read your QR codes, change where they point, read your scan figures, and so on, depending on what the assistant asked for.

It also says what no connection can ever do, whatever it asked for: invite or remove a person, change anybody’s role, or touch your billing. Those are refused by the API itself rather than by the connector, so they hold for every assistant.

Allow it, and you are connected. The connection shows up in Settings, API tokens as the application’s name followed by “connected app”, and it counts as one of your plan’s tokens.

In your assistant, add a connector and give it https://lynkarr.com/mcp.
Choose the option to sign in or authorize when offered — not “no authentication”.
Sign in to Lynkarr if you are asked to.
Read what the assistant is asking for, then choose Allow access.
Ask it something — “list my Lynkarr QR codes” — to confirm it worked.

Signing in needs a plan that includes API access. On the Free plan there is nothing to connect to yet.

Claude

Claude supports remote MCP servers directly, so there is nothing to install, and its connector dialog is built around signing in. Leave Authentication on the pre-selected “Always required”: that is now the correct setting, and Claude will send you to Lynkarr to approve the connection.

You will see who is asking, which account it will act on, and what it will be able to do. Allow it and the connector finishes. Nothing is copied and no token is typed anywhere.

If you would rather use a token — a shared machine, or a connection you want to scope by hand — that still works. Set Authentication to None and add the token under Additional request headers as X-API-Key.

Use X-API-Key rather than Authorization for that. Claude keeps Authorization for its own credential and describes custom headers as being sent alongside it, so a custom Authorization is not reliably passed on. When it is dropped, the connector connects and then reports that it has no tools available, which explains nothing.

In Claude, go to Settings, then Connectors, and choose Add custom connector.
Give it a name and the URL https://lynkarr.com/mcp.
Leave Authentication as it is, and finish adding the connector.
When Claude opens Lynkarr, sign in if asked, read what is being requested, and choose Allow access.
Ask “list my Lynkarr QR codes” to confirm.
Prefer a token? Set Authentication to None instead, add a header named X-API-Key, and paste your token as its value.

Header name:   X-API-Key
Header value:  lyn1_your_token_here

The header route takes no “Bearer” prefix — just the token. Either way the connection appears in Settings, API tokens, and revoking it there disconnects Claude.

Any other client

A client that offers to sign in can do so: point it at https://lynkarr.com/mcp and it will find its own way to the approval page. Nothing needs configuring here for that to work.

A client that only supports headers takes a token instead: turn its authentication off and add X-API-Key set to your token. Use X-API-Key rather than Authorization — a client that manages sign-in itself tends to treat Authorization as its own, and a custom one is quietly dropped, leaving a connector that connects and then has no tools. We accept either header, so the choice is only about which one survives the client.

Both routes end in the same place: a scoped credential that appears in Settings, API tokens and stops working the moment you revoke it there.

ChatGPT

ChatGPT connects to remote MCP servers through its connectors settings. Availability depends on your plan and on whether the workspace allows custom connectors, so if you cannot see the option it is usually an account setting rather than anything to do with us.

Add a connector pointing at https://lynkarr.com/mcp and authenticate with the API token as a bearer credential. The tools appear under the connector once it is saved.

Create an API token in Lynkarr: Settings, API tokens.
In ChatGPT, open settings and find connectors.
Add a custom or developer connector with the URL https://lynkarr.com/mcp.
Authenticate with a bearer token and paste the token in.
Ask it to list your QR codes to confirm.

If ChatGPT offers only OAuth, use a custom header instead: X-API-Key, set to your token. And if custom connectors are not available on your plan at all, the REST API does the same job from a script.

Microsoft Copilot

Copilot reaches MCP servers through Copilot Studio rather than through the Copilot chat settings. In Copilot Studio, add a tool or connector of the MCP kind, give it https://lynkarr.com/mcp, and store the API token as the connection's bearer credential.

Because this route goes through Copilot Studio, an administrator may have to publish the agent to the people who will use it. That is a Microsoft permission rather than a Lynkarr one, and nothing on our side needs changing for it.

Create an API token in Lynkarr: Settings, API tokens.
In Copilot Studio, open the agent you want to extend and add a tool.
Choose the MCP option and give it https://lynkarr.com/mcp.
Set the connection to use a bearer token and paste the token in.
Publish the agent to whoever needs it.

Cursor

Cursor reads MCP servers from a JSON file: ~/.cursor/mcp.json for every project, or .cursor/mcp.json inside one project when the connection should not follow you elsewhere.

Add the server with the token in an Authorization header. Restart Cursor afterwards and the tools appear in its MCP settings.

{
  "mcpServers": {
    "lynkarr": {
      "url": "https://lynkarr.com/mcp",
      "headers": {
        "Authorization": "Bearer lyn1_your_token_here"
      }
    }
  }
}

This file holds a live credential. Keep it out of version control — a token in a repository is a token somebody else has.

VS Code

VS Code takes MCP servers in .vscode/mcp.json inside a workspace, or in your user settings for every workspace. The shape is close to Cursor's but names the transport explicitly.

{
  "servers": {
    "lynkarr": {
      "type": "http",
      "url": "https://lynkarr.com/mcp",
      "headers": {
        "Authorization": "Bearer lyn1_your_token_here"
      }
    }
  }
}

Use an input or an environment variable for the token rather than committing the file with the value in it.

Anything else that speaks MCP

MCP is a standard, so a client we have never heard of works without us doing anything. It needs to support remote servers over HTTP — sometimes called streamable HTTP — and to let you set an Authorization header. That second requirement is the one to check first: several clients present OAuth as the only option in their dialog, and hide custom headers a step further down.

Give it https://lynkarr.com/mcp and the token in a header: either Authorization set to Bearer followed by the token, or X-API-Key set to the token on its own. Prefer X-API-Key wherever the client also does OAuth, because that is the case where Authorization tends to be overwritten. If the client only supports local servers that it launches itself, there are proxy tools that present a remote server as a local one; that is a workaround on the client side and nothing changes here.

When it does not connect

A 401 means the token is missing, mistyped, expired or revoked. Check it starts with lyn1_. With Authorization the value is the word Bearer, one space, then the token; with X-API-Key it is the token alone.

Connecting but showing fewer tools than you expected is not a fault: tools are filtered to what the token's scopes allow. A read-only token is shown the reading tools and not the others, deliberately, so the assistant cannot try something it may not do.

Connecting and then failing on every call, with the tools listed, means the token is not arriving. That is the shape of a dropped header, and the fix is usually to send it as X-API-Key rather than Authorization.

Ask the assistant to run the whoami tool. It answers with the account, the plan, the scopes and what is left of your limits, which settles most of this in one go.