ResearchThis Portal

A curated literature feed,
rendered as a gallery — and queryable by your own Claude.

Whatever produces findings uploads a versioned JSON contract to S3. The portal renders it as a filterable card gallery. An MCP server sits next to it, so Claude Desktop or Claude Code can query the same feed directly — no dashboard, no copy-pasting, nothing to install.

Open the live portal Connect via MCP View on GitHub

How it works

Three JSON files in, a live gallery out

No redeploy needed to publish new findings — the portal polls S3 on a short TTL (or an immediate /refresh), so updating the feed is just an upload.

1. S3 (source of truth)findings.json, tracks.json, feed.json — a versioned data contract, uploaded by whatever produces findings.
2. Portal re-fetchesTTL-based cache, or forced via /refresh. Malformed uploads are rejected — the last known-good data keeps serving.
3. Gallery + MCPSame data, two access paths: the browser gallery for humans, MCP tools for your own AI client.
Relevant2025-01-15
Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG
Singh, Ehtesham, et al.
RAGSurvey
Relevant2025-03-30
Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions
Hou, Zhao, Wang, Wang
MCPSecurity
Related2026-03-24
The Evolution of Tool Use in LLM Agents: From Single-Tool Call to Multi-Tool Orchestration
Xu, Li, Ma, et al.
AgentsTool Use

MCP access

Point your own Claude at the feed

The MCP server is a thin, read-only HTTP client of the portal's own public routes — hosted remotely, so there's nothing to install or run locally on any machine.

Claude Desktop
  1. Settings → Connectors → Add → "Add custom connector"
  2. Paste the MCP service URL with /mcp appended
https://researchthis-mcp.onrender.com/mcp
Claude Code
claude mcp add --transport http researchthis-portal \
  https://researchthis-mcp.onrender.com/mcp
Available tools
search_findings(...)Filter by section, track, warn flag, keyword
get_findings_meta()Counts, freshness, theme-track taxonomy
search_zotero_library(query)Search the connected Zotero library
get_zotero_reconciliation()What's in both sources, what's missing from Zotero

Features

Built for a feed that changes, not a one-off report

Filter & searchBy section, theme track, keyword, unverified/LinkedIn flags — client-side, instant.
Freshness stampShows exactly when the underlying data was last updated, not just when the page loaded.
Zotero reconciliationRead-only DOI/arXiv match against a connected Zotero library — what's already there, what's missing.
Reels viewSwipe vertically through findings, TikTok-style, each with a short written summary — off by default.
Optional in-app chatAsk free-text questions over the feed, off by default — or skip it and use MCP instead.
PIN-gated deploysOptional HTTP Basic auth on every route except the health check.
No redeploy to updateNew findings are an S3 upload, not a code change.

Design principles

Why it's safe to point real data at

A few constraints the portal is built around — not features, but things it deliberately refuses to do.

Versioned, not vibesEvery payload carries a contract version. An unsupported version, or any malformed payload, is rejected outright — no silent breaking changes.
Never break, always degradeAn S3 outage or a bad upload never takes the gallery down. It falls back to the last known-good data instead.
Read-only Zotero, permanentlyWord documents cite Zotero items by key. A write path that could ever change a key is out of scope — not missing, refused.
Producer and portal share nothing but the wireWhatever generates findings doesn't need to know the portal's color scheme or page heading, and vice versa. Either side evolves independently.
No default upload pathEvery upload requires an explicit target, so bundled example data is never one missing argument away from overwriting the real feed.
Stateless by designNo durable local state. The process can restart or move hosts with nothing lost — everything durable lives in S3.