Sider Scholar

Your AI Research Assistant lets you search 350M+ research papers, chat with large volumes of research PDFs, and save findings to your Wisebase (knowledge base). 1. Global Academic Search (Search & Read) - Major Sources: Search 350M+ papers from Google Scholar, PubMed, arXiv, and more. - Read Instantly: Access full papers instantly to verify findings. 2. Build Your Knowledge Base (Save & Collect) - Save for Continuous Research: Save searched papers to Wisebase for continuous questioning and deep analysis of your findings. - Save Chat History: Save key research discussions as editable documents to capture and refine insights. 3. Unified Knowledge Analysis (Agentic RAG) - Chat with Your Collection: Analyze your entire collection simultaneously. - Traceable Sources: Get grounded answers with precise Reference Indices to verify every claim. 4. Visual Knowledge Organization (Visualize & Explore) - Knowledge Graphing: Instantly generate interactive graphs from any paper to explore definitions, cause-and-effect links, and concept hierarchies. Ideal Use Cases: For researchers, PhD students, and academics who need to access massive academic sources and synthesize grounded arguments with precise citations. How to Use in ChatGPT 1. Connect App: Connect Sider Scholar to ChatGPT. 2. Trigger: Type “@Sider Scholar". Sample Prompts - Search Paper: “@Sider Scholar Search recent papers on 'LLM alignment' published in the last two years.” - Chat with Knowledge Base: “@Sider Scholar Answer questions about 'CRISPR gene editing' using my Knowledge Base.” - Visual Research: “@Sider Scholar Build a Knowledge Graph explaining key concepts in 'Reinforcement Learning'.”

View in the ChatGPT registry

Integration type: Plugin
Verification status: Not applicable
Platform: ChatGPT
Category: Education
Primary Subcategory: Academic Literature Search & Research Assistants
Secondary Subcategories: None listed
Brand: Sider
Access: Account required
First tracked: 2026-08-04
Tool count: 20
Geography: US

ChatGPT Plugin Discoverability Score

ChatGPT organic discovery is not live yet

Sider Scholar is tracked in the ChatGPT Plugin registry. Public organic-discovery measurement is not live for ChatGPT yet, so there is no score to publish today.

Get notified when your score goes live

Enter your work email and we’ll notify you when ChatGPT Plugin organic discovery scoring launches.

No spam. Unsubscribe any time.

Talk to our team

Primary Subcategory

Competing in ChatGPT Academic Literature Search & Research Assistants

View Category

Listed in alphabetical order

Primary Subcategory

Agentic Search by LinerOrganic discovery is pendingGet the score at launch

alphaXivOrganic discovery is pendingGet the score at launch

Article GalaxyOrganic discovery is pendingGet the score at launch

NYCU LibraryOrganic discovery is pendingGet the score at launch

Precise Special FunctionsOrganic discovery is pendingGet the score at launch

Sider ScholarOrganic discovery is pendingGet the score at launch

Score explained

How the Discoverability Score works

Organic discovery scoring for Sider Scholar on ChatGPT is not live yet. The score will use measured agent conversations when it launches.

InvisibleBuriedEmergingCompetitiveWinning

Organic discovery scoring is pending. Your Plugin score will appear on this scale when measurement goes live.

FoundDiagnostic

Whether Claude found your Plugin in connector search. It must be Found before it can reach the picker, but the score counts picker appearances—not search results.

PickedMain score

How often your Plugin appeared in the picker, or Claude invoked it directly, across contested conversations. This percentage is the Discoverability Score; the headline number is rounded.

PositionedDiagnostic

What position your Plugin appeared in when it was shown in the picker. This shows prominence, but it does not affect the score.

Read the full scoring methodology Recommended guideHow to get your Claude Connector organically discoveredFollow the practical steps agents use to find, shortlist, and choose your Connector.

Tools

20 tools agents can invoke

