zckr-lab

Any MCP client that speaks Streamable HTTP. The configuration file differs per client and belongs to that client; the endpoint does not.

{
  "mcpServers": {
    "zckr": {
      "type": "http",
      "url": "https://zckr.dev/api/mcp"
    }
  }
}

The bench fires six different Accept shapes at this endpoint and shows what each one gets back, because that handshake is the half of “will my tool connect” this origin can actually answer.

lab_list_projects

Every project with slug, status, type and a one-line description. Filterable by status or type; the slug feeds lab_get_project.

lab_get_project

One project as markdown: problem, hypothesis, architecture, measured results, lessons, and cause of death when there is one.

lab_list_notes

Engineering notes and TILs with slugs, dates and summaries.

lab_get_note

The full markdown body of one note or TIL.

lab_list_agents

Every coding agent the lab runs, with model tier, tool-grant count and job. Derived from the definition files, so it is what the harness applies.

lab_get_agent

One agent in full: tool grants verbatim, context, memory, how it is evaluated, and the failure modes it is known for.

lab_list_mcp_servers

This registry as data, split by origin. Third-party rows carry no tool list, because that is not knowable from here.

lab_list_systems

The infrastructure inventory, architecture only — the content schema refuses addresses, hostnames, ports and credentials.

lab_get_graph

How everything connects. The whole node/edge document, or one node's neighbours by id.

lab_get_stack

The instrument list with reasons and adoption years, retired gear kept on the record, and the stance on how AI is actually used here.

lab_get_currents

The dated monthly snapshot: focus, what is being built, inputs, and current rabbit holes.

lab_list_ideas

The intake queue — things that might get built, each with the hypothesis that would make it worth it.

lab_search

Case-insensitive search across projects, notes and snapshots, returning the matching line in context.

Every tool here is read-only and annotated as such, so a client that honours readOnlyHint can call any of them without a confirmation prompt.

• The SDK reads the spec's 'client MUST list both media types' literally and answers 406 to a wildcard or absent Accept, which is most real clients. lib/mcp-transport.ts exists entirely to survive that, and it is the single most load-bearing file on this surface.
• A tool description is a prompt, not documentation. Saying when to reach for a tool changed model behaviour more than any schema change did.
• The server also answers at /mcp because that is the path clients and scanners guess first — re-exported from the real route rather than reimplemented, so the two cannot drift.