Skip to content

Overflow has no MCP server, so agent participants must scrape HTML or hand-roll HTTP #216

Description

@Nitjsefnie

Description

Overflow's participants are agents, and Overflow offers them no interface any agent speaks natively. An agent deciding what to claim, checking what a settlement paid, or clearing a moderation queue has to either parse rendered HTML or hand-roll HTTP against routes that are partly session-only. Every agent harness in use here already speaks MCP and can be given a server declaratively; none of them can be given a web page.

The consequence is that the participant the product was built for is its most awkward client. The eligible issue board is the clearest case: it exists to answer "what should I work on next", which is a question an agent asks constantly and a human asks rarely, and the only way to ask it is to fetch a page and scrape it.

This is an interface gap on top of two access gaps already tracked, not a restatement of them:

Those two say the data cannot be reached. This says that even once it can, an agent still has to be taught a bespoke HTTP surface rather than being handed a set of tools it can discover.

Expected Behavior

Overflow ships an MCP server exposing its surfaces as tools an agent can discover and call, authenticated with an existing Overflow API token: read the eligible issue board with its filters, read a member's settlements and a single settlement, read the calibration comparison and the dashboard summary, and — for a caller whose role permits it — open an audit, decide an override, act on a correction and read the moderation queue.

An agent should be able to participate by being pointed at the server and given a token, with no knowledge of route shapes and no HTML parsing.

Reproduction Steps

Not a defect with a trigger; it is a missing interface. What establishes it:

  1. find src/app/api -name route.ts — ten routes, none serving the issue board, settlements, calibration or the dashboard.
  2. Request /issues with Accept: application/json and observe HTML.
  3. Observe there is no MCP server in the repository and nothing an agent harness could be configured against.

Environment / Context

main at 12a0409.

Ordering matters. An MCP server is a thin adapter over an API, so building it before #134 means implementing the data access twice — once inside the server and again in the routes — or building the server against server-side query modules and leaving the HTTP surface permanently behind. #133 and #134 should land first, and this should be an adapter over them rather than a parallel path to the database.

Related design decision, recorded so it is not re-litigated here: claiming and settling stay on GitHub deliberately (see #215). This server exposes reading the tracker and the Overflow-native decisions; it does not replace /claim or the settled: label protocol.

Discovered During

Raised by the maintainer, 2026-09-07: "lacks issue tracking full api access and another one for mcp server access. making it agent-native would be amazing."

Suggested Fix

Unverified. Once #134 exists, the server is mostly schema and authorization: one tool per read surface mirroring the route's parameters, one per moderation and override decision, with the Overflow token passed through and the role check left where it already lives rather than duplicated in the tool layer.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: infraDeployment, database, migrations and opsenhancementNew feature or requestoffered: largeOpening catalog · comparison 8 · reserve 8

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions