MCP server

Connect Claude, Cursor or any MCP client to SetFork — lists, runs and master experts as tools.

SetFork ships a remote MCP server (Streamable HTTP), so AI agents can work with lists, run them step by step, and even call in master experts for help — all as first-class tools.

Endpoint

https://setfork.com/api/mcp
Authorization: Bearer sf_…

Create a token in Settings → API & MCP access — see API tokens.

Connect from Claude Code

claude mcp add --transport http setfork https://setfork.com/api/mcp \
  --header "Authorization: Bearer sf_YOUR_TOKEN"

Or in any MCP client that supports remote servers: URL https://setfork.com/api/mcp, header Authorization: Bearer sf_….

A read-scope token unlocks the read tools; creating and changing needs write (see API tokens). An edit to your list always names the version it was built on (baseVersion from get_list): if the list moved on meanwhile, the write is refused instead of overwriting someone else's edit.

Reading and search

Tool	Scope	What it does
`search_lists`	read	Search public lists (and your private ones) by words and meaning — `owner/slug` refs
`get_list`	read	The whole list: every block with a stable `bid`, the version, skill files, your pending edits
`get_script`	read	The list as a ready-to-run script (`sh` / `ps1` / `py`); optionally only some items
`my_drafts`	read	Your unpublished lists
`my_catalogs`	read	Your catalogs — to file a new list

Writing lists

Tool	Scope	What it does
`create_list`	write	A new list — as a draft only you see
`bulk_create_lists`	write	Up to 25 lists per call; reports by default, writes with `dryRun:false`
`patch_list`	write	Edit blocks by `bid`: update, insert, delete, move. With `publish:false` edits pile up in a draft
`update_list`	write	Replace the whole content: anything not in the input is removed
`publish_draft`	write	Pending edits as ONE version (report first, then `confirm:true`)
`discard_draft`	write	Drop pending edits
`publish_lists`	write	Publish drafts in bulk (report first, then `confirm:true`)
`rename_list`	write	Change a list's address; the old one keeps redirecting forever — page, git and skill downloads
`delete_list`	write	Delete a list for good (only with `confirm:true`)

Skills and releases

Tool	Scope	What it does
`publish_skill`	write	A whole skill: blocks and `scripts/`, `references/`, `assets/` files in one version; accepts the original `SKILL.md`. Files are added; removed only explicitly
`list_releases`	read	A list's releases, newest first
`create_release`	write	A release from a version: git tag, title, Markdown notes (report first, then `confirm:true`)

Other people's lists: suggestions, issues, checks

Tool	Scope	What it does
`suggest_edit`	write	Suggest a change to someone else's list — the owner accepts or rejects it
`pending_suggestions`	read	Suggestions waiting for your decision
`review_suggestion`	write	Review a suggestion: approve or request changes
`apply_suggestion` / `merge_suggestion`	write	Accept a suggestion into your list
`revert_suggestion`	write	Revert an accepted suggestion
`report_check`	write	An external check result on a suggestion (like a CI status)
`search_issues` / `get_issue`	read	A list's issues and their threads
`create_issue` / `add_issue_comment`	write	Open an issue, reply in it
`close_issue` / `reopen_issue`	write	Close with an outcome (done / not planned / duplicate) or reopen

Runs and sources

Tool	Scope	What it does
`start_run`	write	Start (or resume) a run of a list
`check_step`	write	Mark a step: done / not done / blocked with a reason
`get_run`	read	A run: steps with marks and overall progress
`report_run`	write	Report verifying a version by a run — raises its verification level
`register_source` / `list_sources`	write / read	External knowledge sources for lists

Workshop masters

Tool	Scope	What it does
`list_gnomes`	read	The roster of master experts: id, name, domains and what each is good at — call this first
`ask_gnome`	write	Ask one master in their specialty (advice, outline, critique); optionally attach a list as context
`gnome_review`	write	A guild master reviews an existing list against his guild code and returns concrete fixes
`council_draft`	write	Convene a full council (steward → experts → critic → elder); returns a `draftId`
`get_council_draft`	read	Poll the council: status, the conversation (which master said what) and candidate lists

ask_gnome, gnome_review and council_draft spend your AI quota — like generating on the site — and therefore need a token with write scope: spending money is not a read. For a quick single-expert answer use ask_gnome; for a full list built from a debate use council_draft (1–4 minutes, poll get_council_draft every ~20s).

The same safety model as the UI applies: an agent creates new lists as drafts, and everything that goes public or cannot be undone (publishing, releases, deletion) takes two steps — a report first, then confirm:true, so the client can ask a human. Only the owner or a collaborator can change a list.

Why this matters

Agents can consume canonical lists ("fetch the team's deploy runbook and follow it"), execute them with progress tracking (start_run → check_step), produce new ones ("turn this incident post-mortem into a reusable checklist and save it as a draft"), and consult the right expert master without leaving their working environment.