MCP: add REST routes + CLI resource mirrors for finding-taxonomy and enrichment-analyzers

[JSONbored]

Context

src/mcp/server.ts registers two static, deterministic MCP resources on the remote server only:

• loopover_finding_taxonomy at URI loopover://finding-taxonomy (src/mcp/server.ts:2815-2831), backed by buildFindingTaxonomyDocument() (src/review/finding-taxonomy.ts) — a static JSON document of AI-review finding categories + severity levels, with zero DB/env dependency.
• loopover_enrichment_analyzers at URI gittensory://enrichment-analyzers (src/mcp/server.ts:2834-2850), backed by buildEnrichmentAnalyzersTaxonomyDocument() (src/review/enrichment-analyzers-taxonomy.ts) — a static JSON document read from the committed review-enrichment/analyzer-metadata.json, also zero DB/env dependency.

Neither resource requires authentication or per-repo scoping — both handlers simply call their builder function and return the JSON, with no requireRepoAccess/requireContributorAccess call anywhere in either registration.

packages/loopover-mcp/bin/loopover-mcp.js already establishes the pattern for exposing exactly this kind of static/semi-static document to the local stdio CLI as a mirrored resource that proxies over HTTP: loopover_compatibility (packages/loopover-mcp/bin/loopover-mcp.js:2129-2146) is a server.registerResource(...) whose read handler calls apiGet(compatibilityPath) (i.e. GET /v1/mcp/compatibility, src/api/routes.ts:1001 — an unauthenticated route) and falls back to a { status: "unavailable", ... } payload on failure. Neither the finding-taxonomy nor the enrichment-analyzers document has an equivalent REST route or CLI resource, so a contributor using the local CLI (rather than a client connected directly to the remote MCP server) cannot discover either taxonomy at all.

Requirements

• Add two new unauthenticated REST routes to src/api/routes.ts, alongside the existing GET /v1/mcp/compatibility (src/api/routes.ts:1001): GET /v1/mcp/finding-taxonomy returning c.json(buildFindingTaxonomyDocument()), and GET /v1/mcp/enrichment-analyzers returning c.json(buildEnrichmentAnalyzersTaxonomyDocument()). Reuse the existing builder functions as-is; do not duplicate their logic in the route handler.
• Both new routes must be added to the same unauthenticated-path exclusion list /v1/mcp/compatibility is already in (the requiresApiToken function, src/api/routes.ts:~5978), so they are public the same way /v1/mcp/compatibility already is — these documents carry no private data (category/severity enums, analyzer names/cost classes, all already committed to the repo).
• In packages/loopover-mcp/bin/loopover-mcp.js, add two new server.registerResource(...) blocks immediately after the existing loopover_compatibility resource (packages/loopover-mcp/bin/loopover-mcp.js:2129-2146), reusing the SAME URI strings the remote MCP server already uses (loopover://finding-taxonomy and gittensory://enrichment-analyzers — do not invent new URIs), each calling apiGet(...) against its new route and falling back to an { status: "unavailable" }-shaped payload on failure, exactly mirroring loopover_compatibility's try/catch structure.

Deliverables

• GET /v1/mcp/finding-taxonomy and GET /v1/mcp/enrichment-analyzers routes added to src/api/routes.ts, both unauthenticated
• loopover_finding_taxonomy and loopover_enrichment_analyzers resources registered in packages/loopover-mcp/bin/loopover-mcp.js, using the exact URIs already used by the remote server
• New route-level tests confirming each route returns the same shape buildFindingTaxonomyDocument()/buildEnrichmentAnalyzersTaxonomyDocument() already produce (mirror the assertions in test/unit/mcp-finding-taxonomy.test.ts and test/unit/mcp-enrichment-analyzers.test.ts at the HTTP layer)
• New CLI-level test(s) confirming both resources are discoverable via the local stdio server's listResources() and return the expected JSON, following the existing resource-test pattern used for loopover_compatibility

Test Coverage Requirements

This touches src/api/routes.ts and packages/loopover-mcp/bin/loopover-mcp.js, both under src/**/packages/** — the repo's 99%+ Codecov patch gate applies in full. Both the success path and the CLI's fallback-on-apiGet-failure path for each new resource must be covered by new tests.

Expected Outcome

A contributor using the local loopover-mcp CLI can discover the finding-category taxonomy and the REES enrichment-analyzer taxonomy the same way they can already discover the changelog and API-compatibility state — via a local MCP resource — instead of only via a client connected directly to the remote MCP server.

Links & Resources

• src/mcp/server.ts:2815-2851 (existing remote resource registrations to mirror)
• src/review/finding-taxonomy.ts / src/review/enrichment-analyzers-taxonomy.ts (existing builder functions to reuse)
• src/api/routes.ts:1001 (GET /v1/mcp/compatibility, the unauthenticated-route pattern to copy) and requiresApiToken (src/api/routes.ts:~5978, the exclusion list to extend)
• packages/loopover-mcp/bin/loopover-mcp.js:2129-2146 (loopover_compatibility resource, the CLI-mirror pattern to copy)
• test/unit/mcp-finding-taxonomy.test.ts, test/unit/mcp-enrichment-analyzers.test.ts (existing server-side tests to extend/mirror)

[linear-code]

JSO-4505