Burnout to All Out

Build Your Own
ChatGPT or Claude
Connector

From an idea to a working tool—without becoming a developer.

You are going to build a small piece of software that lets ChatGPT or Claude reach into a tool you already use and do real work there.

Your AI handles the research and writes the software. You choose what it should do, download the finished project, and move it through a few visible buttons. No coding experience assumed. No Terminal.

Plan about two hours for your first build. Your place is saved automatically, so you can close this and come back.

Choose the AI you are building for

Use the switch at the top of this guide to choose ChatGPT or Claude. Most of the build is identical. Only the final connection screens change.

Stay in one conversation with your chosen AI from Phase 1 through the finished build. That conversation becomes the project brain: it keeps the official documentation, your selected jobs, the code, and every error in one place.

What you are actually building

The technical name is a remote MCP server. MCP stands for Model Context Protocol: a shared way AI products can talk to outside software. Inside ChatGPT or Claude, you will see it described as a connector, app, or plugin. In this guide, we simply call it your connector.

Why build one when connectors already exist

If an official connector already does everything you need, use it and skip this guide. This is for the gaps.

Circle is our own example. Its official connector reads the community well, but it could not do the admin work we needed. We built a second connector that could. Both stay available; the custom one covers what the official one leaves out.

Building your own usually makes sense when:

• An official connector exists but cannot do the specific job you need.
• The tool has an API, but no connector exists yet.
• The connector skips the parts of the tool your business runs on.
• You want a few focused actions shaped around your workflow.

Your AI will check for an existing connector and the official API before you build anything.

The four places in this build

Each place has one job. Keeping those jobs separate makes the build much easier to follow.

Before you start

• Choose ChatGPT or Claude and your computer type at the top.
• Done, next marks a screen complete. Skip moves on without marking it.
• All steps lets you jump anywhere.
• Stuck? opens searchable troubleshooting from every screen.
• Every black box has a Copy button. Use it instead of retyping prompts.

Phase 1 of 6

Research the tool and choose the jobs

You are not reading API documentation. Your AI is. This phase ends with a clear yes or no, three first-version jobs, and the exact credential you need.

Three screens.

Step 1.1

Name the tool. Let your AI investigate.

Open one new conversation in ChatGPT or Claude—whichever you chose at the top. This is the conversation you will use for the entire build. Replace the bracketed tool name and send the prompt.

I want to build a small connector between [TOOL NAME] and this AI.

You are responsible for the technical research throughout this
project. Search the web and use the current official documentation
from the tool itself. Do not ask me to find documentation or paste
documentation links later. Keep the verified sources and technical
details in this conversation so you can use them during the build.

Before we write any code, tell me in plain English:

1. Does this tool have an API I can build on?
2. Does an official connector already exist, and what can it do?
3. What can the API read?
4. What can it create, change, or delete?
5. What can it not do?
6. What API keys, access levels, permission scopes, or separate
   admin APIs exist? Explain what each one unlocks.
7. Which API version should we use now?
8. Are there approval requirements, paid API access, or request
   limits I should know about?

End with one verdict:
- BUILDABLE NOW
- BUILDABLE WITH A CATCH
- NOT BUILDABLE THROUGH THE OFFICIAL API

Cite the official sources you verified, but do not make me read
them. Do not write code yet.

If the verdict is not buildable

Stop there. Ask your AI for the simplest supported alternative for that specific tool. Do not force a connector onto software that does not provide the access.

Step 1.2

Have your AI hand you a menu

Send this in the same conversation. You are choosing from verified options—not brainstorming imaginary capabilities.

Using only capabilities you verified in the current official API
documentation, give me 12 useful connector jobs to choose from.

What my business does: [ONE SENTENCE]
What I use this tool for: [TWO OR THREE THINGS]
What takes the most time in it: [ONE OR TWO THINGS]

For each option, tell me:
- What I could ask the AI to do, in plain language
- Whether it reads information or changes information
- Which API key, access level, or permission it needs
- Easy, medium, or hard to build

Put the best options for my business first. Do not suggest anything
the verified API cannot actually do.

Step 1.3

Choose three jobs for version one

Start small. Three jobs are enough to prove the connector works. Reading jobs are safest for a first build because they cannot alter your data.

My three jobs for version one are:

1. [JOB ONE]
2. [JOB TWO]
3. [JOB THREE]

Re-check the current official documentation for each job. Confirm
that every job is supported and name the exact API credential,
access level, and permissions I need.

