Anything else

GradWorkbench is a standard remote MCP server. Nothing about it is specific to the tools on the previous pages, so anything that speaks MCP over HTTP can connect: Zed, Cline, Roo Code, Gemini CLI, JetBrains AI, a script you wrote yourself.

This page is what you need to know to work it out for a tool not listed here.

Before you start#

You need: Any client that speaks MCP over HTTP.

You will know it worked when: Settings → Research Access shows a Last used time against the connection rather than Never.

Your workspace address is your app's address with /api/mcp on the end. The block on Settings → Research Access has yours already filled in, with a copy button — use that rather than typing it.

What to tell it#

That is the entire specification. There is no SSE endpoint, no stdio version, and no separate staging address.

The four config shapes#

Almost every tool uses one of these. If the one you are configuring isn't documented, try them in this order — the first is by far the most common.

1. mcpServers with url — Claude Desktop, Cursor, Cline, Roo Code and most others:

{
  "mcpServers": {
    "gradworkbench": {
      "type": "http",
      "url": "https://gradworkbench.vercel.app/api/mcp",
      "headers": { "Authorization": "Bearer sk_your_key_here" }
    }
  }
}

2. mcpServers with serverUrl — Windsurf and Antigravity. Same shape, different key for the address.

3. servers — VS Code and Copilot. Same entry, different root key.

4. Something else entirely — Codex uses TOML, OpenCode uses an mcp block with "type": "remote".

If a tool offers a Add remote MCP server button or a URL field, use that instead of any file; it will write whichever of these shapes it wants.

Signing in versus a key#

The server supports OAuth 2.1 with PKCE and dynamic client registration, which means a client can register itself and send you here to approve it — no key, nothing to store. Most current MCP clients do this automatically when they get a 401 back.

If a tool has no OAuth support, issue a key in Settings → Research Access and send it as an Authorization: Bearer header. Everything works identically either way.

For the technically curious, the discovery documents are where the spec says they are:

https://gradworkbench.vercel.app/.well-known/oauth-protected-resource
https://gradworkbench.vercel.app/.well-known/oauth-authorization-server

Clients that only speak stdio#

A few older tools can only launch a local program and talk to it over standard input and output. mcp-remote bridges the gap — it runs locally and forwards to a remote server, handling the sign-in for you:

{
  "mcpServers": {
    "gradworkbench": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://gradworkbench.vercel.app/api/mcp"]
    }
  }
}

This needs Node.js installed. Prefer a direct HTTP connection wherever the tool supports one — the bridge is another moving part that can fail on its own.

Connect twice, so research gets checked#

Whatever submits a finding is refused when it tries to confirm that same finding, so add the server a second time under a second name — gradworkbench-verify — with either a second sign-in or a second key carrying Read your workspace and Check research and not Submit research.

Without it, research runs and then stops at verification with "Verification must be independent". See §10.4.

Check it worked#

Ask, in whatever tool you just connected:

What's in my GradWorkbench workspace? Just summarise it — don't research anything.

If that doesn't work, Settings → Research Access is the fastest diagnosis: it lists every connection and when it was last used. Never means nothing has reached the server at all, so the problem is in the tool's configuration rather than in anything you asked for.

← Back to Connecting your assistant