Searches arXiv for academic references and generates BibTeX citations.
Searches dblp for academic references and generates BibTeX citations.
Searches Semantic Scholar for academic references and generates BibTeX citations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BibTeX MCP Server search for papers on quantum computing from 2022"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Multi-provider academic reference search with BibTeX generation. Searches arXiv, DBLP, Semantic Scholar, and OpenAlex concurrently.
For Claude Desktop, ChatGPT, or other MCP clients:
Server URL: https://mcp.florianbrand.de/sse
Transport: SSE (Server-Sent Events)
Authentication: None required
Related MCP server: Literature Review Assistant
This server is hosted publicly at: https://mcp.florianbrand.de/sse
Important: Use the URL exactly as shown above (without www subdomain)
If you prefer to run the server locally, you can add it the following way:
{
"mcpServers": {
"bibtex": {
"command": "uv",
"args": ["run", "--directory", "/path/to/bibtex-mcp", "python", "-m", "reference_mcp", "--stdio"],
"env": {
"SEMANTIC_SCHOLAR_API_KEY": "your_api_key_here"
}
}
}
}A semantic scholar API key is optional but recommended for higher rate limits. It can be requested here.
Fetch a single document by ID.
This is designed for ChatGPT compatibility which expects a single ID parameter.
Args: id: Document ID from previous search results
Returns: Dictionary containing the full document with id, title, text (BibTeX + abstract)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format (dictionary with id, title, text containing BibTeX and abstract) and notes it expects a single ID parameter. However, it does not mention error behavior (e.g., what happens if the ID is not found), rate limits, or permissions. For a read-only fetch, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose stated first, followed by a brief note on compatibility, and then structured Args and Returns sections. Every sentence adds value, though the compatibility note could be seen as extra context rather than essential usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with one parameter and no output schema, the description covers the essential information: what it does, what the parameter means, and what it returns. It lacks error handling details, but for a basic fetch operation, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'id' as a string with no description, and schema description coverage is 0%. The description adds meaningful context by specifying 'Document ID from previous search results', which tells the agent exactly where the ID comes from and its format expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetch a single document by ID' which is a specific verb and resource. It clearly distinguishes from siblings like search_reference and search (which search) and fetch_multiple (which fetches multiple), by emphasizing 'single document'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context by noting this is for ChatGPT compatibility and that the ID comes from previous search results, implying when to use it. However, it does not explicitly state when not to use it or mention alternatives like fetch_multiple, though the sibling names and the 'single' wording make the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full documents for previously searched references.
This is the precision step - returns complete BibTeX records and abstracts for documents identified by the search tool.
Args: ids: List of document IDs from previous search results
Returns: Dictionary mapping IDs to full document text (BibTeX + abstract)
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the burden of describing behavior, and it does by stating the exact return contract: a dictionary mapping each ID to full document text with BibTeX plus abstract. It does not cover invalid-ID/error behavior, but for a read-only fetch operation the disclosed output behavior is substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three clearly labeled short sections (summary, Args, Returns) with no filler. The precision-step framing is front-loaded and every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For one required parameter and no output schema, the description supplies the necessary return shape and usage context. However, it refers ambiguously to 'the search tool' when two search-like siblings exist (search and search_reference), and it omits any error or edge-case behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only gives 'ids' as a string array, so the description adds the crucial meaning that these are document IDs from previous search results. It does not discuss uniqueness or validity, but this fully compensates for the 0% schema coverage for a single simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('full documents') and explains this is the precision step after searching, which separates it from search-oriented siblings. It does not explicitly contrast with the sibling 'fetch', so the single-vs-multiple distinction is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: call this after a search, with IDs from previous search results, to get complete BibTeX records and abstracts. It stops short of explicitly stating when not to use it or naming the alternative for single-document retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search academic literature and return lightweight results for browsing.
This is the recall step - returns compact metadata to help decide which documents to fetch. Natural language queries work best for semantic search across academic databases.
Args: query: Search terms (paper titles, author names, keywords)
Returns: Dictionary with 'results' key containing list of search results. Each result includes: id, title, and snippet (text preview).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it does disclose core behavior: semantic search across academic databases, compact metadata rather than full text, and a dictionary under the 'results' key with id/title/snippet fields. It stops short of describing result limits, ordering, or error behavior, but the core behavioral contract is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: it states the purpose in the first sentence, then the workflow role, query guidance, and return format. There is minor redundancy between 'lightweight results' and 'compact metadata,' but no filler or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with no output schema, the description covers the important parts: purpose, query semantics, and return structure. The main gaps are lack of differentiation from search_reference and no mention of result limits or pagination, but these are not critical for a lightweight recall tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section defines 'query' as search terms and gives concrete examples (paper titles, author names, keywords), adding real meaning beyond the bare string type. It does not document formatting constraints, but there is only one required parameter and its intent is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search academic literature') and a concrete output ('lightweight results for browsing'), so an agent understands what the tool does. It frames the tool as the 'recall step' returning compact metadata, which differentiates it from the fetch siblings, but it does not explicitly distinguish it from the similarly named sibling search_reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly situates the tool in a workflow: this is the recall step, meant to help decide which documents to fetch. It also advises that natural language queries work best, which is actionable guidance. It does not name explicit alternatives or state when not to use it, but the context is sufficient for most calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search academic literature databases (DBLP, Semantic Scholar, arXiv, OpenAlex) to find research papers and return properly formatted BibTeX citations.
Use this tool when the user needs:
Academic citations for research papers, articles, or publications
BibTeX entries for bibliography management
Information about specific papers (authors, venue, publication year, abstract)
Literature search results from computer science and AI databases
The tool automatically searches all major academic databases, deduplicates results, and ranks by relevance. Each result includes complete bibliographic metadata and a ready-to-use BibTeX citation.
Args: query: Academic search terms (paper titles, author names, years or any combination of them yields the best results). max_results: Number of results to return (1-100, default 20). Use lower values (5-10) for focused searches. year: Optional year filter. If provided, returns papers published in this year. author: Optional author name filter. If provided, returns papers by authors matching this name.
Returns: Dictionary with query, total_results count, and array of references containing: - Complete bibliographic data (title, authors, year, venue, DOI, etc.) - Abstract text when available - Formatted BibTeX citation ready for use - Citation count - Source databases that found this reference
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| query | Yes | ||
| author | No | ||
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states that the tool automatically searches all major databases, deduplicates results, ranks by relevance, and returns complete metadata, abstracts, BibTeX, citation counts, and source databases. This gives an accurate behavioral model beyond the schema, though it omits failure modes or rate-limit considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well organized into clear sections: purpose, when-to-use, behavior, args, and returns. Each section serves a distinct decision point, and front-loading the core purpose helps an agent parse quickly. There is minor redundancy in repeating the BibTeX outcome, but nothing is extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates by specifying the return dictionary structure and the fields each reference contains. It also covers all input parameters and the automatic multi-database behavior. It omits edge cases like missing metadata or pagination, but the core invocation contract is fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does. For query it explains what terms work best; for max_results it gives range and focused-search guidance; for year and author it states the filtering behavior. All four parameters carry meaning beyond their bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search academic literature databases (DBLP, Semantic Scholar, arXiv, OpenAlex) to find research papers and return properly formatted BibTeX citations.' This clearly distinguishes the tool from generic siblings like 'search' and 'fetch' by naming the academic databases and the BibTeX output format, so an agent can identify it uniquely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'Use this tool when the user needs' block covering academic citations, BibTeX entries, paper metadata, and literature search results. This gives an agent clear context for when to invoke it, but it doesn't name any alternative tools or explicitly state when not to use it, leaving a small differentiation gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0fetchfetch_multiplesearchsearch_referenceScored across 4 tools
The search and search_reference tools both perform literature searches but with different output granularity. While search_reference returns full BibTeX and search returns lightweight snippets, the boundary is fuzzy and an agent might misselect them. fetch and fetch_multiple are clearly distinct in cardinality.
Tool names follow mixed patterns: search_reference uses verb_noun, while fetch, search, and fetch_multiple are bare verbs or verb_adjective. There is no consistent convention, and the verbs 'search' and 'fetch' could be seen as overlapping actions.
Four tools is well-scoped for a bibliographic reference server. Each tool serves a clear purpose in the search-fetch workflow, and the count is within the ideal range, neither too thin nor bloated.
The tool set covers the core search and retrieval lifecycle: lightweight browsing (search), bulk full retrieval (fetch_multiple), and direct full citation lookup (search_reference). Missing features like DOI lookup or format export are minor and not critical for the stated purpose.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Scholarly search: OpenAlex, Crossref, arXiv, OpenCitations and PubMed in one endpoint.
