Run Selda from ChatGPT, Claude or Cursor

What this actually is

You already talk to an assistant. ChatGPT, Claude, Cursor, Gemini, whichever one you opened this week. It can write and think, and then it stops, because it has no hands: it cannot look up a company for you, cannot remember what your business sells, cannot put a message in front of a real person.

This gives it hands. Paste one address into your assistant, log in once, and it can reach your Selda workspace. From then on you ask in plain words and the work happens:

“Find ten accounting firms in Gothenburg, work out who to write to at each one, and draft something for every one of them.”

and your assistant does exactly that, in your workspace, with real companies and real people, and stops with ten drafts waiting for you to read.

“MCP” is the plumbing and you can forget the word. It stands for Model Context Protocol, and all it means is a standard way for an assistant to use an outside tool. Selda speaks it, your assistant speaks it, and that is the whole of what you need to know.

Why bother

The machine-readable side of this page (tool schemas, an example client, loadable skills) lives in Selda-AI/Selda-mcp-docs.

Copy this

https://mcp.selda.ai/api/mcp

That is the whole setup. Nothing to install, no key to create. Find where your tool asks for an “MCP server” or a “connector”, paste that address, and log in with the Selda account you already use. Then pick which workspace it may reach.

Below is where that box is in each tool.

ChatGPT

1. Settings → Connectors → Add
2. Paste https://mcp.selda.ai/api/mcp
3. Log in when it sends you to Selda, and pick your workspace
4. Ask it: “List my Selda projects”

If step 4 answers with your workspaces, you are done. ChatGPT only calls a connector that exposes tools named search and fetch; Selda exposes both, so there is nothing else to set up.

Claude (claude.ai or the desktop app)

1. Settings → Connectors → Add custom connector
2. Paste https://mcp.selda.ai/api/mcp
3. Log in, pick your workspace
4. Ask it: “List my Selda projects”

Cursor (also Windsurf, Zed, VS Code)

1. Settings → MCP → Add new MCP server, or write the file yourself: ~/.cursor/mcp.json, or .vscode/mcp.json in the project for VS Code
2. Paste this in:

{
  "mcpServers": {
    "selda": { "type": "http", "url": "https://mcp.selda.ai/api/mcp" }
  }
}

3. Restart the editor, log in when it asks
4. Ask it: “List my Selda projects”

Gemini CLI

1. Open ~/.gemini/settings.json
2. Paste this in:

{
  "mcpServers": {
    "selda": { "httpUrl": "https://mcp.selda.ai/api/mcp" }
  }
}

3. Restart gemini, log in when it asks
4. Ask it: “List my Selda projects”

Claude Code, scripts, a server, CI

Anything with no browser cannot do the login step, so it needs a key instead.

1. In the app: Settings → Apps → Selda MCP → create a key. The full value is shown once, copy it
2. Run:

claude mcp add --transport http selda https://mcp.selda.ai/api/mcp \
  --header "Authorization: Bearer PASTE_YOUR_KEY"

3. Ask it: “List my Selda projects”

The key goes in a header, never in the URL, so it stays out of shell history and proxy logs. The same screen in the app tells you whether a call has actually arrived on that key; it only says connected once one has.

Something else

Any tool that speaks MCP over HTTP works. Give it https://mcp.selda.ai/api/mcp and either let it log you in, or send Authorization: Bearer sk_live_... yourself.

If it does not connect

Run this. It needs no key and no login:

curl https://mcp.selda.ai/api/mcp

You should get back {"name":"selda","version":"...","status":"ok"}. If you do, the address is right and the problem is in your tool’s config, not in Selda. (The version moves; status: ok is the part that matters.)

Eligibility

How the authentication actually works

Two ways in, one thing underneath: every call carries a Selda API key, and the key is what says which organisation you are.

The OAuth way (no key to copy)

You add the address, and the client does the rest:

