[ANN] dspace-mcp — a read-only MCP server for querying DSpace 7+ with an AI assistant
18 views
Skip to first unread message
micha...@gmail.com
Jul 22, 2026, 2:01:18 PM (9 days ago) Jul 22
to dspace-c...@googlegroups.com, dspac...@googlegroups.com
(Apologies for cross-posting.)
Hello everyone,
I have released dspace-mcp, a small open source tool that lets an AI
assistant — Claude, or any other MCP-capable client — query a DSpace 7+
repository through its REST API.
assistant — Claude, or any other MCP-capable client — query a DSpace 7+
repository through its REST API.
In practice it means you can ask your repository questions in plain
language: "how many theses did we publish in 2025?", "which authors
appear most often in this collection?", "summarise the PDF attached to
this item". The assistant answers by calling the DSpace REST API, not by
guessing.
language: "how many theses did we publish in 2025?", "which authors
appear most often in this collection?", "summarise the PDF attached to
this item". The assistant answers by calling the DSpace REST API, not by
guessing.
Read-only by construction
-------------------------
This is the part I would want to know about first, and the reason I built
it this way. The server holds no credentials and issues nothing but GET
requests. It cannot deposit, edit or delete anything, and it cannot see
more than an anonymous visitor can — embargoed items, workflow
submissions and restricted collections stay invisible. That is a property
of the code rather than of the model's good behaviour: there is no write
path to prompt-inject your way into, and a test in the suite asserts that
no other HTTP method ever leaves the process.
-------------------------
This is the part I would want to know about first, and the reason I built
it this way. The server holds no credentials and issues nothing but GET
requests. It cannot deposit, edit or delete anything, and it cannot see
more than an anonymous visitor can — embargoed items, workflow
submissions and restricted collections stay invisible. That is a property
of the code rather than of the model's good behaviour: there is no write
path to prompt-inject your way into, and a test in the suite asserts that
no other HTTP method ever leaves the process.
I am willing to help to provide a version that writes to the repo from
an LLM as soon as somebody presents an actual use-case to me.
Try it against the demo instance
--------------------------------
No installation and no local DSpace needed:
--------------------------------
No installation and no local DSpace needed:
uvx dspace-mcp --base-url https://demo.dspace.org/server
For Claude Code:
claude mcp add dspace -- uvx dspace-mcp --base-url https://YOUR-REPO/server
Point --base-url at your own repository's REST API (normally your DSpace
URL with /server appended).
URL with /server appended).
What it exposes
---------------
Nine tools: search items (with year, author and collection filters),
fetch an item by UUID, Handle or DOI, walk communities and collections,
list bitstreams, extract PDF text, count facet values (authors, subjects,
years) server-side, item view statistics, and a repository-info call that
reports which search filters, sort fields and facets your particular
instance actually supports — since that is configured per installation
and differs from site to site.
---------------
Nine tools: search items (with year, author and collection filters),
fetch an item by UUID, Handle or DOI, walk communities and collections,
list bitstreams, extract PDF text, count facet values (authors, subjects,
years) server-side, item view statistics, and a repository-info call that
reports which search filters, sort fields and facets your particular
instance actually supports — since that is configured per installation
and differs from site to site.
Counting is deliberately cheap: "how many" questions are answered with a
single request and a facet count, instead of downloading records.
single request and a facet count, instead of downloading records.
Compatibility
-------------
Verified against DSpace 7.2.1, 7.5, 7.6.5, 8.2, 8.4, 9.2, 10.1 and
11.0-SNAPSHOT. The test suite runs against recorded responses from real
instances of versions 7, 8, 10 and 11.
-------------
Verified against DSpace 7.2.1, 7.5, 7.6.5, 8.2, 8.4, 9.2, 10.1 and
11.0-SNAPSHOT. The test suite runs against recorded responses from real
instances of versions 7, 8, 10 and 11.
MIT licensed. This is an independent project — not affiliated with or
endorsed by LYRASIS or the DSpace project.
endorsed by LYRASIS or the DSpace project.
Feedback, bug reports and pull requests are very welcome, particularly
from anyone running a version or configuration I have not tested against.
If it misbehaves on your instance I would like to hear about it:
from anyone running a version or configuration I have not tested against.
If it misbehaves on your instance I would like to hear about it:
Demo
----
Using Claude Opus 4.8 via Claude Code, I asked the LLM "Using dspace-mcp
please prepare 10 quick facts about demo.dspace.org repository" and the
text is below. Claude when asked is pretty capable to present interesting
infographics about a repo.
demo.dspace.org — 10 quick facts (pulled live via the DSpace MCP server)
========================================================================
========================================================================
1. Version & scale. It runs DSpace 10.1-SNAPSHOT (a pre-release build)
and holds 505 items across 54 collections and 56 communities — 41 of
those communities are top-level, so ~15 are sub-communities.
and holds 505 items across 54 collections and 56 communities — 41 of
those communities are top-level, so ~15 are sub-communities.
2. It is a configured entity repository. Items are typed: 265
Publications, 72 Projects, 68 Persons, 30 OrgUnits, 18 JournalIssues,
13 Journals, 6 JournalVolumes. Barely half the "items" are actual
publications — the rest are related entities.
Publications, 72 Projects, 68 Persons, 30 OrgUnits, 18 JournalIssues,
13 Journals, 6 JournalVolumes. Barely half the "items" are actual
publications — the rest are related entities.
3. Almost nothing has files attached. Only 79 of 505 items (16%) have
content in the ORIGINAL bundle; 426 are metadata-only. Access status
mirrors this: 426 metadata.only, 78 open.access, 1 embargoed item.
content in the ORIGINAL bundle; 426 are metadata-only. Access status
mirrors this: 426 metadata.only, 78 open.access, 1 embargoed item.
4. One author dominates absurdly. "Simmons, Cameron" is credited on 190
items — 38% of the whole repository. The runner-up, De Wael,
Karolien, has 7. This is seeded test data, not a real signal.
items — 38% of the whole repository. The runner-up, De Wael,
Karolien, has 7. This is seeded test data, not a real signal.
5. Content clusters in the 2010s. By decade: 1996–1999 → 11,
2000–2009 → 56, 2010–2019 → 181, 2020–2026 → 24. Note that only 272
items have a usable date at all.
2000–2009 → 56, 2010–2019 → 181, 2020–2026 → 24. Note that only 272
items have a usable date at all.
[...]
--
Best regards, Michał Pasternak
Reply all
Reply to author
Forward
0 new messages