MCP-DBLP
MCP-DBLP
대규모 언어 모델(LLM)을 위해 DBLP 컴퓨터 과학 서지 데이터베이스에 대한 액세스를 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다(AI4SC @ AAAI-26에 채택된 관련 논문).
개요
MCP-DBLP는 모델 컨텍스트 프로토콜을 통해 DBLP(Digital Bibliography & Library Project) API를 LLM과 통합하여 AI 모델이 다음을 수행할 수 있도록 합니다:
DBLP 데이터베이스에서 학술 출판물 검색 및 검색
인용 처리 및 BibTeX 항목 생성
출판물 제목 및 저자 이름에 대한 퍼지 매칭 수행
서지 정보 추출 및 형식 지정
문서에 포함된 참조 처리
LLM 처리를 우회하여 정확도를 극대화하는 직접적인 BibTeX 내보내기
Related MCP server: ArXiv-MCP
기능
불리언 쿼리를 사용한 포괄적인 검색 기능
제목 및 저자 이름 퍼지 매칭
DBLP에서 직접 BibTeX 항목 검색
연도 및 장소별 출판물 필터링
출판물 데이터의 통계 분석
LLM 처리를 우회하여 정확도를 극대화하는 직접적인 BibTeX 내보내기 기능
사용 가능한 도구
도구 이름 | 설명 |
| 사용 지침 및 워크플로우 안내 받기 |
| 불리언 쿼리를 사용하여 DBLP에서 출판물 검색 |
| 퍼지 제목 매칭을 사용하여 출판물 검색 |
| 특정 저자의 출판물 검색 |
| 출판 장소에 대한 자세한 정보 얻기 |
| DBLP 키를 사용하여 컬렉션에 BibTeX 항목 추가 |
| 수집된 모든 BibTeX 항목을 .bib 파일로 내보내기 |
피드백
이 양식을 통해 작성자에게 피드백을 제공해 주세요.
시스템 요구 사항
Python 3.11+
설치
Claude Code
간단히 다음을 실행하세요:
claude mcp add mcp-dblp -- uvx mcp-dblpClaude Desktop
Claude Desktop 구성 파일에 추가하세요:
macOS/Linux:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"mcp-dblp": {
"command": "uvx",
"args": ["mcp-dblp"]
}
}
}소스에서 설치 (개발용)
git clone https://github.com/szeider/mcp-dblp.git
cd mcp-dblp
uv venv && source .venv/bin/activate
uv pip install -e .그런 다음 Claude Desktop을 다음과 같이 구성하세요:
{
"mcpServers": {
"mcp-dblp": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-dblp/", "run", "mcp-dblp"]
}
}
}지침
사용 지침은 get_instructions 도구를 통해 확인할 수 있습니다. 주요 워크플로우 포인트는 도구 설명에 나와 있습니다. 자세한 내용은 도구를 호출하세요. instructions_prompt.md도 참조하세요.
도구 세부 정보
search
불리언 쿼리 문자열을 사용하여 DBLP에서 출판물을 검색합니다.
매개변수:
query(문자열, 필수): 'and' 및 'or' 불리언 연산자를 포함할 수 있는 쿼리 문자열 (대소문자 구분 안 함)max_results(숫자, 선택 사항): 반환할 최대 출판물 수. 기본값은 10year_from(숫자, 선택 사항): 출판 연도 하한year_to(숫자, 선택 사항): 출판 연도 상한venue_filter(문자열, 선택 사항): 출판 장소에 대한 대소문자 구분 없는 부분 문자열 필터 (예: 'iclr')include_bibtex(불리언, 선택 사항): 결과에 BibTeX 항목을 포함할지 여부. 기본값은 false
fuzzy_title_search
퍼지 제목 매칭을 사용하여 DBLP에서 출판물을 검색합니다.
매개변수:
title(문자열, 필수): 출판물의 전체 또는 부분 제목 (대소문자 구분 안 함)similarity_threshold(숫자, 필수): 0에서 1 사이의 부동 소수점 값 (1.0은 정확히 일치함을 의미)max_results(숫자, 선택 사항): 반환할 최대 출판물 수. 기본값은 10year_from(숫자, 선택 사항): 출판 연도 하한year_to(숫자, 선택 사항): 출판 연도 상한venue_filter(문자열, 선택 사항): 출판 장소에 대한 대소문자 구분 없는 부분 문자열 필터include_bibtex(불리언, 선택 사항): 결과에 BibTeX 항목을 포함할지 여부. 기본값은 false
get_author_publications
퍼지 매칭을 사용하여 특정 저자의 출판물 세부 정보를 검색합니다.
매개변수:
author_name(문자열, 필수): 전체 또는 부분 저자 이름 (대소문자 구분 안 함)similarity_threshold(숫자, 필수): 0에서 1 사이의 부동 소수점 값 (1.0은 정확히 일치함을 의미)max_results(숫자, 선택 사항): 반환할 최대 출판물 수. 기본값은 20include_bibtex(불리언, 선택 사항): 결과에 BibTeX 항목을 포함할지 여부. 기본값은 false
get_venue_info
출판 장소에 대한 자세한 정보를 검색합니다.
매개변수:
venue_name(문자열, 필수): 장소 이름 또는 약어 (예: 'ICLR' 또는 전체 이름)
add_bibtex_entry
나중에 내보낼 수 있도록 컬렉션에 BibTeX 항목을 추가합니다.
매개변수:
dblp_key(문자열, 필수): 검색 결과의 DBLP 키 (예: "conf/nips/VaswaniSPUJGKP17")citation_key(문자열, 필수): .bib 파일에서 사용할 인용 키 (예: "Vaswani2017")
동작:
제공된 키를 사용하여 DBLP에서 직접 BibTeX 항목을 가져옵니다.
인용 키를 사용자 지정 키로 바꿉니다.
세션 컬렉션에 추가합니다 (중복 키는 덮어씀).
컬렉션 수와 함께 즉각적인 성공/실패 피드백을 반환합니다.
실패한 개별 항목을 다시 시도할 수 있습니다.
export_bibtex
수집된 모든 BibTeX 항목을 .bib 파일로 내보냅니다.
매개변수:
path(문자열, 필수): .bib 파일의 절대 경로 (예: "/path/to/refs.bib")
동작:
add_bibtex_entry를 통해 추가된 모든 항목을 지정된 경로에 저장합니다.누락된 경우 .bib 확장자가 자동으로 추가됩니다.
필요한 경우 상위 디렉토리가 생성됩니다.
성공적으로 내보낸 후 컬렉션을 지웁니다.
저장된 파일의 전체 경로를 반환합니다.
컬렉션이 비어 있으면 오류를 반환합니다.
중요 참고: BibTeX 항목은 10초 시간 초과 보호와 함께 DBLP에서 직접 가져오며, LLM에 의해 처리, 수정 또는 환각되지 않습니다. 이는 서지 데이터의 정확성과 신뢰성을 극대화합니다. 지정된 대로 인용 키만 수정됩니다. 요청 시간이 초과되면 오류 메시지가 반환되고 항목은 컬렉션에 추가되지 않습니다.
예시
입력 텍스트:
Our exploration focuses on two types of explanation problems, abductive and contrastive, in local and global contexts (Marques-Silva 2023). Abductive explanations (Ignatiev, Narodytska, and Marques-Silva 2019), corresponding to prime-implicant explanations (Shih, Choi, and Darwiche 2018) and sufficient reason explanations (Darwiche and Ji 2022), clarify specific decision-making instances, while contrastive explanations (Miller 2019; Ignatiev et al. 2020), corresponding to necessary reason explanations (Darwiche and Ji 2022), make explicit the reasons behind the non-selection of alternatives. Conversely, global explanations (Ribeiro, Singh, and Guestrin 2016; Ignatiev, Narodytska, and Marques-Silva 2019) aim to unravel models' decision patterns across various inputs.
출력 텍스트:
Our exploration focuses on two types of explanation problems, abductive and contrastive, in local and global contexts \cite{MarquesSilvaI23}. Abductive explanations \cite{IgnatievNM19}, corresponding to prime-implicant explanations \cite{ShihCD18} and sufficient reason explanations \cite{DarwicheJ22}, clarify specific decision-making instances, while contrastive explanations \cite{Miller19}; \cite{IgnatievNA020}, corresponding to necessary reason explanations \cite{DarwicheJ22}, make explicit the reasons behind the non-selection of alternatives. Conversely, global explanations \cite{Ribeiro0G16}; \cite{IgnatievNM19} aim to unravel models' decision patterns across various inputs.
출력 Bibtex
All references have been successfully exported to a BibTeX file at: /absolute/path/to/bibtex/20250305_231431.bib
@article{MarquesSilvaI23,
author = {Jo{\~{a}}o Marques{-}Silva and
Alexey Ignatiev},
title = {No silver bullet: interpretable {ML} models must be explained},
journal = {Frontiers Artif. Intell.},
volume = {6},
year = {2023},
url = {https://doi.org/10.3389/frai.2023.1128212},
doi = {10.3389/FRAI.2023.1128212},
timestamp = {Tue, 07 May 2024 20:23:47 +0200},
biburl = {https://dblp.org/rec/journals/frai/MarquesSilvaI23.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@inproceedings{IgnatievNM19,
author = {Alexey Ignatiev and
Nina Narodytska and
Jo{\~{a}}o Marques{-}Silva},
title = {Abduction-Based Explanations for Machine Learning Models},
booktitle = {The Thirty-Third {AAAI} Conference on Artificial Intelligence, {AAAI}
2019, The Thirty-First Innovative Applications of Artificial Intelligence
Conference, {IAAI} 2019, The Ninth {AAAI} Symposium on Educational
Advances in Artificial Intelligence, {EAAI} 2019, Honolulu, Hawaii,
USA, January 27 - February 1, 2019},
pages = {1511--1519},
publisher = {{AAAI} Press},
year = {2019},
url = {https://doi.org/10.1609/aaai.v33i01.33011511},
doi = {10.1609/AAAI.V33I01.33011511},
timestamp = {Mon, 04 Sep 2023 12:29:24 +0200},
biburl = {https://dblp.org/rec/conf/aaai/IgnatievNM19.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@inproceedings{ShihCD18,
author = {Andy Shih and
Arthur Choi and
Adnan Darwiche},
editor = {J{\'{e}}r{\^{o}}me Lang},
title = {A Symbolic Approach to Explaining Bayesian Network Classifiers},
booktitle = {Proceedings of the Twenty-Seventh International Joint Conference on
Artificial Intelligence, {IJCAI} 2018, July 13-19, 2018, Stockholm,
Sweden},
pages = {5103--5111},
publisher = {ijcai.org},
year = {2018},
url = {https://doi.org/10.24963/ijcai.2018/708},
doi = {10.24963/IJCAI.2018/708},
timestamp = {Tue, 20 Aug 2019 16:19:08 +0200},
biburl = {https://dblp.org/rec/conf/ijcai/ShihCD18.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@inproceedings{DarwicheJ22,
author = {Adnan Darwiche and
Chunxi Ji},
title = {On the Computation of Necessary and Sufficient Explanations},
booktitle = {Thirty-Sixth {AAAI} Conference on Artificial Intelligence, {AAAI}
2022, Thirty-Fourth Conference on Innovative Applications of Artificial
Intelligence, {IAAI} 2022, The Twelveth Symposium on Educational Advances
in Artificial Intelligence, {EAAI} 2022 Virtual Event, February 22
- March 1, 2022},
pages = {5582--5591},
publisher = {{AAAI} Press},
year = {2022},
url = {https://doi.org/10.1609/aaai.v36i5.20498},
doi = {10.1609/AAAI.V36I5.20498},
timestamp = {Mon, 04 Sep 2023 16:50:24 +0200},
biburl = {https://dblp.org/rec/conf/aaai/DarwicheJ22.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@article{Miller19,
author = {Tim Miller},
title = {Explanation in artificial intelligence: Insights from the social sciences},
journal = {Artif. Intell.},
volume = {267},
pages = {1--38},
year = {2019},
url = {https://doi.org/10.1016/j.artint.2018.07.007},
doi = {10.1016/J.ARTINT.2018.07.007},
timestamp = {Thu, 25 May 2023 12:52:41 +0200},
biburl = {https://dblp.org/rec/journals/ai/Miller19.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@inproceedings{IgnatievNA020,
author = {Alexey Ignatiev and
Nina Narodytska and
Nicholas Asher and
Jo{\~{a}}o Marques{-}Silva},
editor = {Matteo Baldoni and
Stefania Bandini},
title = {From Contrastive to Abductive Explanations and Back Again},
booktitle = {AIxIA 2020 - Advances in Artificial Intelligence - XIXth International
Conference of the Italian Association for Artificial Intelligence,
Virtual Event, November 25-27, 2020, Revised Selected Papers},
series = {Lecture Notes in Computer Science},
volume = {12414},
pages = {335--355},
publisher = {Springer},
year = {2020},
url = {https://doi.org/10.1007/978-3-030-77091-4\_21},
doi = {10.1007/978-3-030-77091-4\_21},
timestamp = {Tue, 15 Jun 2021 17:23:54 +0200},
biburl = {https://dblp.org/rec/conf/aiia/IgnatievNA020.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@inproceedings{Ribeiro0G16,
author = {Marco T{\'{u}}lio Ribeiro and
Sameer Singh and
Carlos Guestrin},
editor = {Balaji Krishnapuram and
Mohak Shah and
Alexander J. Smola and
Charu C. Aggarwal and
Dou Shen and
Rajeev Rastogi},
title = {"Why Should {I} Trust You?": Explaining the Predictions of Any Classifier},
booktitle = {Proceedings of the 22nd {ACM} {SIGKDD} International Conference on
Knowledge Discovery and Data Mining, San Francisco, CA, USA, August
13-17, 2016},
pages = {1135--1144},
publisher = {{ACM}},
year = {2016},
url = {https://doi.org/10.1145/2939672.2939778},
doi = {10.1145/2939672.2939778},
timestamp = {Fri, 25 Dec 2020 01:14:16 +0100},
biburl = {https://dblp.org/rec/conf/kdd/Ribeiro0G16.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}면책 조항
이 MCP-DBLP는 프로토타입 단계에 있으므로 주의해서 사용해야 합니다. 사용자는 실험을 권장하지만, 중요한 환경에서의 사용은 전적으로 사용자의 책임입니다.
라이선스
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 LICENSE 파일을 참조하세요.
Available Tools
6 toolscalculate_statisticsA
Calculate statistics from a list of publication results. Arguments:
results (array, required): An array of publication objects, each with at least 'title', 'authors', 'venue', and 'year'. Returns a dictionary with:
total_publications: Total count.
time_range: Dictionary with 'min' and 'max' publication years.
top_authors: List of tuples (author, count) sorted by count.
top_venues: List of tuples (venue, count) sorted by count (empty venue is treated as '(empty)').
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return structure (a dictionary with specific keys) and behavioral details like how empty venues are treated. However, it doesn't mention error handling, performance aspects (e.g., for large arrays), or side effects. The description adds some context but isn't comprehensive.
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 appropriately sized and front-loaded with the purpose, followed by structured details on arguments and returns. Every sentence earns its place by clarifying inputs and outputs, though it could be slightly more concise by integrating the argument list into the flow rather than as a separate bullet.
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?
Given 1 parameter with 0% schema coverage and no output schema, the description does well by fully explaining the parameter and return values. It covers the tool's complexity adequately, though it could improve by adding usage context or error scenarios. The lack of annotations and output schema is compensated by the detailed description.
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 fully. It provides detailed semantics for the single parameter 'results', specifying it as an array of publication objects with required fields ('title', 'authors', 'venue', 'year'). This adds significant meaning beyond the bare schema, fully documenting the parameter's structure and expectations.
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 clearly states the tool's purpose: 'Calculate statistics from a list of publication results.' It specifies the verb ('calculate') and resource ('statistics'), but doesn't explicitly differentiate from siblings like 'search' or 'get_author_publications' which have different functions. The purpose is clear but lacks sibling comparison.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing publication data first), exclusions, or compare to siblings like 'export_bibtex' or 'get_venue_info'. Usage is implied from the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_bibtexA
Export BibTeX entries from a collection of HTML hyperlinks. Arguments:
links (string, required): HTML string containing one or more key links. The href attribute should contain a URL to a BibTeX file, and the link text is used as the citation key. Example input with three links: "Smith2023 Jones2022 Brown2021" Process:
For each link, the tool fetches the BibTeX content from the URL
The citation key in each BibTeX entry is replaced with the key from the link text
All entries are combined and saved to a .bib file with a timestamp filename Returns:
A message with the full path to the saved .bib file
| Name | Required | Description | Default |
|---|---|---|---|
| links | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the process: fetching BibTeX content from URLs, replacing citation keys, saving to a timestamped .bib file, and returning the file path. It covers key behaviors like network fetching and file creation, though it omits details like error handling or rate limits.
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 well-structured with sections for Arguments, Process, and Returns, making it easy to parse. It is appropriately sized, with each sentence adding value, though it could be slightly more concise by integrating the example more seamlessly.
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?
Given the complexity (network fetching, file creation) and lack of annotations or output schema, the description is largely complete. It explains the process, parameter usage, and return value. However, it could improve by mentioning potential errors (e.g., invalid URLs) or file format specifics.
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. It provides detailed semantics for the single parameter 'links', including its type, requirement, format (HTML string with <a> tags), example, and how the href and link text are used. This adds significant meaning beyond the basic schema.
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 clearly states the tool exports BibTeX entries from HTML hyperlinks, specifying the exact verb ('export'), resource ('BibTeX entries'), and source ('collection of HTML hyperlinks'). It distinguishes from sibling tools like 'get_author_publications' or 'search' by focusing on BibTeX extraction from links rather than general searches or author-specific queries.
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 implies usage when BibTeX entries need to be exported from HTML links, but it does not explicitly state when to use this tool versus alternatives like 'fuzzy_title_search' or 'get_author_publications'. It provides an example input, which helps clarify context, but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fuzzy_title_searchA
Search DBLP for publications with fuzzy title matching. Arguments:
title (string, required): Full or partial title of the publication (case-insensitive).
similarity_threshold (number, required): A float between 0 and 1 where 1.0 means an exact match.
max_results (number, optional): Maximum number of publications to return. Default is 10.
year_from (number, optional): Lower bound for publication year.
year_to (number, optional): Upper bound for publication year.
venue_filter (string, optional): Case-insensitive substring filter for publication venues.
include_bibtex (boolean, optional): Whether to include BibTeX entries in the results. Default is false. Returns a list of publication objects sorted by title similarity score.
| Name | Required | Description | Default |
|---|---|---|---|
| include_bibtex | No | ||
| max_results | No | ||
| similarity_threshold | Yes | ||
| title | Yes | ||
| venue_filter | No | ||
| year_from | No | ||
| year_to | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the search is case-insensitive, returns results sorted by similarity score, includes optional BibTeX entries, and applies filters for year and venue. It also specifies default values (e.g., max_results default is 10, include_bibtex default is false). However, it doesn't mention potential limitations like rate limits, error conditions, or authentication needs.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The parameter explanations are structured as a bulleted list, which is clear and efficient. However, the 'Returns' statement could be integrated more seamlessly, and there's minor redundancy in specifying 'case-insensitive' for both title and venue_filter separately.
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 search tool with 7 parameters, no annotations, and no output schema, the description is largely complete. It covers the tool's purpose, all parameter semantics, and key behavioral aspects like sorting and defaults. The main gap is the lack of output details (only mentions 'publication objects' without specifying structure), but given the complexity and absence of an output schema, this is a minor shortfall.
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?
Given the schema description coverage is 0%, the description compensates fully by providing detailed semantics for all 7 parameters. It explains each parameter's purpose, data types, requirements, defaults, and constraints (e.g., similarity_threshold range 0-1, case-insensitive matching for title and venue_filter). This adds significant value beyond the bare schema, making the parameters well-understood.
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 clearly states the tool's purpose: 'Search DBLP for publications with fuzzy title matching.' This specifies the verb ('search'), resource ('publications'), and method ('fuzzy title matching'), distinguishing it from sibling tools like 'search' (which lacks the fuzzy matching specification) and 'get_author_publications' (which focuses on authors rather than titles).
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 implies usage through the mention of 'fuzzy title matching' and the parameter explanations, suggesting it's for finding publications when the exact title isn't known. However, it doesn't explicitly state when to use this tool versus alternatives like the generic 'search' tool or 'get_author_publications', nor does it provide exclusions or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_author_publicationsA
Retrieve publication details for a specific author with fuzzy matching. Arguments:
author_name (string, required): Full or partial author name (case-insensitive).
similarity_threshold (number, required): A float between 0 and 1 where 1.0 means an exact match.
max_results (number, optional): Maximum number of publications to return. Default is 20.
include_bibtex (boolean, optional): Whether to include BibTeX entries in the results. Default is false. Returns a dictionary with keys: name, publication_count, publications, and stats (which includes top venues, years, and types).
| Name | Required | Description | Default |
|---|---|---|---|
| author_name | Yes | ||
| include_bibtex | No | ||
| max_results | No | ||
| similarity_threshold | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes key behaviors like fuzzy matching, case-insensitive search, and default values for optional parameters. However, it lacks details on error handling, rate limits, authentication needs, or what happens with low similarity thresholds. The description doesn't contradict annotations, but it's incomplete for a tool with fuzzy matching and multiple parameters.
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 well-structured and appropriately sized. It starts with a clear purpose statement, then lists arguments with detailed explanations, and ends with return value information. Every sentence adds value, though the return details could be slightly more concise. It's front-loaded with the core functionality.
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?
Given the tool's complexity (fuzzy matching, 4 parameters) and lack of annotations/output schema, the description does a good job of covering key aspects. It explains parameters thoroughly and outlines the return structure. However, it could benefit from more behavioral context (e.g., performance implications, error cases) to be fully complete for an agent's use.
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 description adds significant value beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: 'author_name' for full/partial name matching, 'similarity_threshold' as a float between 0-1 for match precision, 'max_results' for limiting output with a default, and 'include_bibtex' for including BibTeX entries. This compensates fully for the schema's lack of descriptions.
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 clearly states the tool's purpose: 'Retrieve publication details for a specific author with fuzzy matching.' It specifies the verb ('retrieve'), resource ('publication details'), and key behavior ('fuzzy matching'). However, it doesn't explicitly differentiate from sibling tools like 'fuzzy_title_search' or 'search', which might have overlapping functionality.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'fuzzy_title_search' (for titles) or 'search' (which might be more general), nor does it specify prerequisites or exclusions. Usage is implied by the description but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_venue_infoA
Retrieve detailed information about a publication venue. Arguments:
venue_name (string, required): Venue name or abbreviation (e.g., 'ICLR' or full name). Returns a dictionary with fields: abbreviation, name, publisher, type, and category. Note: Some fields may be empty if DBLP does not provide the information.
| Name | Required | Description | Default |
|---|---|---|---|
| venue_name | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool retrieves data from DBLP and notes that some fields may be empty, adding useful behavioral context about data source and completeness. However, it lacks details on error handling, rate limits, or authentication needs, which are important for a read operation.
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 well-structured with clear sections for arguments and returns, and every sentence adds value. It could be slightly more front-loaded by moving the note about DBLP earlier, but overall it's efficient with minimal waste.
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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is reasonably complete. It covers the purpose, parameter semantics, return fields, and data source limitations. However, it could improve by mentioning error cases or when to use alternatives, slightly reducing completeness.
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 description adds significant meaning beyond the input schema, which has 0% coverage. It explains the 'venue_name' parameter as accepting names or abbreviations (e.g., 'ICLR'), clarifies it's required, and provides examples, fully compensating for the schema's lack of documentation.
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 clearly states the verb 'retrieve' and resource 'detailed information about a publication venue,' making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'get_uthor_publications' or 'search' by focusing on venue metadata rather than author data or broader searches.
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?
No guidance is provided on when to use this tool versus alternatives like 'search' or 'fuzzy_title_search.' The description implies usage for venue details but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchA
Search DBLP for publications using a boolean query string. Arguments:
query (string, required): A query string that may include boolean operators 'and' and 'or' (case-insensitive). For example, 'Swin and Transformer'. Parentheses are not supported.
max_results (number, optional): Maximum number of publications to return. Default is 10.
year_from (number, optional): Lower bound for publication year.
year_to (number, optional): Upper bound for publication year.
venue_filter (string, optional): Case-insensitive substring filter for publication venues (e.g., 'iclr').
include_bibtex (boolean, optional): Whether to include BibTeX entries in the results. Default is false. Returns a list of publication objects including title, authors, venue, year, type, doi, ee, and url.
| Name | Required | Description | Default |
|---|---|---|---|
| include_bibtex | No | ||
| max_results | No | ||
| query | Yes | ||
| venue_filter | No | ||
| year_from | No | ||
| year_to | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses some behavioral traits like case-insensitive operators, lack of parentheses support, and default values for max_results and include_bibtex. However, it misses details like rate limits, error handling, or authentication needs, leaving gaps for a tool with 6 parameters.
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 appropriately sized and front-loaded with the core purpose, followed by a structured breakdown of arguments and returns. Every sentence adds value, though the parameter explanations could be slightly more concise.
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 search tool with 6 parameters, no annotations, and no output schema, the description is largely complete. It covers purpose, parameters with semantics, and return format. Minor gaps include lack of pagination details or explicit error cases, but it adequately supports agent usage.
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?
Given 0% schema description coverage, the description fully compensates by providing detailed semantics for all 6 parameters. It explains the query format with examples, optional status, defaults, and filtering logic (e.g., 'case-insensitive substring filter for publication venues'), adding significant value beyond the bare schema.
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 clearly states the specific action ('Search DBLP for publications') and resource ('publications'), distinguishing it from siblings like 'get_author_publications' or 'get_venue_info' by focusing on boolean query-based search rather than author-specific or venue-specific lookups.
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 implies usage through the mention of 'boolean query string' and parameter details, but does not explicitly state when to use this tool versus alternatives like 'fuzzy_title_search' or 'get_author_publications'. No exclusions or clear alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
v1.0.0- First observed
calculate_statistics - First observed
export_bibtex - First observed
fuzzy_title_search - First observed
get_author_publications - First observed
get_venue_info - First observed
search
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose with no ambiguity: calculate_statistics processes existing results, export_bibtex handles BibTeX export, fuzzy_title_search and search provide different search methods, get_author_publications focuses on authors, and get_venue_info targets venues. The tools cover different aspects of the DBLP domain without overlap.
All tool names follow a consistent verb_noun pattern with snake_case: calculate_statistics, export_bibtex, fuzzy_title_search, get_author_publications, get_venue_info, and search. The naming is predictable and readable throughout the set.
With 6 tools, the count is well-scoped for a DBLP server, covering key operations like search, author/venue info, statistics, and BibTeX export. Each tool earns its place without feeling thin or bloated, suitable for typical academic workflows.
The tool set provides strong coverage for core DBLP operations including search, author/venue retrieval, and data export, with minor gaps such as no direct tool for updating or deleting data (though this may be intentional for a read-heavy domain). Agents can effectively navigate publication workflows with these tools.
Maintenance
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
MCP server for Firecrawl — web search, scraping, and biomedical/arXiv paper search.
Related MCP Servers
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables querying the Crossref API to search for academic publications by title, author, or DOI, returning structured metadata about scholarly works.327 npm4MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI agents to search, retrieve, and analyze academic papers from arXiv, supporting features like keyword search, paper details retrieval, content extraction, and paper analysis.5MIT
- FlicenseNot gradedqualityDmaintenanceA comprehensive Model Context Protocol server that provides AI assistants with direct access to Semantic Scholar's academic database, enabling advanced paper discovery, citation analysis, author research, and AI-powered recommendations.16-
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI assistants to verify BibTeX citations and URLs against academic databases like Semantic Scholar and DBLP. It allows users to ensure bibliography accuracy and link accessibility directly within their research workflows.1MIT