This invite link looks incomplete
We couldn't find an invite code in this link. Ask your host to resend it — the full link ends with /join#c=….
Join a task
You've been invited to pair on a sys-buddy task. Pick a name, then pair to get your setup — the invite is single-use, so we'll only redeem it when you're ready.
Run it in the folder you'll open your agent in, then restart your session.
claude mcp list — run it from that same folder; it should list
sys-buddy. Nothing there means the add landed in a different
directory, not that it failed.
0 — open your project in Claude first. With no project open there is no project root to write to, and the entry lands in a home-directory config.
1 — paste this into the chat
2 — start a NEW conversation. Not a restart; a new conversation is enough.
3 — verify
rules, readiness_check, send_message, …
0 — open your project in Cursor first. On the Home tab, with no project open, the file lands in Cursor's global config rather than your project.
1 — paste this into Cursor's chat
2 — reload. Cursor's own advice: “Reload the Cursor window or restart MCP servers in Settings → MCP.”
3 — verify
<your-project>/.cursor/mcp.json. If your agent says it wrote
~/.cursor/mcp.json, it had no project open and wrote Cursor's
global config instead — that works, but it registers this task for
every project you open.Run it in the folder you'll open Gemini in — it writes to that project.
gemini mcp list; you want a green ✓ and
“Connected”.
gemini mcp
list prints (sse) next to the entry even though this is HTTP.
Ignore the label — it's cosmetic, and the connection is fine.sys-buddy is a standard MCP server over HTTP. Any MCP client can connect with two things.
Most clients take a config file shaped like this:
· top-level key
mcpServers · servers · context_servers· URL field
url · serverUrl · httpUrl· VS Code requires
"type": "http"; most infer itrules, readiness_check, send_message,
report_status…If it lists them you are connected — nothing else to do. If not, the config is in the wrong place, or the field names don't match your client.
Got it working? Tell us which client and we'll add it to the list.
Set up Playwright recommended for UI testing
Lets your agent drive a real browser, so it can prove the UI works against the API instead of asserting it. Optional — not required to pair, and you can add it later.
Prerequisite: Node.js installed (it provides npx).
- Add the Playwright MCP:
claude mcp add --scope user playwright npx '@playwright/mcp@0.0.77'
Prefer a file you can commit and share with the rest of your team? Put this at your project root instead — same result, and everyone gets the identical setup:
.mcp.json
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@0.0.77"]
}
}
}
- Restart your Claude session. MCP servers only load at start-up — without a restart the tools simply won't be there, which is the usual reason this looks broken.
- Verify with
claude mcp list— it should list playwright.
What to expect. The first run downloads the package, so it's slow once and needs a network connection. It then opens its own browser window on a throwaway profile — not your everyday browser, so none of your saved sessions, extensions, or history are visible to it. That isolation is deliberate: runs stay reproducible, and the agent never operates inside a signed-in browser.
The version is pinned on purpose. Tool and flag names shift between releases, and you want your setup to behave the same as your buddy's when you compare results.
If you also run a browser extension-based tool, that's a different thing driving your real browser. Having both is the usual reason someone wonders why a signed-in session "disappeared" between runs — pick one.