Then give me click-by-click instructions for where to create that
credential inside [TOOL NAME]. Do not ask me to search the docs or
find the settings on my own. Do not write code yet.

Phase 2 of 6

Get your key and set up the handoff

You will collect the one private credential your connector needs, then install the visual app that sends your finished project to GitHub.

Four screens.

Step 2.1

Create the API credential

Follow the click-by-click path your AI gave you in Step 1.3. Create the credential with only the access needed for your three jobs.

Copy the key into your password manager. Many tools show it exactly once.

Step 2.2

Create your GitHub and Railway accounts

• Create a free GitHub account at github.com/signup.
• Create a Railway account at railway.com. Choose Sign in with GitHub so the accounts are already connected.

Railway charges for running the connector. A small connector is inexpensive, but check Railway's current pricing before you deploy.

Step 2.3

Install GitHub Desktop

Download GitHub Desktop from desktop.github.com/download. It handles Git and GitHub through visible buttons, so you do not need Terminal, Git commands, or a personal access token.

Step 2.4

Sign in to GitHub Desktop

1. Choose Sign in to GitHub.com.
2. Your browser opens. Approve the sign-in.
3. Return to GitHub Desktop.
4. If it asks for your name and email, use the same email as your GitHub account.

That is the entire GitHub connection. No token to generate, copy, or remember.

Phase 3 of 6

Have your AI build the project

Your AI already knows the tool, the official documentation, and your three jobs. Now it creates one finished package you can download.

Three screens.

Step 3.1

Tell your AI to build the whole package

Send this in the same conversation from Phase 1. Replace the tool name and three jobs. Do not include your real API key.

Build the complete remote MCP connector for [TOOL NAME] now.

The three jobs are:
1. [JOB ONE]
2. [JOB TWO]
3. [JOB THREE]

You own the technical decisions. Before coding, reopen and verify
the current official [TOOL NAME] API documentation and the current
official MCP SDK documentation. Do not ask me to locate or paste
documentation.

Build the simplest stable version:
- Node.js with Express
- The current official MCP SDK
- Streamable HTTP transport at /mcp
- A /health route that returns the word OK
- Listen on process.env.PORT, defaulting to 3000
- Read every credential from environment variables
- Never put a real key or token in any project file
- No login system, dashboard, database, or unrelated product
  infrastructure
- Clear tool names, input descriptions, and useful error messages
- Use only API endpoints supported by the official documentation

The finished project must include:
- package.json with a working "start" script
- every complete source file
- .gitignore that ignores node_modules and .env
- .env.example with variable names only and no real values
- SETUP.txt listing the exact Railway variable names, the start
  command, and three plain-language test prompts

Run whatever checks are available in your environment and fix any
errors before delivery.

Deliver the entire finished project as one downloadable ZIP file.
Put the project files at the top level of the ZIP, not inside extra
nested folders. Do not make me create files or copy code blocks by
hand. Do not include placeholder comments or unfinished sections.

Step 3.2

Download and unzip the project

1. Download the ZIP your AI created.
2. Move it somewhere you will keep, such as Documents.
3. Open the ZIP to extract the project folder.
4. Rename the folder in lowercase with hyphens if needed, such as flodesk-connector.

I need the actual downloadable project package now. Create and
attach one ZIP containing every finished file. Do not paste the
files into the conversation and do not give me instructions for
creating them myself.

Step 3.3

Check the package without reading code

Open the extracted folder. You are checking names and structure—not reviewing programming.

There must be no file named .env and no file containing your real API key. You never gave the key to your AI, so it cannot belong in this package.

On a Mac, filenames beginning with a dot may be hidden. That is normal. SETUP.txt and package.json are the two visible files you need for the next phases.

Phase 4 of 6

Publish it with GitHub Desktop

You already have the finished folder. GitHub Desktop turns it into a private repository and publishes it. Every action in this phase is a button.

Four screens.

Step 4.1

Add the project folder

1. Open GitHub Desktop.
2. Choose File, then Add Local Repository.
3. Click Choose and select the extracted project folder—not the ZIP.
4. If GitHub Desktop says the folder is not a Git repository, click the link to create a repository there.
5. Use the folder name as the repository name. Leave Git Ignore set to None, License set to None, and do not add a README. Your AI already supplied the files the project needs.

When the project opens in GitHub Desktop, the left side shows a list of files under Changes.

Step 4.2

Save the first version

1. Look through the filenames under Changes.
2. Confirm there is no file named .env. A file named .env.example is correct and safe.
3. At the bottom left, type First working version in the Summary box.
4. Click Commit to main.