1. It calls the server without credentials. Selda answers 401 with a WWW-Authenticate header pointing at /.well-known/oauth-protected-resource, which points at the authorization server (https://api.selda.ai). This is how the client discovers the flow without being told.
2. It registers itself (POST /oauth/register, RFC 7591). No human step, no client id to create by hand.
3. It sends your browser to https://app.selda.ai/oauth/authorize. You log in with the account you already use, and approve one workspace.
4. It exchanges the resulting code for an access token (POST /oauth/token, Authorization Code with PKCE, S256).

The access token is an sk_live_… key under the hood. Same organisation scoping, same list, same revoke button in Settings → Apps → Selda MCP. OAuth is a way to mint one without anybody copying a string, not a second permission system.

The static key way

Create a key in Settings → Apps → Selda MCP and put it in a header. The full value is shown once.

Authorization: Bearer sk_live_...

The key travels in a header, never in the URL, so it stays out of shell history and proxy logs.

What a key can and cannot reach

• The organisation is resolved from the key. You never send an orgId, and a key made in one organisation cannot see another one’s workspaces. That is enforced server side on every call, not by the client asking nicely.
• Scopes: read for queries, write for mutations, pipeline for engine runs. A key without the scope gets 403 and a sentence saying which one is missing.
• Test keys (sk_test_…) cannot spend or send. Every plan can connect with one. Real sends from your connected inboxes need Pro or above.
• Keys are stored hashed. Selda cannot show you an existing key again, only replace it.
• Revoke in Settings → Apps → Selda MCP. The same screen tells you whether a call has ever arrived on that key, so “connected” means a request was actually seen, not that a string was pasted somewhere.
• No key of any kind can send a message. There is no MCP tool for it, on any plan, with any scope.

What you can do with it

Everything, with one exception. Connected, your assistant runs the whole product: it lists and opens your workspaces, reads and corrects leads, writes the Brain that every message is built from, starts the engine, watches a run, reads what came back, and drafts replies on real threads in your inbox. Sixty-two tools, and they are the same functions the app’s own buttons call. This is not a read-only view of Selda, it is Selda with a different front end.

The exception is the send. There is no send tool, on any client, with any key. That is not a setting somebody could turn on: the one function that sends appears in no registry an API key can reach, and a test pins that. So the most an assistant can do is put a finished draft in front of you, which is exactly as far as it should get.

Once connected, these prompts produce real work in your Selda workspace:

• “List my Selda projects.”, see your workspaces and get the projectId everything else needs.
• “Look up Example Oy and tell me who to reach in marketing.”, enriched company info and matched decision-makers, no campaign started.
• “Create a campaign from this folder of prospect research, upload the files, find decision-makers, draft messages.”, one file per company (PDF, Markdown, JSON); lands as a real, reviewable campaign in the app, exactly like dragging the folder in yourself.
• “Find 20 SaaS founders in Finland and add them as leads to my main project.”, runs the discovery pipeline and stores drafted outreach.
• “Check the status of that campaign run.”, phase, companies found, contacts resolved, messages drafted.
• “Draft a first-touch message for this lead based on their website.”, a personalized draft grounded in real research.
• “Check my credits.”, remaining balance and plan.
• “Show campaign stats for my Q3 campaign.”, sent, replies, meetings, the numbers that matter.
• “Add these companies from this page as leads.”, paste a URL or list; known contacts get added directly.

Build your own pipeline

Everything above is one question at a time. The step after that is a sequence you repeat, and you build it the same way: by describing it, not by writing code.

Start with what your assistant already knows about you. This is the part people miss. If you have been using ChatGPT for a while, it has already been told about your business: in a project, in custom instructions, in an uploaded deck, or just across a lot of conversations. That context does not have to be typed into Selda a second time. Hand it over:

“You already know what we do from our earlier conversations. Write that into the Selda Brain: what we sell, who we sell it to, the two customers we can name, and the one thing we must never claim about ourselves.”

The Brain is what every message is built from, so this is the step that decides whether the outreach sounds like you or like a template. If your assistant does not know enough yet, point it at the source instead:

“Read our website and our pricing page, then put what you learn into the Selda Brain.”

Anything invented here ends up in a real message to a real person, so it has to be facts. That is also why the Brain has an avoid type: the things Selda must never claim are worth writing down as explicitly as the things it may.

Then hand it the research you already do. If you analyse prospects somewhere else, in a spreadsheet, in a folder of PDFs, in another assistant, that work does not have to be repeated:

“Here are eleven PDFs, one per company. Load them into Selda as a campaign, find the decision-maker at each, and draft from what is in the file rather than crawling the site.”

That lands as a real campaign in the app, the same as if you had dragged the folder in yourself.

Then let things arrive on their own. When someone fills in your form or an ad gets answered, your own code or automation can tell Selda, and it picks the person up from there:

“When a signup arrives, add them to Selda with whatever we know, join them to the onboarding campaign, and draft the first message.”

If you build software, this is where it gets interesting. The thing your product already knows about a user, that they signed up, that they hit a limit, that they finished a trial without buying, is exactly the thing that decides what to say to them and when. You do not need a separate sales tool watching from outside; your own app can tell Selda directly, and the outreach is written from the actual event rather than from a guess about it. Ask your assistant to wire it:

“Add a call to Selda in our signup handler: send the email, the company domain and what plan they picked, join them to the onboarding campaign, and draft the first message.”

Your assistant writes that code against the same API, in your codebase, and from then on the product drives the outreach. The draft still waits for you.

Then keep going. Ask for the run’s status, read what came back, correct a lead that is wrong, draft the reply to someone who answered. It is all one conversation, and none of it sends.

The order that works: facts in → material in → run → read → correct → draft the reply. Each step is a sentence, and you can stop at any of them.

→ Longer patterns people actually build: What people build with it → Full tool list and details: MCP server reference.