The Problem: AI Research Tools Are Fundamentally Broken
AI research tools are borderline useless for academia.
Traditional AI assistants like ChatGPT and Claude generate authoritative-sounding responses with completely fabricated citations. Have a look for yourself:
- A 2023 peer-reviewed study in Cureus found that when ChatGPT generated medical research content, 47% of citations were entirely fabricated and only 7% were both real and accurate.
- A separate 2023 study in Clinical Medicine examined ChatGPT responses to medical questions and discovered 69% of references were completely fabricated, despite appearing plausible and authoritative.
As a research assistant, that’s catastrophic. You need every claim backed by a real source, not 7% of it!
A friend of mine in bioinformatics was complaining about exactly that, the other day. But manually cross-referencing findings across dozens of papers & juggling PubMed query syntax has another problem — it’s slow and tedious, the tooling being ancient.
Could I help him?🤔
This problem sparked my curiosity as a weekend project. I ended up building a research assistant for him that can’t hallucinate — not by making the LLM smarter, but by giving it access to peer-reviewed, reputable sources via MCP.
What is MCP? MCP (Model Context Protocol) is a framework that allows AI models like Claude to connect to external data sources and tools through standardized server interfaces, stopping hallucinations cold by providing real-time access to authoritative data, instead of relying on the LLM’s training data.
Since my friend isn’t a coder, I needed something he could use without touching code, so MCP servers were perfect — using a long prompt, I orchestrated a stack of tools he could use directly from Claude Desktop (not a hard requirement; just use any MCP client at all).
Solution: The Domain-aware AI Research Stack
This tutorial demonstrates building a zero-code, pure natural language research assistant that accurately cites sources and answers complex queries, using three specialized MCP servers that provide:
- Web intelligence (Bright Data MCP)
- Domain-specific academic databases (biomcp + mcp-simple-arXiv)
- Knowledge graph memory (Memory MCP)
All three MCP servers are available on GitHub, free, and open-source.
Why This Works
- No hallucinations: Sources come from real databases, not LLM training data
- Zero coding required: Pure natural language interface through Claude Desktop
- Persistent knowledge: Knowledge graph remembers previous research sessions
- Complex query support: Can answer relational questions across multiple studies.
Server #1: Web Intelligence with Bright Data MCP
What Bright Data MCP Provides:
This is Bright Data’s All-in-one solution for web data extraction at scale — with built-in solutions for:
- Bot detection bypass
- CAPTCHA solving
- Rate limiting management
- Geoblocking circumvention
- And a paid Pro mode with better tools for browser automation, quick access to data from Facebook/Tiktok, Amazon/Walmart/Ebay/Zara etc, YouTube, and more.
Key Tools for Research Are In The Free Tier:
search_engine: Scrape search results from Google, Bing or Yandex. Returns SERP results in markdown (URL, title, description)scrape_as_markdown: Scrape a single webpage URL with advanced options for content extraction, and get back the results in Markdown. Easy peasy. Can unlock any webpage even if it uses bot detection or CAPTCHA.
The free tier supports 5000 tool calls per month, far more than other MCP’s I was considering like Brave Search + some browser automation MCP. No dependency hell, either.
Setup Instructions
- Sign up at the link below.
The Web MCP by Bright Data - Start with a Free Plan
- Get API Key.
- Add to MCP Config (remote hosted version):
{
"mcpServers": {
"Bright Data": {
"command": "npx",
"args": [
"mcp-remote",
"https://mcp.brightdata.com/mcp?token=YOUR_API_TOKEN_HERE"
]
}
}
}
Pro Mode For 60+ Tools
If you know you’ll need any of the tools in Pro mode, you could also run it locally and enable those tools (among other tweaks) with an env variable like this:
{
"mcpServers": {
"Bright Data": {
"command": "npx",
"args": ["@brightdata/mcp"],
"env": {
"API_TOKEN": "your-token-here",
"PRO_MODE": "true", // Enable all 60+ tools
"RATE_LIMIT": "100/1h", // Custom rate limiting
"WEB_UNLOCKER_ZONE": "custom", // Custom unlocker zone
"BROWSER_ZONE": "custom_browser" // Custom browser zone
}
}
}
}
We can use this alone to query for well-respected, trusted sources via Google, but that’s not entirely reliable. We need something more — access to authoritative, peer-reviewed sources.
Server #2: Academic Database Access with Domain-Specific MCPs
💡 For light research, or less domain-specific topics, this step is completely optional. Bright Data with its SERP + individual page scraping tools — can handle it all just fine.
I just have two of these for now (neither need API keys), and I swap these out depending on what I’m researching.
A. BioMCP for Biomedical Research
BioMCP provides direct access**** to peer-reviewed biomedical databases.
- PubMed: Medical literature database
- ClinicalTrials.gov: Clinical trial registry
- MyVariant.info: Genetic variant data
- bioRxiv: Preprint server
- OpenFDA: FDA drug/device data
- cBioPortal: Cancer genomics data (API key required)
GitHub - genomoncology/biomcp: BioMCP: Biomedical Model Context Protocol
Setup Instructions
- Make sure
uvis installed and working (pip install uv) - Add to MCP Config (local):
{
"mcpServers": {
"biomcp": {
"command": "uv",
"args": ["run", " - with", "biomcp-python", "biomcp", "run"]
}
}
}
B. simple-arXiv MCP for STEM Papers
The simple-arXiv MCP server gets us access to cutting-edge preprints in fields including, but not limited to:
- Mathematics and Physics
- Astronomy
- Computer Science
- Statistics
- Electrical Engineering
- Mathematical Finance and Economics
No API key required.
Setup Instructions
- Install the server locally (
pip install mcp-simple-arxiv) - Add to MCP Config (local):
{
"mcpServers": {
"simple-arxiv": {
"command": "python",
"args": ["-m", "mcp_simple_arxiv"]
}
}
}
C. More Domain Options
Besides these, you could always add more connectors in other niche domains if you need/find them (like the Earthdata MCP server which provides NASA’s Earth science data for environmental and geospatial research.)
The key is finding MCP servers that are laser focused on the specific academic domains you need, for trusted data.
Server #3: Persistent Knowledge with Memory MCP
There are many, many knowledge graph implementations out there, take your pick. I just went with the simplest one, the original memory MCP from Anthropic itself.
What The Knowledge Graph Memory Server Provides:
Anthropic’s memory MCP creates a local knowledge graph that we can use to store, post-research:
- Research sources with full citations
- Domain concepts and their relationships
- Expert researchers and their publication patterns
- Cross-study connections for complex queries
Key Benefits Over Stateless Research:
- Remembers previous sessions: No need to re-research known topics. Just check the state of the knowledge graph before a query and you’re good to go.
- Enables complex queries: Entity and Relationship modeling makes cross-discipline queries like “How did attention mechanisms migrate from NLP into protein design research?” possible.
- Tracks research paths: So you can ask “What’s the chronological path of clinical trials on CRISPR since 2021?”
- Identifies expert networks: “Who has published the most on this topic?”
Best of all, it builds up research intelligence over time, with each query.
The knowledge graph makes these connection-based queries trivial — it’s built for “find me everything connected to this thing” rather than “find me rows that match these columns.”
Setup Instructions
- Make sure
npxis installed and working - Add to MCP Config (local):
{
"mcpServers": {
"memory": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-memory"],
"env": {
"MEMORY_FILE_PATH": "E:\\coding\\ai\\mcp\\memory.json"
}
}
}
}
This architecture is pretty clean — each MCP server has one job and does it well. Domain servers tap into peer-reviewed academic databases, Bright Data extracts the papers those servers surface (and can act as a fallback/fetch tertiary sources), and the knowledge graph prevents fragmentation. The LLM orchestrates between them and fills in the reasoning gaps.
Complete MCP Configuration
Here’s my full MCP config. If you’re using Claude, this goes in the claude_desktop_config.json file
You can find that option in Claude Desktop → Settings → Developer Options.
{
"mcpServers": {
"Bright Data": {
"command": "npx",
"args": [
"mcp-remote",
"https://mcp.brightdata.com/mcp?token=YOUR_API_TOKEN_HERE"
]
},
"biomcp": {
"command": "uv",
"args": ["run", " - with", "biomcp-python", "biomcp", "run"]
},
"memory": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-memory"],
"env": {
"MEMORY_FILE_PATH": "E:\\coding\\ai\\mcp\\memory.json"
}
},
"simple-arxiv": {
"command": "python",
"args": ["-m", "mcp_simple_arxiv"]
}
}
}
Notice that the knowledge graph MCP server stores its knowledge graph in a local memory.json file, and you’ll have to provide that path.
MCP Client & AI Model Compatibility
Again:****** This stack is not limited to Claude Desktop or the Sonnet model. Any MCP-compatible client or model can follow this tutorial — I’m using that combination since it’s what my friend already has installed.
You could even run this locally with any model capable of handling tool calls. Just know that I’ve seen that smaller models (~8B parameter range and below) tend to struggle with this.
That’s it then, let’s dive right in.
Building An Effective Research Pipeline
Here’s how I orchestrate these three MCP servers through a prompt that handles multi-source research intelligence.
This is a pretty big flowchart. 😅 Take your time.
Press enter or click to view image in full size
Press enter or click to view image in full size
Press enter or click to view image in full size
Step 1: Check Memory Before Doing Anything
Here’s how we’ll start.
I want to research [TOPIC]. Execute this workflow:
### Step 1 - Check Existing Knowledge
Use the Knowledge Graph MCP (`search_nodes`) to check if there are already [TOPIC]-related entities or sources in memory.
- Query with key terms related to your research topic
- Return any existing nodes and relations (papers, books, articles, experts, concepts, institutions)
// more to come later
This seems obvious, but it’s solving two problems at once.
- I’m not burning tool calls re-fetching data I already have.
- I’m building on previous research instead of treating every query like a blank slate.
💡 Pro Tip: Use phrasing like “[TOPIC]-related” instead of exact matches. Academic papers use different terminology for the same concepts. Letting the model use a fuzzy search will catch related work that might use “machine learning” vs “artificial intelligence” vs “deep learning” for overlapping research.
That search_nodes tool is part of the Knowledge graph MCP. We’ll look at how it works (and how it helps us) in a bit. For now, just think of this first part of the prompt like a cache we check first for hits. Only on a miss do we continue with the actual workflow.
Step 2 & 3: Domain-Aware Source Routing
Instead of searching everything (which is wasteful, and prone to poisoning) I built three distinct research pipelines to route queries to specialized endpoints based on the topic being searched, and what it needs:
- Track A: Biomedical Gold Standard —
biomcp→ PubMed, FDA data, clinical trials, pharma data, and more. - Track B: STEM Cutting Edge —
simple-arxiv→ Preprints 6–18 months ahead - Track C: General purpose research —
Bright Data→ Anything else, plus broader context as a follow up
This conditional is a good demonstration of how we leverage the actual LLM as the glue between our 3 MCP servers. We first let our LLM (Sonnet 4, here) classify the topic, then tell it the right tools to use + how to use them, based on that classification.
### Step 2 : Classify the topic
Before anything, check what kind of topic this is.
### STEP 3 : Find Latest Information
- Does the topic relate to medicine, genetics, pharmaceuticals, or clinical research? Then:
- Use biomcp MCP server to find recent peer-reviewed articles, clinical trials, and genetic variants
- Get the 5 most recent papers
- If any of the papers or journals retrieved does not have a brief, or full content:
- Use Bright Data's scrape_as_markdown to extract full content from its PMID link
- If you didn’t find a PMID link, use Bright Data’s search_engine to query for the DOI. Then, use scrape_as_markdown to extract that page’s full content.
- Does the topic relate to mathematics, physics, astronomy, electrical engineering, computer science, quantitative biology, statistics, mathematical finance, or economics? Then:
- Use simple-arxiv MCP server to search for preprints
- Get the 5 most recent papers
- For any of those arXiv paper found:
- Use Bright Data's scrape_as_markdown to extract content of its arXiv full text HTML link
- Else (or if the previous two tracks didn't yield anything relevant):
- Use Bright Data's search_engine to find recent and authoritative sources on the topic from the last 6-12 months:
- Search academic databases, news sources, and authoritative websites
- Use Bright Data's scrape_as_markdown to extract content of the top 5 most relevant results
- Prioritize: peer-reviewed papers, reputable publications, expert analyses, official reports
- Collect these metadata: title, authors, publication date, URL, source type, publication venue
// more to come later
TL;DR: Explicitly state the “strength” and “risk” of each track — this primes your model to understand the credibility hierarchy. It’s a good-enough default to follow.
I’m explicitly trading off recency vs. credibility based on the research domain. Change this based on your specific needs, or if you want to fetch more than just the most recent paper (I get 5 at a time in the production version of this prompt).
I did it this way because the most relevant information will vary depending on the field. in biomedical research, there’s a clear hierarchy: systematic reviews beat RCTs beat cohort studies beat case reports. But for cutting-edge AI research, for example, the most important work often appears on arXiv months before journal publication.
The rest of the flow is pretty self-explanatory — I’m exploiting the domain-aware MCPs to get the full-text links to papers/journals, and then using Bright Data to fetch their full contents as markdown. Geoblocks, dynamic content, CAPTCHA are resolved automatically.
Step 4 — Deduplication: Keeping the Graph Clean
💡 If all you need is one-off searches with no persistent store or follow-up questions, this step is optional. You’re already done. Skip to Step 6, run the prompt, enjoy!
So we know we’re going to need a knowledge graph to model and store this raw data.
But if you’ve ever tried building a research assistant, you know duplicates are the silent killer.
- The same paper can show up in arXiv and PubMed.
- Authors’ names can be spelled differently across datasets.
- A single work can generate multiple nodes if you don’t normalize.
Every duplicate fragments the graph and breaks the intelligence layer — you end up with “half-truths” scattered across nodes instead of a single connected entity. So before doing anything with the knowledge graph, we have to fix this.
Why Deduplication Matters
Imagine storing research for the Mona Lisa under three separate nodes:
source__mona_lisasource__la_giocondasource__paintings_by_da_vinci
Your assistant wouldn’t know they’re the same painting. Citations, relationships, and insights would all be split apart. That’s what happens if we don’t normalize.
The Canonical ID Strategy
To avoid this, I enforce deterministic, human-readable IDs. A few examples:
| Case | Canonical ID Example | Notes |
| :--- | :--- | :--- |
| PubMed journal article | `source__nejm_2023_gene_editing` | Venue + year + title words |
| arXiv preprint | `source__arxiv_2021_2101.12345` | Use official arXiv ID |
| arXiv → journal | Link with `precedes_publication` | Don’t collapse into one node |
| News article | `source__nyt_2024_crispr_breakthrough` | Outlet + year + headline words |
| Author | `expert__jane_doe_oncology` | Name + domain disambiguation | human-readable, so when I’m debugging why two papers didn’t link properly, I can actually read the IDs and figure out what went wrong.
TL;DR: Every claim must resolve to one canonical source node, not spawn a new duplicate. These rules aren’t perfect, but they prevent most of the fragmentation.
Here’s the full prompt I use. This should give you enough to be able to design one based on your own needs.
### Step 4 - Deduplication & Canonical Matching
**1. Generate Deterministic IDs:**
For each entity type, create stable IDs using this format:
- **Sources**: `source__[venue_slug]_[year]_[first_3_words_of_title]`
- Academic: "source__nature_2024_attention_mechanisms_survey"
- arXiv: "source__arxiv_2024_neural_memory_architectures"
- News: "source__nyt_2024_ai_breakthrough_reported"
- **Concepts**: `concept__[concept_name_lowercase_underscored]`
- Example: "concept__transformer_attention_mechanisms"
- **Domains**: `domain__[field_name_lowercase_underscored]`
- Example: "domain__machine_learning" or "domain__theoretical_physics"
- **Experts**: `expert__[last_name]_[first_name]_[specialization]`
- Example: "expert__lecun_yann_deep_learning"
**2. Check for Existing Duplicates:**
Before creating any entity, use `search_nodes` to check if it already exists:
- Search by the generated canonical ID
- Search by exact title match
- Search by URL, DOI, or arXiv ID (for academic sources)
- Search by author name and year (for expert entities)
- **Special for arXiv**: Check if the same paper later appeared in a journal (cross-reference by authors + similar title)
**3. Handle Duplicates:**
- **If exact ID found**: Skip creation, instead add new observations to existing entity using `update_entity`
- **If similar title found** (manually assess if >80% similar): Update existing entity rather than create new one
- **For arXiv→Journal transitions**: Link as related papers rather than duplicating
- **If no match found**: Create new entity with the canonical ID
Which brings us to the knowledge graph — let’s quickly give you a primer on that next.
TL;DR: Knowledge Graph
What it is: A local graph database provided by our MCP server that gives Claude persistent memory for research data.
Three core components:
- Entities are your core nodes — anything worth remembering gets an entity.
{
"name": "source__nature_2024_crispr_safety",
"entityType": "research_source",
"observations": [
"peer_review_status: peer_reviewed",
"evidence_level: systematic_review",
"credibility_level: high"
]
}
- Observations are atomic facts attached to entities (as strings). Instead of dumping everything into a description field, each discrete piece of information gets its own observation. This makes the knowledge queryable — I can ask “show me all high-credibility sources on CRISPR safety” and get precise results.
- Relations connect entities in meaningful ways:
{
"from": "expert__doudna_jennifer_crispr",
"to": "source__nature_2024_crispr_safety",
"relationType": "authored_paper"
}
Why it matters:
Instead of treating every research query like a blank slate, Claude builds up searchable knowledge over time. You can ask “show me all high-credibility CRISPR papers” and get precise results based on stored metadata, not hallucinations.
The payoff:
Runs locally, gets smarter with use, enables complex follow-up questions like “which papers cite both study A and study B?”
Got all that? Great. Let’s move on with the tutorial.
Step 5 — Knowledge Graph Schema
TL;DR: Once duplicates are under control, the next step is deciding what kinds of entities and relationships we actually store. This schema is what makes the assistant more than just a search tool.
The Core Graph (Minimal Viable Setup)
This can be as simple or complex as you want. I figure you only need three entity types to start:
- Sources → papers, preprints, news articles
- Concepts → ideas, techniques, diseases, compounds
- Experts → authors, labs, organizations
And three relationships:
cites(source → source)mentions(source → concept)authored_by(source → expert)
That’s enough to ask useful follow-up questions like:
- “Which papers cite both study A and study B?”
- “Who are the top authors on compound Z?”
- “Which concepts link protein X to disease Y?”
So your minimal viable prompt for this would look like:
### Step 5 - Create/Update Core Graph Entities
**A. Source Entity**
- `id`: "source__[venue_or_platform]_[year]_[short_title]"
- `name`: Human-readable title
- `entityType`: "research_source"
- `observations`:
- "source_type: {paper|preprint|news}"
- "title: ..."
- "authors: ..."
- "url: ..."
**B. Concept Entity**
- `id`: "concept__[normalized_concept_name]"
- `name`: "{Concept_Name}"
- `entityType`: "concept"
- `observations`:
- "basic_description: short explanation of this concept"
**C. Expert Entity**
- `id`: "expert__[lastname_firstname]"
- `name`: "{Expert_Name}"
- `entityType`: "expert"
- `observations`:
- "affiliation: {institution if known}"
### Step 5B - Relationships
Always use canonical IDs:
- `source__arxiv_2024_attention → cites → source__nature_2023_transformers`
- `source__arxiv_2024_attention → mentions → concept__attention_mechanisms`
- `source__arxiv_2024_attention → authored_by → expert__vaswani_ashish`
And you’re done. You could use this and be fine for most use cases (and you can move on to Step 6).
For a much more useful research assistant, however, you’d need something more. Here’s what I do:
[OPTIONAL] The Extended Graph For Better Analysis
For deeper research intelligence, I add many other optional fields and relationships:
- Domains (e.g. medicine, physics) → for query routing
- Observations on sources:
credibility_level(peer-reviewed, preprint, news)research_phase(preclinical, clinical trial, published application)controversy_level(low, medium, high)- Temporal links:
precedes_publication(connect preprint → final journal version) - Expert influence:
collaborated_with,affiliated_with - And more.
Here’s how I implement mine. Use this as a template to design your own.
### Step 5 - Create/Update Entities with Enhanced Structure
**A. Create/Update Source Entity:**
- `id`: Use canonical format: `source__[venue]_[year]_[title_keywords]`
- `name`: Human-readable: "{Topic}_{SubArea}_{ContentType}_{Year}"
- `entityType`: "research_source"
- `observations`:
- `"source_type: {pubmed_paper|preprint|clinical_trial|news_article|book|report|interview|patent}"`
- `"peer_review_status: {peer_reviewed|preprint_not_reviewed|under_review|clinical_protocol|unknown}"`
- `"methodology: {experimental_study|clinical_trial|theoretical_analysis|literature_review|case_study|survey|meta_analysis}"`
- `"research_phase: {basic_research|preclinical|phase1|phase2|phase3|approved|post_market}"`
- `"evidence_level: {systematic_review|rct|cohort_study|case_series|expert_opinion|preliminary}"`
- `"topic_focus: {specific_subtopic_or_theme}"`
- `"credibility_level: {high|medium|low}"`
- `"recency_relevance: {cutting_edge|current|historical|timeless}"`
- `"content_depth: {comprehensive|overview|specialized|introductory}"`
- `"research_maturity: {preliminary_results|established_findings|mature_field|speculative}"`
- `"citation_risk: {high_novelty_unvalidated|medium_risk|well_established|controversial}"`
- **For PubMed**: `"pmid: [PMID]"`, `"doi: [DOI]"`, `"journal_impact: [high|medium|low]"`
- **For arXiv**: `"arxiv_id: [arXiv:XXXX.XXXXX]"`, `"submission_date: [date]"`
- **For Clinical Trials**: `"nct_number: [NCT########]"`, `"trial_phase: [I|II|III|IV]"`, `"enrollment_size: [number]"`
- any other relevant observation about this source extracted from this source
- Standard metadata: `"title: ..."`, `"authors: ..."`, `"url: ..."`, etc.
**B. Create/Update Concept Entity:**
- `id`: Use canonical format: `concept__[normalized_concept_name]`
- `name`: "{Concept_Name}"
- `entityType`: "concept"
- `observations`:
- `"concept_maturity: {emerging|developing|established|mature|declining}"`
- `"theoretical_vs_practical: {purely_theoretical|mixed|highly_practical}"`
- `"complexity_level: {basic|intermediate|advanced|expert}"`
- `"research_velocity: {rapidly_evolving|steady_progress|slow_development|stagnant}"`
- `"controversy_level: {consensus|minor_debates|major_debates|highly_controversial}"`
- `"interdisciplinary_scope: {single_field|cross_disciplinary|broadly_applicable}"`
- any other relevant observation about this concept extracted from this source
**C. Create/Update Domain Entity:**
- `id`: Use canonical format: `domain__[normalized_field_name]`
- `name`: "{Field_Name}"
- `entityType`: "knowledge_domain"
- `observations`:
- `"field_maturity: {emerging|established|mature|transforming}"`
- `"arxiv_category: {cs.AI|math.NA|physics.ML|econ.TH|etc}"`
- `"research_activity_level: {very_high|high|medium|low}"`
- `"commercial_relevance: {high|medium|low|academic_only}"`
- `"breakthrough_potential: {revolutionary|significant|incremental}"`
- `"methodology_preferences: {theoretical|experimental|computational|empirical}"`
- any other relevant observation about this domain extracted from this source
**D. Create/Update Expert Entity:**
- `id`: Use canonical format: `expert__[lastname_firstname_specialization]`
- `name`: "{Expert_Name}_{Specialization}"
- `entityType`: "expert_authority"
- `observations`:
- `"expertise_level: {world_leading|highly_recognized|established|emerging}"`
- `"institutional_affiliation: {university|tech_company|research_lab|independent}"`
- `"publication_pattern: {frequent_arxiv|traditional_journals|mixed|books_primarily}"`
- `"influence_type: {theoretical_breakthroughs|practical_applications|both}"`
- `"collaboration_network: {highly_collaborative|selective|independent}"`
- any other relevant observation about this expert extracted from this source
**E. Create Enhanced Relationships:**
Always reference entities by their canonical IDs:
- `source__arxiv_2024_attention → explores_concept → concept__attention_mechanisms`
- `source__arxiv_2024_attention → precedes_publication → source__nature_2025_attention` (if same work published later)
- `expert__lecun_yann_deep_learning → frequently_publishes_on_arxiv → domain__machine_learning`
- `concept__transformer_attention → rapidly_evolving_in → domain__natural_language_processing`
- `source__arxiv_2024_paper_a → builds_upon → source__arxiv_2024_paper_b` (citation relationships)
- any other relevant relationship extracted from this source
### Step 5B - Enhanced Deduplication Guidelines
**arXiv-Specific Deduplication:**
- Same paper on arXiv and later in journal: Create relationship `precedes_publication` rather than duplicate
- Multiple arXiv versions (v1, v2, v3): Update existing entity with version notes
- Conference papers that become arXiv preprints: Link as `related_work`
**Cross-Platform Matching:**
Consider equivalent:
- "Transformer Attention Mechanisms" (Nature) vs "Attention in Transformers" (arXiv)
- Same author set + similar core concepts + similar timeframe
**Author Disambiguation:**
- "Y. LeCun" vs "Yann LeCun" vs "Yann A. LeCun" → same expert entity
- Use institutional affiliation + research area to resolve ambiguity
Why This Matters
My expanded design makes Claude store a Source for a research topic (Say, “CRISPR”) like so:
{
"type": "entity",
"name": "CRISPR_Clinical_Trials_2025",
"entityType": "source",
"observations": [
"source_type: pubmed_paper",
"peer_review_status: peer_reviewed",
"evidence_level: systematic_review",
"research_phase: approved",
"credibility_level: high",
"citation_risk: well_established",
"Research type: comprehensive clinical translation review",
"Methodology: systematic analysis of CRISPR clinical trials and regulatory approvals",
"Target application: various genetic diseases and cancer therapies",
"Innovation level: established technology with expanding clinical applications",
"Clinical relevance: extremely high - covers approved therapies and ongoing trials",
"Research stage: clinical implementation and regulatory approval",
"Technical focus: base editing, prime editing, delivery systems, safety profiles",
"Model system: clinical trials across multiple disease areas",
"PMID: 40160040",
"DOI: 10.1017/erm.2024.32",
"Journal: Expert Reviews in Molecular Medicine",
"Publication date: 2025-03-31",
"Authors: Cetin B, Erendor F, Eksi YE, Sanlioglu AD, Sanlioglu S",
"Key findings: First FDA-approved CRISPR therapy (Casgevy); expanding clinical applications; ongoing challenges with delivery and off-target effects"
]
}
Thanks to our knowledge graph MCP server’s tools, now I can ask Claude “Show me all the high-risk citations in oncology research” and instantly retrieve sources tagged explicitly with citation_risk: high_novelty_unvalidated rather than letting the LLM decide.
This lets me query intelligently, with no hallucinations:
- “What are the most credible, peer-reviewed papers on CRISPR safety?” → pulls things explicitly marked as
credibility_level: highandpeer_review_status: peer_reviewed. - “Show me the earliest, still-preliminary results on CRISPR applications.” → surfaces
evidence_level: preliminary. - “Which Phase 2 clinical trials are testing new gene therapies?” → resolves exactly to
research_phase: phase2. - “Find me preprints with medium credibility on microbiome–immune interactions.” → maps to
source_type: preprintandcredibility_level: medium.
Similarly, for Concepts, interactions between gut bacteria and their human host would be depicted in my knowledge graph as:
{
"type": "entity",
"name": "concept__gut_microbiome_host_interactions",
"entityType": "concept",
"observations": [
"concept_maturity: developing",
"research_velocity: rapidly_evolving",
"controversy_level: minor_debates",
"theoretical_vs_practical: mixed",
"definition: The dynamic relationships between gut microbial communities and the human host's physiology",
"key_components: Bacteria, archaea, viruses, fungi, and their metabolic byproducts",
"research_significance: Central to understanding digestion, immune modulation, and metabolic health",
"scholarly_approach: Systems biology integrating microbiology, immunology, and metabolomics",
"experimental_evidence: Metagenomic sequencing, germ-free mouse models, fecal microbiota transplantation",
"historical_context: Recognition since early 20th century of gut bacteria's role in nutrient absorption",
"biomedical_implications: Links to obesity, diabetes, autoimmune disorders, and neurological diseases",
"contemporary_relevance: Microbiome-targeted interventions such as probiotics, prebiotics, and dietary therapies",
"methodological_innovation: Shotgun metagenomics and machine learning for microbial community analysis",
"clinical_impact: Emerging microbiome-based diagnostics and therapeutics influencing precision medicine"
]
}
And for Experts. Noted Renaissance expert Ann Pizzorusso would be depicted in my knowledge graph like this:
{
"type": "entity",
"name": "Ann Pizzorusso",
"entityType": "expert_authority",
"observations": [
"expertise_level: highly_recognized",
"institutional_affiliation: independent",
"publication_pattern: mixed",
"influence_type: theoretical_breakthroughs",
"collaboration_network: selective",
"specialization: Geological analysis of Renaissance art",
"notable_work: Tweeting Da Vinci (2014 book)",
"recent_discovery: Identification of Lecco as Mona Lisa background location",
"methodology: Combined geological and art historical analysis",
"previous_research: Analysis of Virgin of the Rocks paintings at Louvre and National Gallery"
]
}
By using this schema for modeling relationships in my knowledge graph, I’m no longer staring at a jumble of unstructured notes. I can immediately see which relationships were present in my raw research data.
For example, after I researched “Mona Lisa”, here’s what relationship entities looked like in my graph:
{"type":"relation","from":"source__smithsonian_2023_mona_lisa_chemical_analysis","to":"concept__mona_lisa_scientific_analysis","relationType":"contributes_to"}
{"type":"relation","from":"source__smithsonian_2023_mona_lisa_chemical_analysis","to":"expert__victor_gonzalez_chemist","relationType":"authored_by"}
{"type":"relation","from":"source__guardian_2024_mona_lisa_location_discovery","to":"expert__ann_pizzorusso_geologist_art_historian","relationType":"features_research_by"}
{"type":"relation","from":"source__guardian_2024_mona_lisa_location_discovery","to":"concept__mona_lisa_scientific_analysis","relationType":"contributes_to"}
{"type":"relation","from":"expert__victor_gonzalez_chemist","to":"domain__art_conservation_science","relationType":"works_in"}
{"type":"relation","from":"expert__ann_pizzorusso_geologist_art_historian","to":"domain__art_conservation_science","relationType":"works_in"}
{"type":"relation","from":"concept__mona_lisa_scientific_analysis","to":"concept__renaissance_painting_techniques","relationType":"reveals_insights_about"}
{"type":"relation","from":"concept__renaissance_painting_techniques","to":"domain__art_conservation_science","relationType":"studied_within"}
{"type":"relation","from":"source__npr_2025_mona_lisa_louvre_move","to":"concept__mona_lisa_scientific_analysis","relationType":"contextualizes"}
What This Unlocks:
Now, the LLM has concrete data to tell me that:
- The Smithsonian 2023 chemical analysis paper contributes to the broader concept of Mona Lisa scientific analysis, and it is authored by Victor Gonzalez (chemist).
- The Guardian 2024 discovery piece features research by Ann Pizzorusso (geologist + art historian) and also contributes to the same Mona Lisa scientific analysis concept.
- Both Gonzalez and Pizzorusso are explicitly tied to the art conservation science domain, showing their shared disciplinary context.
- The Mona Lisa scientific analysis concept itself is shown to reveal insights about Renaissance painting techniques, which in turn are studied within the art conservation science domain.
- Even coverage like the NPR 2025 story about moving the painting is captured — it contextualizes the ongoing scientific analysis, giving me cultural and historical framing.
None of these are hallucinations. All answers are grounded in citable fact.
Don’t get too caught up in this. You can absolutely get away with a far less complex schema for modeling knowledge graphs! Just use the minimal viable one. I only hope my example gives you a mental model of how to design a similar knowledge graph for whatever fits your needs best.
Step 6: From Data Collection to Research Intelligence
We’re pretty much done. The final steps are just for…output, really. This is where the knowledge graph with our structured entity schema really pays off.
### Step 6 - Comprehensive Research Intelligence Output
Before generating the analysis:
- Every factual claim must be mapped to an existing `source` node in the Memory MCP (via `search_nodes`).
- If no mapping exists, explicitly state “No supporting data available” instead of including the claim.
- Always cite the mapped source ID (PubMed ID, DOI, arXiv ID, or URL).
Generate the complete research analysis by:
A. Source Analysis:
- Summarize each source (arXiv → preprint format, Journals → APA style, News → AP style)
- Use search_nodes to identify thematic connections, overlaps, and contradictions across sources
- Classify sources into quality tiers:
- Tier 1: Peer-reviewed, high-credibility
- Tier 2: arXiv preprints, preliminary but promising
- Tier 3: News/popular sources, cultural context
B. Provide Research Intelligence:
- Executive Summary: Key findings from the research data
- Research Timeline: Recent developments from cutting-edge to established
- Expert Authority Mapping: Key researchers and their influence networks
- Concept Maturity Assessment: Which ideas are ready for application vs. still developing
- Cross-Disciplinary Insights: How concepts transfer between domains
- Knowledge Gaps & Opportunities: Areas for future research
- Risk-Adjusted Recommendations: What to trust vs. what needs validation
- Strategic Research Directions: Next steps based on cutting-edge developments
- Complete References: Properly formatted citations for all sources
Just like relationship modeling, feel free to tweak your prompt here to ask for output exactly how you want it.
Maybe you just need a quick fact-check, not a full research briefing like I did. But when you’re starting a new research area or need to inform colleagues, having all this structured intelligence in one place is probably incredibly valuable.
💡 The citation formatting matters more than you’d think. Academic readers expect arXiv preprints formatted differently than peer-reviewed papers. Getting this right signals that the system understands academic conventions, not just text processing.Also, the stratification here uses all those structured observations I built earlier. Remember
credibility_levelandevidence_level? Now they’re powering automatic source ranking that helps researchers understand what they can trust.
This kind of nuanced credibility assessment is exactly what my friend researching bioinformatics needed. He can now build on solid foundations while being appropriately cautious about cutting-edge claims.
The key thing to remember is that I’m not just building a better search engine — I’m building a research reasoning system that understands academic credibility, tracks intellectual development over time, and can make risk-adjusted recommendations about what to trust.
Real-World Performance
I’ve been testing this on everything from biomedical research to art history and so far, it’s knocking it out of the park.
Let’s look a run-through of a full workflow from prompt to cited answer — let’s say we want to research latest developments about CRISPR, a cutting-edge DNA/gene editing topic.
What’s Happening Here
- You’ll see that biomcp’s internal
thinktool was called first — this is the recommended approach that the biomcp creators advise. - Then, it correctly used its
article_searcherto retrieve the latest CRISPR publications (including preprints and journal articles), andtrial_searcherto identify currently open clinical trials related to CRISPR therapies. - It even identified that one of the clinical trials fetched was more about COPD treatment than core CRISPR, so it discarded it and fetched a new one beyond the original “latest 5 only” cutoff.
- After identifying the most relevant items, it switched to Bright Data’s
scrape_as_markdownto pull down the full content of those papers and trial records, so the assistant had the actual text to work with rather than just abstracts or metadata. - Finally, it ran the Knowledge Graph MCP’s
search_nodestool to check for duplicates in the local knowledge graph, thencreate_entitiesandcreate_relationsto store structured representations of those sources, concepts, and expert links.
With all context built, the assistant moved on to synthesis and produced a properly cited research intelligence report, with everything I asked for.
Here’s a non-exhaustive list of questions my assistant can now answer because of the complex graph modeling:
- How did attention mechanisms migrate from NLP into protein design research?
- Who are the top five experts publishing in CRISPR research, and where are they affiliated?
- Which findings are still preliminary vs. validated in later-phase CRISPR trials?
- What’s the chronological path of clinical trials on CRISPR since 2021?
- Which AI subfields are currently intersecting with biomedical CRISPR research?
See? The more effort you put into modelling your knowledge graph, the more it’ll pay off.
Key Takeaways
Here’s what I learnt putting this together:
- MCP servers are surprisingly composable —Very impressed with the current state and variety of MCP servers available. The Bright Data MCP offering 5000 tool calls per month was perfect. That’s almost 5 times that of any other search server’s free tier, and it saves you from having to pack a Puppeteer MCP every time. Claude Desktop (with Sonnet 4) handles orchestration well with these tools if prompted correctly.
- Domain-specific MCP servers are crucial —Wherever possible, you want to get peer reviewed, expert data rather than relying on SERP results. If your research is mission-critical, the Google frontpage is just not as reliable these days.
- Deduplication and well-designed knowledge graphs are make-or-break — without canonical IDs and persistent, complex relationships, a research assistant is not that useful for real-world work.
There are also some flaws with this stack as it stands :
- Having Sonnet classify queries into Track A/B/C is clever, but it’s still relying on an LLM and classification drift can happen (e.g. a biomedical AI paper could land in either Track B or Track A). I will eventually need a thin deterministic router MCP that uses domain keywords instead of pure LLM judgment. 🤔 Or code my own.
- The knowledge graph stores it all in a JSON file. This is fine for small-to-medium projects, but I’m guessing as soon as I start adding thousands of entities and relationships, querying with
search_nodeswill bog down. I’ll probably need to back this with a lightweight graph DB layer (Neo4j/Dgraph/Weaviate) eventually. Thankfully, they all have MCP servers too.
These are fragilities that a tiny normalization MCP to enforce IDs and dedup rules would fix. That way I’m not just depending on prompt determinism. As a project built in one weekend, though, I’m happy with this “Version 1.0" as it stands.
Anyway, the goal isn’t to replace human research, just to augment it. This research assistant handles the grunt work of finding sources, extracting key information, and maintaining citation integrity. Humans still need to synthesize insights, identify research gaps, and make strategic decisions about what to investigate further.
If you’re building research tools or dealing with LLM hallucination in academic work, I hope my stack helps you out :)