Skip to main content
Glama
deenesjakoruzh
szeider

MCP-DBLP

by szeider
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

MCP-DBLP

MCP Compatible License: MIT Python Version

A Model Context Protocol (MCP) server that gives Large Language Models access to the DBLP computer science bibliography (accompanying paper published at AI4SC @ AAAI-26).

Overview

MCP-DBLP lets an LLM search DBLP through the Model Context Protocol and build a BibTeX file from the results. The model chooses the papers and the citation keys; the server writes the entries from DBLP's data, so the model never rewrites bibliographic fields.

Since version 2.0, MCP-DBLP works from a local copy of DBLP instead of the dblp.org web API, which now blocks automated clients. On first start the server downloads the local index, a prebuilt SQLite index of the monthly DBLP dump (about 1.3 GB, see The local DBLP index). After that, all searches run locally, without rate limits.

Related MCP server: ArXiv-MCP

Features

  • Boolean search with and and or (no parentheses), filtered by year and venue

  • Fuzzy matching of titles and author names

  • Author-aware ranking: each search result names the query words that matched an author, the title, or the venue, and marks prefix-only matches

  • BibTeX in DBLP's own format, rendered from DBLP's data; it matches the .bib export on dblp.org except for the time of day in the timestamp field, and titles also brace words with inner capitals ({CaDiCaL}, {DRUP}-based) so that bibliography styles do not lowercase them

  • Export of the collected entries to a .bib file, written by the server

  • A new local index every month, installed with mcp-dblp-index update

Available tools

Tool

Description

search

Search DBLP with boolean queries

fuzzy_title_search

Find publications by approximate title

get_author_publications

List an author's publications, optionally by year

get_venue_info

Look up a venue's name, acronym, type and DBLP page

add_bibtex_entry

Add the entry for a DBLP key to the collection

export_bibtex

Write the collected entries to a .bib file

set_dblp_mirror

Choose the dblp.org host for the web fallback (rarely needed)

Feedback

Provide feedback to the author via this form.

System requirements

  • Python 3.11+

  • uv

  • About 5.5 GB of free disk space on first start (1.3 GB download plus 4.2 GB index), 4.2 GB afterwards

Installation

Claude Code

Run:

claude mcp add mcp-dblp -- uvx mcp-dblp

Claude Desktop

Add to your Claude Desktop configuration file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "mcp-dblp": {
      "command": "uvx",
      "args": ["mcp-dblp"]
    }
  }
}

From source (development)

git clone https://github.com/szeider/mcp-dblp.git
cd mcp-dblp
uv venv && source .venv/bin/activate
uv pip install -e .

Then configure Claude Desktop with:

{
  "mcpServers": {
    "mcp-dblp": {
      "command": "uv",
      "args": ["--directory", "/path/to/mcp-dblp/", "run", "mcp-dblp"]
    }
  }
}

The local DBLP index

DBLP publishes all of its data as a monthly XML dump under the CC0 license. The companion repository mcp-dblp-index builds the local index from each dump and publishes it as a GitHub release.

First start. If no local index is installed, the server downloads the current release in the background (about 1.3 GB, unpacked to 4.2 GB). This takes about 2 minutes at 100 Mbit/s and about 9 minutes at 20 Mbit/s. Meanwhile, each tool call waits up to 40 seconds for the index and then answers with the download progress, so the first search takes longer than usual. An interrupted download resumes where it stopped.

Updates. A new local index is released every month. The installed one changes only when you update it:

uvx --from mcp-dblp mcp-dblp-index update

The old index keeps serving until the new one is installed. Papers added to DBLP after the release date are not in the index until the next release.

Command line. mcp-dblp-index manages the index:

Command

What it does

status

Show the installed index (release date, number of publications)

fetch

Download and install the current local index

update

Install the newest release if it is newer than the installed one

download

Download the raw DBLP XML dump (for building the index yourself)

build

Build the index from a downloaded dump (about 10 minutes)

Environment variables. Set them in the server's environment; in Claude Desktop, use the env field of the server entry:

Variable

Meaning

MCP_DBLP_HOME

Directory for the index and downloads (default ~/.mcp-dblp), e.g. on a disk with more space

MCP_DBLP_INDEX

Path of a specific index file; http switches to the dblp.org web API (blocked by dblp.org)

MCP_DBLP_FIRST_START_WAIT

Seconds a tool call waits for the first-start download (default 40)

{
  "mcpServers": {
    "mcp-dblp": {
      "command": "uvx",
      "args": ["mcp-dblp"],
      "env": { "MCP_DBLP_HOME": "/Volumes/Data/mcp-dblp" }
    }
  }
}

Instructions

Usage instructions are delivered to the model with the first answer of each session. See instructions_prompt.md.

Tool details

search

Search DBLP for publications. All query words must occur in the title, the author names or the venue (case and accents do not matter). Each result shows its DBLP key and a Matched: line that says where each query word was found, for example szeider = author 2 of 3.