A commit is simply a named snapshot. Nothing has gone online yet.

Step 4.3

Publish the repository

1. Click Publish repository in the top bar.
2. Keep the repository name.
3. Make sure Keep this code private is checked.
4. Click Publish Repository.

GitHub Desktop signs in and sends the project for you. There is no password prompt and no token.

Step 4.4

Verify it landed

In GitHub Desktop, choose Repository, then View on GitHub. Your browser opens the private repository.

Confirm the file list includes package.json and SETUP.txt. Confirm again that .env is not there.

This visual check is your proof that Railway will receive the correct project.

Phase 5 of 6

Deploy it on Railway

GitHub stores the files. Railway runs them. This is the first and only place you need to test the server.

Five screens.

Step 5.1

Point Railway at the repository

1. Log into Railway and click New Project.
2. Choose Deploy from GitHub repo.
3. Select your connector repository.
4. If the private repo is missing, choose the option to configure GitHub access and grant Railway access to that repository.
5. When Railway offers Deploy Now or Add Variables, choose Add Variables.

Step 5.2

Add the private credential

Open SETUP.txt from your downloaded project folder. It lists the exact environment variable names the connector expects.

1. In Railway, open your service and go to Variables.
2. Railway may suggest names from .env.example. Use those suggestions, or click New Variable.
3. For each variable, copy the name exactly. Capital letters and underscores matter.
4. Paste the real key from your password manager as the value.
5. Do not create a PORT variable. Railway supplies that automatically.
6. Review and deploy the staged changes.

This is the first time the real API key enters the project—and it stays inside Railway.

Step 5.3

Wait for a successful deployment

Railway installs the project and starts it. A successful deployment turns green or shows a success status.

Railway failed while deploying the project you built. Diagnose the
exact cause from this log, re-check the current official docs where
needed, fix the project, and give me a complete replacement ZIP.

[PASTE THE RAILWAY ERROR LOG]

Step 5.4

Generate the public address

1. Open Settings for the Railway service.
2. Find Networking.
3. Click Generate Domain.
4. If Railway asks for a port, enter 3000.

Railway gives you an address similar to your-connector-production.up.railway.app. Copy it.

Step 5.5

Confirm the connector is alive

Paste the Railway address into a browser and add /health to the end.

https://your-address.up.railway.app/health

If the page says OK, the connector is live. Copy the Railway address without /health; you need it in the next phase.

If it does not say OK, open Railway's deployment logs and give the exact error to the same AI conversation. Do not start a new chat.

Phase 6 of 6

Connect it to ChatGPT

The server is running. Now you add its /mcp address to your chosen AI and test one real request.

Three screens.

Step 6.1

Add the connector to ChatGPT

https://your-address.up.railway.app/mcp

Use /mcp here. The /health address was only the heartbeat check.

Step 6.2

Turn it on in a new conversation

Your connector must be enabled in the conversation before your AI can call its tools.

Step 6.3

Ask for one real read-only job

Use one of the exact jobs from Phase 1 and include a real record, date, or identifier from your account.

Use my [CONNECTOR NAME] connector to [YOUR FIRST READ-ONLY JOB].
Show me the result and tell me which connector tool you used.

Your AI may ask permission to use the tool. Review the action and approve it. When real data comes back, test the other two jobs.

You built that.

Changing the connector later

Return to the original build conversation and describe the new job or the problem. Your AI already has the documentation and project history.

Update the connector you built in this conversation to add:
[DESCRIBE THE NEW JOB]

Re-check the current official API documentation, update every
affected file, run your checks, and give me one complete replacement
ZIP. Do not give me partial snippets.

Open the new ZIP and copy its contents into your existing local project folder, replacing files with the same names. Do not delete the existing project folder itself.

GitHub Desktop shows the changes. Type a short Summary, click Commit to main, then Push origin. Railway notices the update and redeploys automatically.

Building your second one

Your accounts and GitHub Desktop are already ready. Here is the whole build with no explanation.

When it breaks

First builds sometimes break. The same searchable list is behind the Stuck? button at the top of every screen.

Done

You built a
connector

Your AI did the technical work. You directed the build.

The skill was not memorizing code or Terminal commands. It was choosing a useful job, keeping the AI anchored to official documentation, and moving a finished project through a clean handoff.

Print or save as PDFBack to the start

The printed copy contains every screen, both Mac and Windows notes, and your selected AI connection path.

Copy my resume link

Clear my progress and start fresh

Burnout to All Out. Built for members creating their first connector.