quests.lol
Menu
ACCESS // API REST + MCP v1.0.0

The board, as JSON.

Everything on Dossiers and Pulse, readable by something that is not a person, plus who else has already called each token on gg.xyz and at what entry. One key opens both the REST endpoints and the MCP endpoint. Built because going through a day of projects by hand takes a day.

Connect an agent

One line. Nothing to install, nothing to version. Everyone is on the deployed build.

claude code 
claude mcp add --transport http quests https://quests.lol/mcp \
  --header "Authorization: Bearer YOUR_KEY"

Then ask it plainly: what landed on the board today, and has anyone called it on gg?

Or over HTTP

Stored reads, with a bearer key on every request. openapi.json has the full schemas.

  1. GET /api/v1/gg/calls

    Stored GG calls and attributed theses, newest first

    limitcursorcontractchain

  2. GET /api/v1/gg/calls/{id}

    One stored GG call with thesis and caller profile

  3. GET /api/v1/search

    Find a stored project by contract, website or X profile

    q

  4. GET /api/v1/projects

    The board, or what changed on it

    pagesincecursorlimithas_dossier

  5. GET /api/v1/projects/{handle}

    One project by X handle or stable ID

    include

  6. GET /api/v1/projects/{handle}/ask

    What has been asked of Lark about a project, and what she answered

  7. GET /api/v1/pulse

    All eight current pulse cards

  8. GET /api/v1/pulse/{beat}

    One pulse card

one day of the board, one request 
curl -H "Authorization: Bearer YOUR_KEY" \
  "https://quests.lol/api/v1/projects?since=2026-08-31T00:00:00Z&limit=100"

The tools an agent sees

  • list_projectsThe board, newest first, with totals.
  • sync_projectsOnly what changed since a point. Returns a cursor.
  • search_projectsFind a stored contract, website or X profile. Never starts research.
  • get_projectOne project by ID or X handle. Optional votes, research status and freshness.
  • get_pulseThe current pulse cards, all eight or one.
  • list_gg_callsStored GG calls and attributed theses, newest first. Filter by contract.
  • get_gg_callOne saved call, its author and linked projects, by call ID.
  • ask_larkRequest research or ask a question. Allowlisted key owner required.
  • lark_answersRead research progress and answers. Same owner access required.

Limits

Rate
60 requests per minute, per key
Browse
50 projects a page, fixed
Sync
50 by default, 100 by request
Errors
{ error: { code, message } }, always
Auth
One 401 for every failure, on purpose

Read these before you build the loop

Read the thesis, know the caller

GG calls include the saved thesis, author profile, avatar and GG-provided X handle when available. PnL is the caller’s dated seven-day realized trading result, not the return on that call. Old or unknown figures stay null.

Follow next, not page length

GG pages hold up to 30 calls, with a default of 20. Long theses can shorten a page to keep replies small. Follow next until null. This browses saved history; it does not sync edits or removals. Reread a call ID for its current saved version.

Search reads what we have

Use /search?q= with a contract, website or X profile. A miss does not add a project or buy research. Multiple matches stay ambiguous. Use a chain-qualified contract or a stable project ID to narrow them down.

Status is not a completion promise

Search includes vote counts, dossier progress and separate source dates. Use include=context on a project read for the same detail. Public snapshots may be 30 seconds old. Unknown dates stay null; queued research does not reserve funding. Voter names require an allowlisted key owner.

Protection before new work

GG calls, search, enriched project reads and research submissions pause if rate protection is unavailable. REST returns 503 with Retry-After; MCP returns a tool error asking you to wait 60 seconds. Existing basic reads remain available.

A project can arrive more than once

Match on id, never on handle. A repeat is an update, not a new project. An X handle can be abandoned and picked up by somebody else.

since means the archive wrote the row

Not that the project materially changed. A re-sighting that only refreshed a follower count still counts as a write. Compare against what you stored if you need real change.

The two paging modes do not mix

page is the board. since and cursor are the delta. Asking for both is a 400 rather than a silent preference, because a consumer who thinks it is syncing while the server is paging never finds out.

Keys are issued by hand.

Every key is a row somebody writes. Say who you are and what you are building, and it gets written. Revoking one kills both surfaces at once, because there is one credential and one check.

link pending Ask in the Discord.