Sider Scholar

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"}

⚠️ 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)

⚠️ 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)

⚠️ 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)

⚠️ 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)

Internal APP fetch tool for accessing internal APIs

⚡ 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.

🎯 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.

Generate a non-hierarchical, network-based knowledge graph visualization.

display use's 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.

⚠️ 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

⚠️ 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)

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.

🎯 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'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.

⚠️ 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.

get file list from Wisebase

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

upload file to Wisebase