Use this for complex OpenAlex searches with multiple field-specific criteria combined with boolean operators. **What it does:** - Constructs sophisticated multi-field queries for OpenAlex - Combines multiple search criteria with AND/OR logic - Searches specific fields (title, author, abstract, institution, etc.) - Provides maximum precision for complex research questions **When to use:** - User wants papers matching MULTIPLE specific criteria - Need to search different fields with different terms - Complex queries like "papers about X by author Y from institution Z" - User wants to combine title search + author search + date filter - Systematic reviews requiring precise inclusion criteria **How to use:** - query_parts: Array of {field, query} objects Examples: * [{field: "title", query: "neural networks"}, {field: "author.display_name", query: "LeCun"}] * [{field: "abstract", query: "deep learning"}, {field: "authorships.institutions.display_name", query: "MIT"}] - boolean_operator: "AND" (all must match) or "OR" (any can match) - filters: Additional filters like publication date - sort: Sorting preference - per_page/page: Pagination **Returns:** Same as search_open_access_works - list of matching papers. **Example:** Find papers with "climate change" in title AND "machine learning" in abstract from 2023+: query_parts=[{field:"title", query:"climate change"}, {field:"abstract", query:"machine learning"}] boolean_operator="AND" filters={"from_publication_date": "2023-01-01"}
advanced_search
Internal APP fetch tool for accessing internal APIs
fetch
⚡ TARGETED FILE RETRIEVAL TOOL - Use when you have specific file IDs ⚡ **PRIMARY USE CASE**: When file IDs are explicitly provided or known (e.g., from user context, previous searches, or document references). **✅ WHEN TO USE THIS TOOL:** - File IDs are specified in the user's request or context - You need to retrieve information from SPECIFIC documents (not the entire knowledge base) - User asks to analyze/summarize/query PARTICULAR files - Prompts explicitly mention using "files_rag_answer" tool - Working with a targeted subset of documents - Following up on specific papers/documents from previous operations **❌ WHEN NOT TO USE (use wisebase_rag_answer instead):** - No specific file IDs are available - Need to search across the ENTIRE knowledge base - Exploratory search without file constraints - Multi-round iterative retrieval needed **🎯 ADVANTAGES:** - Direct, focused retrieval from specified files - Faster response time (no multi-round iteration) - Precise control over search scope - Better for specific document analysis **INPUT REQUIREMENTS:** - fileIds: Array of target file IDs (REQUIRED - must have at least one) - question: Your search query or question **CRITICAL**: If you have file IDs available in the context, YOU MUST use this tool instead of wisebase_rag_answer.
files_rag_answer
⚠️ LAST RESORT - Use ONLY if both get_open_access_work AND url_extract fail. **PREFERRED ALTERNATIVES (in order):** 1. get_open_access_work (use paper ID from search results) - BEST 2. url_extract (use PubMed URL) - SECOND CHOICE 3. pubmed_work_info (this tool) - LAST RESORT ONLY **What it does:** - Fetches paper info directly from PubMed/PMC via NCBI APIs - Has rate limits and slower than get_open_access_work - Returns basic metadata: title, abstract, DOI, journal, dates **When to use (RARE):** - get_open_access_work failed (paper not in OpenAlex) - url_extract failed on PubMed URL - User provides only a PMID and get_open_access_work didn't work **How to use:** - identifier: PMID, PMC ID, DOI, or paper title - id_type: "pmid", "pmc", "doi", or "title" **Returns:** {title, abstract, pdf_link, full_text_link, journal, pub_date, issn} **🎯 CRITICAL WORKFLOW:** 1. Have paper ID → get_open_access_work 2. If fails → url_extract with PubMed URL 3. If still fails → pubmed_work_info (this tool)
pubmed_work_info
🎯 **SCHOLAR'S PAPER LOOKUP TOOL** - Use this for getting detailed information about a single paper. Superior to all platform-specific fulltext tools. **What it does:** - Retrieves complete metadata for a single paper from OpenAlex (250M+ papers indexed) - Accepts DOI, PMID, or OpenAlex ID from previous search results - Returns comprehensive details: all authors, institutions, citations, references, related works, PDF links - Cheapest option for single paper lookups, no rate limits, better data quality than platform-specific tools **⭐ HIGHEST PRIORITY for single paper lookups!** **When to use:** - You have a paper identifier (DOI, PMID, OpenAlex ID) from a previous search result - User says "tell me more about this paper" (use ID from context) - User wants detailed information about a specific paper - Need full author list, institution details, or citation data for one paper - **ALWAYS use this instead of pubmed_work_info/arxiv_work_info/biorxiv_work_info** **When NOT to use:** - User doesn't have a paper ID yet → use search_open_access_works first - Searching for papers (not looking up a specific one) → use search tools **How to use:** - identifier: Usually comes from previous search results (results[0]["id"] or results[0]["doi"]) * OpenAlex ID: "W2124808589" (from search results) * DOI: "10.1038/s41586-023-12345-6" (from search results) * PMID: "36878453" (from search results) **Returns:** Complete paper object with all metadata, authors, institutions, citations, referenced_works, related_works, credibility indicators. **🎯 WORKFLOW:** 1. Search finds papers → results contain IDs 2. Use get_open_access_work with that ID for full details 3. NEVER use pubmed_work_info/arxiv_work_info/biorxiv_work_info if this works **💰 COST:** Cheapest option for single paper details - No rate limits, superior data.
get_open_access_work
⚠️ LAST RESORT - Use ONLY if both get_open_access_work AND url_extract fail. **PREFERRED ALTERNATIVES (in order):** 1. get_open_access_work (use DOI/OpenAlex ID from search) - BEST 2. url_extract (use arXiv URL) - SECOND CHOICE 3. arxiv_work_info (this tool) - LAST RESORT ONLY **What it does:** - Fetches paper from arXiv by arXiv ID - Has rate limits **When to use (RARE):** - get_open_access_work failed - url_extract failed on arXiv URL - User provides arXiv ID specifically **Parameters:** - arxiv_id: arXiv ID like "2301.12345" **Returns:** {status, data: {id, title, summary, authors, published, pdf_url}} **🎯 WORKFLOW:** 1. get_open_access_work → 2. url_extract → 3. arxiv_work_info (last resort)
arxiv_work_info
⚠️ LAST RESORT - Use ONLY if both get_open_access_work AND url_extract fail. **PREFERRED ALTERNATIVES (in order):** 1. get_open_access_work (use DOI from search) - BEST 2. url_extract (use bioRxiv URL) - SECOND CHOICE 3. biorxiv_work_info (this tool) - LAST RESORT ONLY **What it does:** - Fetches paper from bioRxiv API - Has rate limits **When to use (RARE):** - get_open_access_work failed - url_extract failed on bioRxiv URL **Parameters:** - biorxiv_id: bioRxiv DOI or title - id_type: "doi" or "title" **Returns:** {identifier, id_type, paper: {metadata}} **🎯 WORKFLOW:** 1. get_open_access_work → 2. url_extract → 3. biorxiv_work_info (last resort)
biorxiv_work_info
🎯 Use this for all Google Scholar academic searches. **What it does:** - Searches Google Scholar database (includes papers from all publishers, indexed content) - Returns papers with titles, snippets, publication info, citation counts, and links - Includes both open-access and paywalled papers (shows access status) - Fast and reliable for academic literature searches **When to use:** - User wants scholarly articles from Google Scholar - Need to check citation counts for papers - User asks for papers by specific authors - Looking for well-known, highly-cited works - Literature reviews and research tasks - User asks "find papers on X" or "search for research about Y" **Parameters:** - query: Search terms (required) - language: Language code (default "en", supports "zh-CN" for Chinese) - year_start/year_end: Filter by publication year range - sorted: false for relevance (default), true for date - count: Number of results (default 5, recommend 20+ for comprehensive searches) **Returns:** List of papers with title, authors, snippet, publication_info, citation count, links, and resource type (PDF/HTML/Book). **⭐ RECOMMENDED:** Use count=20 or higher for comprehensive search results.
scholar_search
Generate a non-hierarchical, network-based knowledge graph visualization.
knowledge_graph
display use's knowledge graph list.
knowledge_graph_list
When a user wants to create a document that they intend to save for future use, this tool should be invoked to analyze and generate the document according to the user's instructions; after the user confirms, the save function will then be called. Otherwise, the save function should not be invoked without the user's permission.
prepare_chat_for_saving
The model **must not actively invoke this tool** during the conversation. This tool is only intended to be triggered by the frontend via `window.openai.calltool` **after** `chat-save-preparation` has been called, and it is used **solely for saving files that have already been edited**. Therefore: - The model **must not call this tool directly** in its reasoning or responses. - The timing and logic for invoking this tool are **entirely controlled by the frontend**, and are independent of any tool calls produced by the model.
save_edited_document
🎯 **SCHOLAR'S PRIMARY SEARCH TOOL** - Use this FIRST for all academic searches. Cheapest option, fast, and covers 250M+ papers from Scholar's OpenAlex integration. **What it does:** - Direct search of OpenAlex database (world's largest open catalog of scholarly works) - Works best with simple keyword searches (2-5 keywords) - Supports optional simple filters (mostly used WITHOUT filters) - Allows sorting by date, citations, or relevance - Returns comprehensive paper metadata with DOIs, PDFs, citations, authors, institutions **⭐ DEFAULT CHOICE:** Use this for 90% of academic searches! **When to use (ALWAYS try this first):** - User wants papers on any topic: "find papers about brain-computer interfaces" - Simple keyword searches (you extract keywords from user query) - Basic year filtering if needed (one filter dimension) - Sorting by citations or date - ANY academic search unless it requires complex multi-dimensional filtering **How to use:** - query: Simple keywords (2-5 words) - YOU extract these from user's natural language Examples: "brain computer interface", "climate change mitigation", "CRISPR gene editing" - filters: OPTIONAL - Use sparingly, usually OMIT this Simple examples: {"from_publication_date": "2024-01-01"} or {"institutions.display_name": "MIT"} Database filter: {"locations.source.display_name": "PubMed"} or "arXiv" or "bioRxiv" - sort: "publication_date:desc" (newest first), "cited_by_count:desc" (most cited), or null for relevance - per_page: 25-200 (default 25) **Returns:** {meta: {count, per_page, page}, results: [{id, doi, title, authors, abstract, citations, pdf_url, institutions, credibility}]} **🎯 CRITICAL WORKFLOW:** 1. User asks for papers → extract keywords → search_open_access_works (CHEAPEST) 2. If needs complex multi-filter → smart_open_access_search (EXPENSIVE) 3. Never use smart_open_access_search for simple queries **Database-specific searches:** Use filters to target specific databases: filters={"locations.source.display_name": "PubMed"/"arXiv"/"bioRxiv"} This replaces pubmed_search, arxiv_search, biorxiv_search for most cases! **💰 COST:** Cheapest option - No extra API costs, no AI parsing needed.
search_open_access_works
⚠️ RARELY NEEDED - Use search_open_access_works with PubMed filter instead! Only use this for NCBI-specific databases beyond PubMed. **PREFERRED ALTERNATIVE:** search_open_access_works(query="your keywords", filters={"locations.source.display_name": "PubMed"}) This gives better results and includes OpenAlex metadata! **What it does:** - Direct search of NCBI databases (PubMed, PMC, Gene, Protein, etc.) - Returns PubMed-specific summaries with PMIDs - Provides MeSH terms and NCBI-specific metadata **When to use (RARE):** - User explicitly asks for "NCBI Gene database" or "NCBI Protein database" (non-PubMed NCBI) - Need MeSH terms specifically - User wants to search PMC, Gene, or Protein databases - search_open_access_works fails after trying with PubMed filter **When NOT to use:** - General medical/biological paper searches → use search_open_access_works - User says "find PubMed papers" → use search_open_access_works with PubMed filter (better!) **Parameters:** - query: Search query - database: "pubmed" (default), "pmc", "gene", "protein" - max_results: Default 10 **Returns:** {search_results: {count, query_key, webenv}, summaries: {pmid: {metadata}}} **🎯 WORKFLOW:** 1. User wants PubMed → search_open_access_works with PubMed filter 2. Only use pubmed_search if they need Gene/Protein databases
pubmed_search
⚠️ RARELY NEEDED - Use search_open_access_works with arXiv filter instead! **PREFERRED ALTERNATIVE:** search_open_access_works(query="your keywords", filters={"locations.source.display_name": "arXiv"}) This gives better results with OpenAlex metadata! **What it does:** - Direct search of arXiv preprint repository - Covers physics, math, CS, and related fields - Returns arXiv-specific IDs and metadata **When to use (RARE):** - User explicitly says "search arXiv directly" or "use arXiv API" - search_open_access_works with arXiv filter fails - Need arXiv-specific XML metadata **When NOT to use:** - User wants arXiv papers → use search_open_access_works with arXiv filter (better!) - General physics/CS/math search → use search_open_access_works **Parameters:** - query: Search terms - start: Pagination index (default 0) - max_results: Number of results (default 10) **Returns:** {status, data: [{id, title, summary, authors, published, pdf_url}]} **🎯 WORKFLOW:** User wants arXiv → search_open_access_works + arXiv filter (preferred)
arxiv_search
⚠️ RARELY NEEDED - Use search_open_access_works with bioRxiv filter instead! **PREFERRED ALTERNATIVE:** search_open_access_works(query="your keywords", filters={"locations.source.display_name": "bioRxiv"}) Better results with OpenAlex metadata! **What it does:** - Direct search of bioRxiv preprint server - Title-only matching (limited) - Has rate limits **When to use (RARE):** - User explicitly says "search bioRxiv directly" - search_open_access_works with bioRxiv filter fails **When NOT to use:** - User wants bioRxiv papers → use search_open_access_works with bioRxiv filter (better!) **Parameters:** - query: Search terms (title matching) - year_start/year_end: Year range - sorted: true for date sort - count: Results (default 20) **Returns:** {query, results: [{paper metadata}]} **🎯 WORKFLOW:** User wants bioRxiv → search_open_access_works + bioRxiv filter (preferred)
biorxiv_search
⚠️ EXPENSIVE TOOL - Use ONLY when complex multi-dimensional filtering is required. Prefer search_open_access_works for simple searches. **What it does:** - Uses AI (OpenAI API call - COSTS MONEY) to parse natural language into structured OpenAlex filters - Automatically determines complex filter combinations across multiple dimensions - Handles queries requiring simultaneous filtering by year + citations + institution + author + journal - Searches OpenAlex with AI-optimized parameters **⚠️ COST WARNING:** Each call makes an OpenAI API request. Use sparingly! **When to use (RARE cases only):** - User needs COMPLEX filtering with 3+ dimensions that would be hard to manually specify - Query requires intelligent interpretation of ambiguous filter requirements - Example: "highly cited papers on AI from top universities published after 2020" (needs citation filter + institution filter + date filter) - User query has multiple contradictory or nuanced filtering requirements **When NOT to use (MOST cases):** - Simple keyword searches → use search_open_access_works (FREE, FAST) - Basic year filtering → use search_open_access_works with filters param - Single filter dimension → use search_open_access_works - User just wants "papers about X" → use search_open_access_works **How to use:** - query: Natural language research question (AI will parse it) - per_page/page: Pagination (defaults fine) **Returns:** Same as search_open_access_works - list of papers with metadata. **🎯 PRIORITY:** ALWAYS try search_open_access_works FIRST. Only use this if the query genuinely requires complex multi-dimensional filtering that you cannot construct manually.
smart_open_access_search
An agentic RAG (Retrieval-Augmented Generation) system for iterative, multi-round knowledge retrieval. ⚠️ CRITICAL: This is NOT a single-call tool. You MUST call it multiple times (up to 20 rounds allowed). **MANDATORY ITERATION PROTOCOL:** 1. Call the tool with your initial query 2. Receive 'passages' and 'should_continue' flag 3. IF 'should_continue' is TRUE → YOU MUST CALL AGAIN WITH A DIFFERENT QUERY - Read and analyze ALL passages to understand what information you got - Identify what's MISSING or unclear from current passages - Generate a COMPLETELY DIFFERENT query from a NEW ANGLE - Call the tool again immediately - Do NOT answer the user's question yet 4. IF 'should_continue' is FALSE → You have enough information to answer **🔥 CRITICAL: Query Diversity Requirements** Each new query MUST be SUBSTANTIALLY DIFFERENT from previous ones to avoid duplicate results: ❌ BAD (too similar): - Round 1: "user book acquisition" - Round 2: "user acquiring books" ← Same concept, will get duplicate results! ✅ GOOD (different angles): - Round 1: "user book acquisition" → general discussion - Round 2: "PDF reader features personalization" → technical features angle - Round 3: "reading behavior patterns analysis" → behavioral angle - Round 4: "book recommendation algorithms" → algorithmic angle **How to generate DIVERSE queries:** 1. **Different aspects**: If Round 1 was about "what", try "how", "why", "when", "who" 2. **Different granularity**: Broad overview → specific details → edge cases 3. **Different perspectives**: User view → system view → business view 4. **Different domains**: Features → behavior → architecture → performance 5. **Complementary info**: If got "benefits", ask about "challenges" or "implementation" **Required analysis before each new query:** Before calling again, you MUST: 1. Summarize key themes from current passages 2. List what topics/angles are MISSING 3. Choose ONE missing angle to explore 4. Formulate query targeting ONLY that new angle 5. Ensure new query uses DIFFERENT keywords than before **Example multi-round with diverse queries:** Round 1: "user book acquisition methods" → Got: General discussion about users getting books ✓ Covered: Basic concepts, user workflows ✗ Missing: Specific features, technical implementation Round 2: "PDF reading features personalization customization" → Got: Feature descriptions, customization options ✓ Covered: Features, UI/UX aspects ✗ Missing: User behavior data, usage patterns Round 3: "reading behavior PDF vs web statistics" → Got: Behavioral comparisons, usage statistics ✓ Covered: User behavior, comparison data ✗ Missing: Technical architecture, system design Round 4: "knowledge base architecture search retrieval" → Got: System design, technical implementation ✓ should_continue = false → NOW comprehensive coverage **REMEMBER:** - Same query = same results = wasted call! - Each query should explore a NEW dimension/angle - Analyze passages content, not just count - should_continue: true = MANDATORY different query - should_continue: false = Stop and answer - more then 5 rounds allowed
wisebase_rag_answer
get file list from Wisebase
wisebase_file_list
upload file to Wisebase
wisebase_upload

Sider Scholar FAQ

How do I improve a ChatGPT Plugin's discoverability?

The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.

What are Sider Scholar alternatives on ChatGPT?

As of 2026-08-14, Sider Scholar competes with Agentic Search by Liner, alphaXiv, Article Galaxy, NYCU Library, Precise Special Functions, Scholar Gateway, SciSpace, Scite, Tailo Lens, Undermind in ChatGPT Academic Literature Search & Research Assistants, ranked by public Discoverability Score.

Where is this profile measured?

This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.