It assembles cited reports from web and local sources
GPT Researcher starts with a question, creates narrower research questions, gathers material, summarizes each source, and combines the result into a report. The Python package exposes that flow directly, while the repository also includes a FastAPI server and two frontend choices. Reports can use web search or local PDF, text, CSV, spreadsheet, Markdown, PowerPoint, and Word files. That is a useful starting point when the product requirement is a research workflow rather than a single search call.
The architecture has a planner, execution agents, and a publisher. Research branches can run concurrently, and the project tracks source links as it works. The README says reports can exceed 2,000 words and use more than 20 sources, but those are product descriptions, not results from our sandbox. Source volume does not verify a claim. A competent deployment still needs rules for acceptable domains, conflicting evidence, stale pages, and human signoff.
The default route depends on OpenAI and Tavily accounts
The shortest documented setup uses Python 3.11 or later, then asks for an OpenAI API key and a Tavily API key before starting Uvicorn. An OpenAI-compatible base URL can replace the default model endpoint. LangSmith and Monocle tracing are optional, and Gemini image generation needs a Google API key plus its own feature flag. Each extra provider changes cost, data handling, rate limits, and failure behavior.
GPT Researcher also works as an imported Python package. That route is appealing for an existing service because code can call conduct_research() and write_report() without adopting either frontend. Docker Compose is the more complete application path: the README says its default configuration starts 2 processes, a Python server on port 8000 and a React app on port 3000. Operators should decide which surface they need before copying the full stack.
What happened when we ran it
Our sandbox installed 230 Python packages in 88 seconds, leaving 1006 MB on disk. The repository at commit 6f99857 contained 820 files and about 46,276 lines of source in a 27.7 MB checkout. Pip-audit reported 0 known vulnerabilities in the installed environment. The project had 6 CI workflow files, a Dockerfile, a Compose file, and a tests directory.
The build ended with exit code 1 after 9 seconds. The supplied measurement does not include a diagnostic tail for that step, so there is no sound basis for naming a missing compiler, package, or configuration as the cause. The useful conclusion is limited: install completion did not lead to a successful build in the fresh Python 3.12 Debian container.
Tests ended with exit code 1 after 30 seconds. Pytest reported 398 passed, 14 failed, and 1 skipped out of 412. Several failures could not import get_all_retriever_names; another could not import gpt_researcher.utils.enum. Other logged failures involved search results being dropped, Semantic Scholar returning an empty list, and Serper tests finding no mocked requests.request. The log lists these outcomes but does not prove that they share one cause.
MCP expands the inputs, while the server lives elsewhere
The Python client can combine a web retriever with MCP servers. The README demonstrates a GitHub MCP server passed as a process command with a GitHub token. This makes private or specialist sources available to the same report flow, but it also means GPT Researcher inherits the permissions and reliability of each connected server. A production service should restrict those tokens and record which connector supplied each important claim.
The dedicated GPT Researcher MCP server has moved to assafelovic/gptr-mcp. This repository is therefore an MCP client, not the current home of the server implementation. Claude users also get a separate skill installation through npx skills add. Those are distinct integration paths: the skill packages a workflow for Claude Code, while MCP connects the research code to external tools and data sources.
Its bias claim needs a human reviewer
The README is unusually direct about its limitation. GPT Researcher tries to reduce incorrect or biased output by scraping multiple sources and comparing recurring information, but says it does not aim to eliminate bias. Its disclaimer calls the application experimental and says it should not be treated as a recommendation for academic research. That language should shape the product around it.
For internal market scans, first drafts, and cited briefing material, a reviewer can inspect the links and correct weak synthesis. High-stakes research needs more: source-quality rules, primary-document preference, date checks, quotation verification, and a record of prompts and provider versions. The 398 passing tests show substantial exercised code, while the 14 failures mean this exact checkout does not offer a clean baseline for unattended use.
August 2026 activity is current, and the failed baseline still matters
GitHub showed 29,156 stars, 52 open issues and pull requests, and an Apache-2.0 license when fetched. The last push was August 24, 2026. Release v3.6.1 was published that day and says it restored the main branch, added CI, landed queued pull requests, documented a scholarly retriever, and changed scraper and retriever behavior. That is current maintenance, not a guarantee that commit 6f99857 matches every later fix.
GPT Researcher earns a trial when cited report generation is the actual product feature and a team can own provider configuration plus editorial review. The wide set of frontends, retrievers, file formats, and tracing options saves assembly work. Our 1006 MB install, failed build, and 14 failing tests make a staged evaluation the right entry point, with one chosen provider path and a small set of known research questions before broader deployment.