Parameters:

  • query (string, required): The search words. or separates alternatives (no parentheses), "quoted phrases" match adjacent words, the field prefixes author:, title:, venue: and year: apply to the next word or phrase, and a 4-digit year restricts the results to that year. Example: author:Vaswani title:attention 2017

  • max_results (integer, optional): Maximum number of publications to return. Default is 10

  • year_from (integer, optional): Lower bound for publication year

  • year_to (integer, 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

fuzzy_title_search

Find publications by title, also when the title is misspelled or only its beginning is known. Results are ranked by title similarity and labelled "same title", "title contains the query" or "similar title".

Parameters:

  • 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 (integer, optional): Maximum number of publications to return. Default is 10

  • year_from (integer, optional): Lower bound for publication year

  • year_to (integer, 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

get_author_publications

List an author's publications, newest first. The name is matched fuzzily. DBLP tells namesakes apart by a number ("Wei Wang 0010"); the answer names the DBLP person listed and the other persons with a matching name.

Parameters:

  • author_name (string, required): Full author name, optionally with DBLP's number (case and accents do not matter)

  • similarity_threshold (number, required): A float between 0 and 1 where 1.0 means an exact match

  • max_results (integer, 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

  • year_from (integer, optional): Only publications from this year on

  • year_to (integer, optional): Only publications up to this year

get_venue_info

Look up a venue: its name, acronym, type (conference or journal), DBLP page, number of publications, and year range.

Parameters:

  • venue_name (string, required): A conference acronym ('IJCAI'), DBLP's journal abbreviation ('J. ACM') or a journal's full name ('Journal of the ACM')

add_bibtex_entry

Add a BibTeX entry to the collection for later export.

Parameters:

  • dblp_key (string, required): The DBLP key from search results (e.g., "conf/nips/VaswaniSPUJGKP17"); DBLP:KEY and the biburl of a DBLP entry (https://dblp.org/rec/KEY.bib) work too

  • citation_key (string, required): The citation key to use in the .bib file (e.g., "Vaswani2017")

Behavior:

  • Renders the BibTeX entry for the key from the local index, in DBLP's format

  • Replaces the citation key with your custom key

  • Adds the entry to the session's collection (an entry with the same citation key is replaced)

  • Returns success or an error, with the size of the collection

The server renders every entry from DBLP's data; the model chooses only the citation key and never edits the entry. A key missing from the local index is looked up on dblp.org, which currently blocks automated clients, so such a call returns an error and leaves the collection unchanged.

export_bibtex

Export all collected BibTeX entries to a .bib file.

Parameters:

  • path (string, required): Absolute path for the .bib file (e.g., "/path/to/refs.bib"); a leading ~ is expanded. Relative paths are rejected.

Behavior:

  • Saves all entries added via add_bibtex_entry to the specified path

  • The .bib extension is added automatically if missing

  • Parent directories are created if needed

  • Clears the collection after successful export

  • Returns the full path to the saved file

  • Returns an error if the collection is empty

set_dblp_mirror

Choose which dblp.org host the web fallback uses: keys missing from the local index, or all requests with MCP_DBLP_INDEX=http. Searches with the local index never contact dblp.org, and dblp.org currently blocks automated clients, so this tool is rarely useful.

Parameters:

  • host (string, required): dblp.org, dblp.uni-trier.de, or dblp.dagstuhl.de; other hosts are rejected

Example

Input text

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.

Output text

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,IgnatievNA020}, corresponding to necessary reason explanations \cite{DarwicheJ22}, make explicit the reasons behind the non-selection of alternatives. Conversely, global explanations \cite{Ribeiro0G16,IgnatievNM19} aim to unravel models' decision patterns across various inputs.

Output BibTeX

export_bibtex answers Exported 7 references to /path/to/refs.bib and writes:

@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 00:00:00 +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 00:00:00 +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 00:00:00 +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    = {Wed, 18 Mar 2026 00:00:00 +0100},
  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    = {Sun, 07 Dec 2025 00:00:00 +0100},
  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 00:00:00 +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    = {Sun, 01 Feb 2026 00:00:00 +0100},
  biburl       = {https://dblp.org/rec/conf/kdd/Ribeiro0G16.bib},
  bibsource    = {dblp computer science bibliography, https://dblp.org}
}

Disclaimer

MCP-DBLP is a research prototype. Use it at your own risk.

License

This project is licensed under the MIT License. See the LICENSE file for details.

Available Tools

6 tools
calculate_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)').

ParametersJSON Schema
NameRequiredDescriptionDefault
resultsYes

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters5/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
linksYes

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

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

ParametersJSON Schema
NameRequiredDescriptionDefault
author_nameYes
include_bibtexNo
max_resultsNo
similarity_thresholdYes

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters5/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
venue_nameYes

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv1.0.0
    • First observedcalculate_statistics
    • First observedexport_bibtex
    • First observedfuzzy_title_search
    • First observedget_author_publications
    • First observedget_venue_info
    • First observedsearch
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored across 6 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • Crossref MCP Server

    botanicastudios
    A
    license
    B
    quality
    D
    maintenance
    A 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.
    3
    27 npm
    4
    MIT

  • ArXiv-MCP

    kelvingao
    A
    license
    Not graded
    quality
    D
    maintenance
    A 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.
    5
    MIT

  • Semantic Scholar MCP Server

    alperenkocyigit
    F
    license
    Not graded
    quality
    D
    maintenance
    A 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
    -

  • harcx-mcp

    Vashistht
    A
    license
    Not graded
    quality
    D
    maintenance
    An 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.
    1
    MIT

Appeared in Searches