You can query a local paper library and experiment results, and cross-reference them.
Paper library tools
search_papers: semantic search over indexed PDFs, optionally scoped by project or sub-area.
list_projects: list paper projects and sub-areas with counts.
list_library: overview of indexed papers with title, year, and size/scope.
read_paper: retrieve full text of a paper by ID.
read_code / list_code: read and list source files in configured directories.
Experiment analysis tools
list_experiments: overview of experiment runs with model, status, and date.
analyze_project: comprehensive analysis of all runs in a project, including per-run metrics, varied vs constant hyperparameters, correlations between numerical hyperparameters and metrics, and flags for unstable runs.
get_experiment: full hyperparameters and results for a single run.
get_fold_summary: k-fold cross-validation summary with mean, std, min, max per metric, plus high-spread warnings.
compare_experiments: compare multiple runs, showing only differing hyperparameters and metric results side-by-side.
Additional citation support
find_citation_candidates and read_thesis are documented to help find supporting passages for claims and analyze thesis structure.
All tools provide deterministic retrieval and aggregation, leaving interpretation to the language model.
Click on "Install 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., "@research-mcp find discussions of dropout regularization in my library"
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.
A local Model Context Protocol server that turns a personal research workspace — papers and experiment results — into tools any MCP-capable client (Claude Desktop, Cursor, VS Code) can query.
Ask "analyse all my thesis runs, which hyperparameters drive instability, and does my paper library back that up?" and the model works across both sources: it reads the experiment summaries, correlates hyperparameters against metrics, and cross-checks the findings against the PDFs on your own disk.
Research context is scattered. Papers sit in one folder, training runs log JSON and CSV somewhere else, notes live in a third place. Questions that span those sources can't be answered without manual digging, and pasting file after file into a chat window does not scale.
This server exposes each source as a set of tools. The language model decides at runtime which to call and how to combine them. Retrieval and aggregation are deterministic Python; only the interpretation happens in the model.
Related MCP server: PDFDashboardWithMCP
Papers and experiments are handled differently on purpose.
indexing (offline) reading (on demand)
PDFs ──► ingest.py ──► library.db ◄──┐
├──► server.py ◄──► Claude Desktop
JSON / CSV runs ─────────────────────┘ (stdio MCP)Papers are unstructured text, so they need preparation. ingest.py extracts text,
strips references, splits it into overlapping chunks, computes embeddings and writes
everything to a single SQLite file. You run it when you add papers.
Experiments are already structured. There is no database and no preprocessing: the server reads the JSON/CSV files straight from disk when a tool is called and summarises them on the fly. Drop a new results file in place and it is instantly queryable.
server.py is read-only and starts automatically when Claude Desktop launches. It
contains no LLM — it just serves data over stdio.
Paper library
Tool | Purpose |
| Semantic search across all chunks, optionally scoped to a project |
| Available paper projects with counts |
| All indexed papers |
| Full text of a single paper |
Experiments
Tool | Purpose |
| Summarises all runs of a project in one call: per-run metrics, which hyperparameters were varied, correlations against every metric, and flagged unstable runs |
| Overview of runs with model, status and date |
| Full hyperparameters and results of a single run |
| k-fold results reduced to mean/std per metric, with a stability warning on high spread |
| Diffs runs, showing only the hyperparameters that differ alongside the metrics |
Citation assistant
Tool | Purpose |
| For a single statement, returns the most similar passages from your own papers — full passage text, page and score — so the model can judge whether a source really supports the claim |
| Reads a LaTeX/Markdown thesis and splits it into sentences, marking which already carry a citation and grouping them by paragraph |
| Scans a whole thesis in one pass: collects the uncited sentences, groups them by paragraph, and returns candidate passages for each, so the model can propose where a citation is missing and which paper supports it |
Source access
Tool | Purpose |
| Reads a source file of the project, confined to configured directories |
| Lists the readable source files |
Requires Python 3.12+ and uv.
git clone https://github.com/lduda79/research-mcp
cd research-mcp
uv syncRegister the server in claude_desktop_config.json (on Linux:
~/.config/Claude/claude_desktop_config.json):
{
"mcpServers": {
"research": {
"command": "uv",
"args": ["--directory", "/absolute/path/to/research-mcp", "run", "server.py"]
}
}
}Verify without a model in the loop:
npx @modelcontextprotocol/inspector uv run server.pyPaths live in config.yaml at the project root. Copy the example and edit it:
cp config.example.yaml config.yaml# The vector database stays inside research-mcp — it is a derived index.
database: library.db
# Default subfolder names inside each project. Name your folders the same way
# everywhere and you only need each project's "root" below.
defaults:
papers: papers
experiments: experiments
thesis: text
projects:
my_project:
root: ~/Desktop/my_project
# uses the defaults
# A second project may override folder names or omit a folder:
# my_other_project:
# root: ~/Desktop/my_other_project
# experiments: runs
# thesis: null~ expands to your home directory; relative paths are taken from the research-mcp
folder. Each project keeps its papers, experiment runs and thesis text wherever you
work — nothing has to live inside research-mcp. Papers from every project share one
database, separated by the project column.
If no config.yaml is present, the server falls back to the classic layout
(data/papers, data/experiments, data/thesis, data/library.db).
The read tools (read_code, read_thesis) are confined to the research-mcp checkout
plus the folders named in config.yaml — nothing outside can be read.
Put PDFs in a project's papers folder (e.g. ~/Desktop/my_project/papers). All
papers of a project are indexed under that project's name. Index them:
uv run ingest.py # index all projects from config.yaml
uv run ingest.py --project my_project # only one project
uv run ingest.py --path ~/some/folder --project scratch # an ad-hoc folder
uv run ingest.py --force # re-index everything
uv run ingest.py --stats # show current contents
uv run ingest.py --duplicates # find duplicates, remove after confirmation
uv run ingest.py --no-arxiv # skip metadata lookup (offline)Store each run under a project's experiments folder, one subfolder per run, with a hyperparameter file and a results file:
~/Desktop/my_project/experiments/
└── run1_lower_lr/
├── hparams.json
└── results.jsonhparams.json holds flat, numeric hyperparameters. The results file carries summary
values (mean_<metric>, std_<metric>) and an optional per_fold list with the raw
per-fold values; from those the server computes spread and flags unstable runs itself.
Filenames and metric names are flexible — several common names are accepted, and each
project may use its own metrics.
The templates/ directory contains annotated templates and save_run.py, a helper you
call at the end of training that writes both files consistently (it derives the
summary values from the per-fold data, so they can never disagree).
Two entry points work together to help place references while writing:
read_thesis parses a .tex/.md file into sentences, marks which already carry a
citation, and tags each sentence with its paragraph.
audit_thesis goes further in a single pass: it collects the uncited sentences,
groups them by paragraph, and looks up candidate passages from the library for each -
returning paper, page, full passage and score. The model then decides which uncited
sentences are actually citation-worthy (skipping meta-sentences) and whether a
paragraph deserves one shared citation or one per sentence.
For a single ad-hoc statement, find_citation_candidates returns the same kind of
ranked passages without reading a file.
The deterministic core is covered by a pytest suite: configuration resolution, text chunking, the thesis/citation parser and the experiment analysis. These modules need neither the embedding model nor a database, so the tests run in a fraction of a second.
uv run pytest # run everything
uv run pytest -v # list each testThe suite runs automatically on every push via GitHub Actions
(.github/workflows/tests.yml) against Python 3.12.
Paths are configurable, data lives where you work. A config.yaml maps each project
to a real folder on disk, so papers, runs and thesis text stay in your workspace instead
of being copied into the server. One module resolves every path; nothing else hardcodes
a location.
Papers and experiments take different paths. Unstructured PDFs are embedded into a vector store ahead of time; structured run files are read and aggregated on demand. Two problems, two mechanisms — forcing them through one pipeline would help neither.
Aggregation happens before the model sees anything. k-fold runs can hold thousands of raw numbers. The server returns mean, std and outlier flags instead, so the model reasons over a handful of meaningful figures rather than a flood of noise. Correlations between hyperparameters and metrics are computed deterministically (Pearson) and labelled as descriptive, not causal.
Ingestion is separate from the server. The server is read-only and loads the embedding model lazily, so Claude Desktop starts in milliseconds instead of waiting for PyTorch.
Reads are confined to configured directories. The file-reading tools resolve every
path and reject anything outside the checkout or the folders named in config.yaml, so a
stray or malicious path cannot escape the project.
No print() anywhere in the server. With stdio transport the MCP protocol occupies
stdout — a single stray print corrupts the message stream. All logging goes to stderr.
References are stripped before chunking. Bibliographies are dense clusters of domain vocabulary with no propositional content; leaving them in hijacks semantic search.
Filtered vector search overfetches. The KNN query is unaware of the metadata columns
and returns the k globally nearest chunks; the project filter is applied afterwards.
Without overfetching (k = limit * 8) a filtered query can return almost nothing — the
standard pre- vs post-filtering tradeoff in ANN search.
Titles come from font size, not the first line. Paper title pages often carry licence notices above the title. Taking the largest text span on page one is far more reliable; when an arXiv ID is present, the arXiv API overrides the heuristic entirely.
Content hashing drives re-indexing. Each PDF is fingerprinted with SHA-256, so
ingest.py is idempotent — unchanged files are skipped, renamed files are detected and
moved rather than re-embedded, and changed files are replaced along with their orphaned
vectors (virtual tables are not covered by ON DELETE CASCADE).
Python MCP SDK (FastMCP) · SQLite + sqlite-vec · sentence-transformers
(all-MiniLM-L6-v2) · PyMuPDF · httpx · PyYAML
Working: configurable project paths, PDF ingestion with duplicate and rename handling, semantic search with project scoping, arXiv metadata lookup, full experiment analysis (per-run summaries, k-fold statistics, cross-run comparison and hyperparameter correlations), a citation assistant that finds supporting passages for uncited statements and audits a whole thesis for missing citations, and a pytest suite for the deterministic core running in CI.
Planned:
Hybrid retrieval (BM25 via FTS5 + dense, combined with reciprocal rank fusion)
External paper discovery (arXiv / Semantic Scholar) so literature cross-checks can reach beyond the local library
Citation checking: verify that an existing \cite{...} is actually supported by the
cited source, via a .bib lookup
MIT
Fasst ALLE Laeufe eines Projekts in einem Aufruf zusammen - fuer die Gesamtanalyse.
Das ist das richtige Tool fuer Fragen wie "analysiere alle meine Testlaeufe",
"welche Hyperparameter haengen mit dem Ergebnis zusammen", "gibt es Ausreisser"
oder "was sollte ich als naechstes testen". Liefert in einem Objekt:
- jeden Lauf mit flachen Hyperparametern und zusammengefassten Metriken
- welche Hyperparameter ueberhaupt variiert wurden und welche konstant sind
- Korrelationen zwischen numerischen Hyperparametern und JEDER Metrik
- die verfuegbaren Metriknamen und die Laeufe mit hoher Fold-Streuung
Die Korrelationen sind deskriptiv und beruhen oft auf wenigen Laeufen - sie
sind Anhaltspunkte, kein Kausalnachweis. Deute sie im Kontext.
Fuer Vorschlaege, was als Naechstes zu testen ist, kannst du die Befunde
anschliessend mit search_papers gegen die Literatur abgleichen.
Args:
projekt: Name des Projekts, z.B. "masterarbeit"
metric: Optional die Zielmetrik, die im Fokus stehen soll, z.B.
"std_val_dbm_mse". Wird sie weggelassen, waehlt das Tool selbst
eine aus - korreliert wird ohnehin gegen alle Metriken. Die
gueltigen Namen stehen im Feld "verfuegbare_metriken".
| Name | Required | Description | Default |
|---|---|---|---|
| metric | No | ||
| projekt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: returns per-run data, varied/constant hyperparams, correlations, metric names, and high-variance runs. Warns correlations are descriptive, not causal. Also mentions auto-selection of metric if omitted.
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?
Well-structured with clear sections, but slightly verbose. Could be more concise while retaining all essential information. Every sentence contributes value, so no major 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 no output schema and no annotations, the description covers all necessary aspects: purpose, usage, parameter details, return content, and interpretation caveats. Completely adequate for an analysis 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 has no descriptions (0% coverage). Description explains 'projekt' with an example and 'metric' as optional with auto-selection behavior and guidance to find valid names in output field 'verfuegbare_metriken'. Adds significant meaning.
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 aggregates all runs of a project for overall analysis, with specific example questions. It distinguishes itself from siblings like list_experiments and get_experiment by focusing on cross-run analysis.
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?
Provides explicit when-to-use guidance with example queries and suggests using search_papers for literature checks. Does not explicitly state when not to use or list alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vergleicht mehrere Laeufe und hebt hervor, was sie unterscheidet.
Zeigt nur die *abweichenden* Hyperparameter (nicht die ganze Config) und
stellt die Ergebnis-Metriken nebeneinander. Ideal fuer die gezielte Frage,
welche einzelne Konfigurationsaenderung welchen Effekt hatte. Fuer den
Gesamtueberblick ueber alle Laeufe nutze stattdessen analyze_project.
Args:
run_ids: Liste von Laufnamen, z.B. ["dcgan_run_005", "dcgan_run_006"]
projekt: Optional, um die Suche einzugrenzen
| Name | Required | Description | Default |
|---|---|---|---|
| projekt | No | ||
| run_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it only shows deviating hyperparameters and not the full config, and presents metric results side by side. No annotations are provided, so the description carries the full burden, and it does this adequately, though it could mention if it's read-only or if data is mutated (it is likely read-only).
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 very concise, front-loads the purpose, then details behavior, and ends with parameter documentation. Every sentence is meaningful and well-structured.
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 simplicity (2 parameters, no output schema), the description covers the main functionality, usage context, and parameter formats. It could be considered complete for this complexity level, though it might hint at the return format.
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?
Despite 0% schema description coverage, the description explains the parameter meanings: 'run_ids' is a list of run names, and 'projekt' is optional to narrow the search. This adds value beyond the schema's field definitions.
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 compares experiments and highlights differences, specifically showing deviating hyperparameters and metrics. It distinguishes itself from 'analyze_project', which is for an overall overview.
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 explicitly recommends using this tool to see the effect of single configuration changes and advises using 'analyze_project' for an overall overview, providing clear when-to-use and when-not-to-use guidance with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gibt Hyperparameter und Ergebnisse eines einzelnen Laufs vollstaendig zurueck.
Nutze zuerst list_experiments oder analyze_project, um gueltige run_ids zu
bekommen.
Args:
run_id: Name des Laufs, z.B. "dcgan_run_005"
projekt: Optional, um die Suche einzugrenzen
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| projekt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It describes the tool as returning data (implies read-only), but does not mention potential errors, authentication, or side effects. However, the behavior is straightforward for a retrieval tool.
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 concise sentences: purpose, usage guidance, parameter details. No unnecessary words. Information is front-loaded and well structured.
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 no output schema, the description mentions the return of hyperparameters and results but does not detail the structure. For a simple get tool, this is mostly complete, though additional output format could be helpful.
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 adds value by explaining run_id as 'name of the run' with an example, and projekt as optional to narrow search. This provides meaning beyond the schema's type alone.
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 it returns hyperparameters and results of a single run. It distinguishes from sibling tools like list_experiments (which lists runs) and analyze_project (project-level analysis).
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?
Explicitly advises to first use list_experiments or analyze_project to obtain valid run_ids. This provides clear when-to-use guidance and the prerequisite for tool invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fasst k-fold-Cross-Validation-Ergebnisse eines Laufs statistisch zusammen.
Gibt pro Metrik Mittelwert, Standardabweichung, Minimum und Maximum ueber
alle Folds zurueck - nicht die Rohwerte. Warnt automatisch, wenn eine
Metrik stark ueber die Folds streut (Hinweis auf instabiles Training oder
einen unguenstigen Split).
Args:
run_id: Name des Laufs, z.B. "dcgan_run_005"
projekt: Optional, um die Suche einzugrenzen
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| projekt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that it returns only summary statistics (not raw values) and automatically warns about high variance across folds, providing useful behavioral context beyond the schema.
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, well-structured with a clear purpose, output details, and argument list. Every sentence adds value without redundancy.
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 no output schema and no annotations, the description covers the tool's purpose, return values (summary stats), and parameters adequately. It lacks explicit return format, but is sufficient for typical 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?
Schema coverage is 0%, but the description adds meaning by explaining run_id with an example ('dcgan_run_005') and clarifying projekt as optional for narrowing search, compensating for the lack of schema 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 it aggregates k-fold cross-validation results into summary statistics (mean, std, min, max per metric), distinguishing it from sibling tools like get_experiment or compare_experiments.
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 for obtaining aggregated fold results and warns about high variance, but does not explicitly state when to use vs alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet Trainings- und Testlaeufe mit Modell, Status und Datum auf.
Nur der Ueberblick. Fuer eine Gesamtanalyse aller Laeufe nutze
analyze_project, fuer einen einzelnen Lauf get_experiment.
Args:
projekt: Optional auf ein Projekt einschraenken, z.B. "masterarbeit".
Weglassen, um alle Laeufe zu sehen.
| Name | Required | Description | Default |
|---|---|---|---|
| projekt | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states it's an 'Ueberblick' (overview) and lists fields (model, status, date), but does not disclose pagination, ordering, or any limits. Adequate but not fully transparent.
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?
Four sentences, no wasted words. Purpose, usage guidance, and parameter explanation are concise and well-structured. Slightly verbose with German phrasing but still efficient.
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 simplicity (one optional param, list output) and existence of an output schema (not shown), the description sufficiently covers key aspects: what it lists, filtering, and sibling distinction. Could mention sorting or default ordering but complete enough.
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 coverage is 0%, so description must compensate. It explains 'projekt' parameter: optional, restricts to a project, provides example ('masterarbeit'), and clarifies that omitting shows all runs. Adds meaningful context beyond 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 it lists training/test runs with model, status, and date. It distinguishes from siblings (analyze_project for total analysis, get_experiment for individual runs), making the tool's specific purpose unambiguous.
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?
Explicitly tells when to use this tool ('Nur der Ueberblick') and when to use alternatives ('Fuer eine Gesamtanalyse... analyze_project... fuer einen einzelnen Lauf get_experiment'). Also hints at optional filtering with 'projekt' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet alle indexierten Paper der Bibliothek mit Titel, Jahr und Umfang auf.
Benutze dieses Tool, um einen Ueberblick zu bekommen, welche Paper ueberhaupt verfuegbar sind, bevor du inhaltlich suchst.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses the tool's behavior (lists all indexed papers with specific fields) and implies it is a read-only operation. No mention of side effects or permissions, but the tool is simple and non-destructive.
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?
Two sentences: first defines the action, second provides usage context. No wasted words, front-loaded with 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 has no parameters and an output schema exists, the description sufficiently covers what the tool does and when to use it. It mentions the returned fields (title, year, size) and the overall purpose.
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 tool has zero parameters and schema coverage is 100%. Following the baseline rule (0 params = baseline 4), the description does not need to add parameter info.
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 that the tool lists all indexed papers with title, year, and size. This verb-resource combination is specific and distinguishes it from siblings like search_papers or read_paper.
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?
Provides explicit guidance: use this tool to get an overview of available papers before doing content searches. The sibling 'search_papers' is implicitly mentioned as the alternative for in-depth searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Zeigt alle Projekte und Bereiche der Paper-Bibliothek mit Anzahl der Paper.
Ein Projekt ist die oberste Gliederung (z.B. "masterarbeit"), ein Bereich eine Untergliederung darin (z.B. "baselines", "related-work"). Benutze dieses Tool, bevor du eine Suche einschraenkst, um die gueltigen Namen zu erfahren.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | 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 that the tool shows paper counts and is intended for name discovery, but does not mention pagination, ordering, or what happens if the library is empty. For a simple listing tool, this is adequate but not exhaustive.
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 three sentences, front-loading the primary purpose. Every sentence adds value: purpose, definition of terms, and usage guidance. No wasted words.
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 has an output schema and zero parameters, the description is complete. It explains what the tool lists and provides use context. For a simple listing tool, no additional details are necessary.
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 input schema has no parameters, so schema coverage is 100%. The baseline for 0 params is 4, and the description adds value by explaining what the output contains (projects, areas, paper counts), though it does not add anything beyond the schema because there are no params.
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 that the tool shows all projects and areas of the paper library with their paper counts, using a specific verb (shows) and resource (projects and areas). This distinguishes it from sibling tools like list_library (broader listing) and read_paper (single item).
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 advises using this tool before narrowing a search to learn valid names, providing clear context for when to use it. While it does not explicitly list alternatives or when not to use, the guidance is sufficient for an agent to make a selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liest den Volltext eines Papers, um Details nachzuschlagen.
Nutze zuerst search_papers oder list_library, um die paper_id zu bekommen.
Args:
paper_id: Die numerische ID aus search_papers oder list_library
max_chars: Maximale Textlaenge, die zurueckgegeben wird
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes | ||
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It conveys that the tool reads text and respects a character limit, but does not explicitly state that it is read-only or describe the return format. This leaves some ambiguity about what the output looks like.
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?
Two short paragraphs, with the purpose stated first, followed by a step and the argument descriptions. No unnecessary words, every sentence serves a clear function.
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?
The description covers the primary actions and parameters but omits details about the return value (e.g., format, encoding). Since there is no output schema, the description should clarify what the agent can expect. It also does not mention error conditions or limits beyond max_chars.
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 has 0% description coverage, so the description must explain parameters. It does so adequately: paper_id is described as the numeric ID from sibling tools, and max_chars is described as the maximum text length to return. This adds significant semantic value beyond the raw schema types.
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 purpose as reading the full text of a paper to look up details, specifying the verb 'read' and the resource 'paper'. It distinguishes itself from siblings like search_papers (which presumably returns metadata) and list_library (which lists available papers) by focusing on retrieving full text.
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?
Explicitly advises to use search_papers or list_library first to obtain the paper_id, providing clear context for when to use this tool. It does not explicitly mention when not to use it, but the prerequisite instruction implies that directly calling without an ID is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Durchsucht die lokale Paper-Bibliothek inhaltlich nach einem Thema.
Findet Textstellen auch dann, wenn andere Begriffe verwendet werden als in
der Suchanfrage. Gibt Textausschnitte mit Titel, Jahr und Seitenzahl zurueck.
Benutze dieses Tool, um herauszufinden, was in den gelesenen Papern zu einem
Thema steht - etwa um einen Befund aus den Experimenten mit der Literatur
abzugleichen.
Args:
query: Thema oder Frage in natuerlicher Sprache, z.B. "warum Warmup beim Training"
limit: Maximale Anzahl der Textstellen (1-20)
projekt: Optional auf ein Projekt einschraenken, z.B. "masterarbeit".
Weglassen, um die gesamte Bibliothek zu durchsuchen.
bereich: Optional auf einen Bereich innerhalb des Projekts einschraenken,
z.B. "baselines" oder "related-work". Gueltige Werte liefert
list_projects. Weglassen, um alle Bereiche zu durchsuchen.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| bereich | No | ||
| projekt | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it performs semantic search ('Findet Textstellen auch dann, wenn andere Begriffe verwendet werden'), returns snippets with title, year, and page number, and searches the local library. No contradictions.
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 and well-structured: a one-sentence purpose, two sentences on behavior, and a clear list of arguments with examples and constraints. No superfluous text.
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 (4 params, 1 required, output schema exists), the description covers purpose, behavior, parameter semantics, and cross-references list_projects. It is complete for an agent to use the tool correctly.
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 input schema has 0% description coverage, but the description's Args section explains each parameter in detail (e.g., query as natural language question, limit 1-20, projekt optional scoping to project, bereich optional with valid values from list_projects). This adds essential meaning beyond the 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 that the tool searches the local paper library by content for a topic ('Durchsucht die lokale Paper-Bibliothek inhaltlich nach einem Thema'). It further explains the semantic search capability and return format, making the purpose unambiguous.
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 a specific use case ('um herauszufinden, was in den gelesenen Papern zu einem Thema steht') and implies it is for content-based queries. However, it does not explicitly contrast with sibling tools or state when not to use this tool.
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. Dates show when Glama detected each change.
v0.1.0analyze_projectcompare_experimentsget_experimentget_fold_summarylist_experimentslist_librarylist_projectsread_papersearch_papersEach tool targets a distinct aspect: library management (list_library, read_paper, search_papers), project overview (list_projects), and experiment analysis (list_experiments, get_experiment, get_fold_summary, analyze_project, compare_experiments). No overlap in purpose.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_library, read_paper, analyze_project). The naming is predictable and uniform.
With 9 tools covering paper library and experiment tracking, the toolkit is well-scoped for a research assistant. No redundant or missing tools for the core functionalities.
The tool set covers the full lifecycle for the domain: browsing papers (list, search, read), exploring projects, and analyzing experiments (list, get, compare, aggregate, fold stats). No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
Agentic search over your Dewey document collections from any MCP-compatible client.
Academic paper search, scientific literature, citation analysis, arXiv & semantic related-work.
Academic literature search, retrieval, and private library management on top of OpenAlex.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lduda79/research-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
