How-to · MCP

Connect ChatGPT to your projects with MCP

FrameOn Lab · 19 September 2026

ChatGPT can read and update a real project instead of working from whatever you pasted into the chat. The connection takes about two minutes, uses no API key, and the part most guides skip — what the model can and cannot do once it is connected — is the part that decides whether it is useful.

What a connector actually changes

Without one, every conversation starts from nothing. You paste a summary, the model reasons over it, and its answer is as good as your summary was. Ask it what was decided about the payment retry logic and it will produce something plausible, because a plausible answer is the only kind available to it.

With a connector, the model calls a tool, gets the actual task list, reads the actual wiki page, sees who is actually assigned — and, when you ask it to, writes back. The difference is not that answers get better. It is that they become checkable.

Connect it

You need a FrameOn workspace (the free plan is enough) and a ChatGPT plan that supports connectors. There is no API key anywhere in this.

In ChatGPT, open Settings → Connectors and choose to add one.
Paste the FrameOn MCP endpoint:
```
https://api.frameonlab.com/api/v1/mcp
```
A FrameOn authorisation page opens in your browser. Sign in, check which workspace it names, and approve.
Back in the chat, ask for something you can verify — "list the open tasks in <project>". If it names real tasks, you are done.

Why there is no key to paste. The server speaks OAuth 2.1 with Dynamic Client Registration and PKCE, so ChatGPT registers itself and receives a token it rotates on its own. Nothing long-lived ends up in a settings field. Revoking access in FrameOn kills it immediately, which a pasted key does not.

The same endpoint, other clients

Claude Code, one line:

claude mcp add --transport http frameon https://api.frameonlab.com/api/v1/mcp

Claude Desktop, Cursor, Windsurf and anything else that reads mcpServers:

{
  "mcpServers": {
    "frameon": {
      "type": "http",
      "url": "https://api.frameonlab.com/api/v1/mcp"
    }
  }
}

Or let a script find the right config file for you:

npx @frameon/mcp-connect

What it can do once connected

Twenty tools: thirteen that read, seven that write. The useful way to think about them is not as a list but as four questions an agent can now answer from fact.

Question	What it reaches
What is the state of this project?	Task tree, filters, statistics, alerts, the team, the time log
Why was it done this way?	The wiki — decisions as documents with version history — and full-text plus semantic search across it
What should I know before touching this?	Project memory: the conventions, constraints and traps recorded separately from the wiki
How do I do this without getting it wrong?	Skill playbooks: which tools to call, in what order, and the traps that cost a round-trip

The seven write tools create tasks, update them, comment, create wiki pages, log time, record what an agent learned, and report AI usage. None of them deletes anything.

Try these first

"Read the FrameOn guide, then summarise where <project> stands and what is blocked."

"Search the wiki for how we handle retries, and tell me which task that decision came from."

"Before we start: what does project memory say I should know about this codebase?"

"Break this epic into tasks. Show me the list before you create anything."

That last one matters. Ask an agent to propose before it writes and you keep the review step. FrameOn's own playbooks are written to propose first for exactly that reason.

What it cannot do, on purpose

A connector that will not tell you its limits gets improvised around. So, explicitly:

It cannot delete. Nothing destructive is exposed over MCP at all. Not gated — absent.
It cannot approve timesheets. It can log its own hours. Approval is a human step and stays one.
It cannot see outside its projects. A credential reaches the projects its role reaches. Cross-workspace access does not exist on this surface, and the workspace identifier never appears in a response.
It cannot see money it should not. Financial figures are stripped from what it reads unless the role behind the token may see them.
It cannot write at all with a read-only token. The write tools are not listed — the model never learns they exist, so it never tries.

When it does not work

Symptom	Usually
Connector added, no tools appear	The authorisation was not completed. Remove it and add it again, and finish the browser step.
Only read tools appear	The role behind your login cannot write, or the credential has no write scope. That is the design, not a fault.
"Which project?" on every call	Expected on the first call. Every project-scoped tool takes a project id, and omitting it returns the list of reachable projects — cheaper than asking you.
The model invents task numbers	It is not calling the tool. Say so: "use the FrameOn tools, do not guess".
Answers ignore a recent change	Ask it to re-read. A chat keeps earlier tool results in context and will happily reuse them.

One habit worth forming

At the end of a working session, ask the agent to write down what the next one would need and could not cheaply reconstruct: a decision and its reasoning, a convention not visible in the code, a trap that cost time. Not the diff — the commit history already has that.

It takes a minute and it is the whole difference between a connector that answers questions and a project that accumulates what it learns. The next agent — in another client, on another machine, next month — finds it there.

Connect in two minutes

Create a free workspace, add the endpoint, approve in the browser. The tool list and the guide the server hands to clients are public, if you would rather read first.

Create a free workspace Read the MCP docs