dspace-mcp 0.3.1

Read-only MCP server for DSpace 7+ repositories

dspace-mcp

The Claude Desktop installer prompts for your repository URL. The Cursor and VS Code links carry DSPACE_BASE_URL empty on purpose — fill in your own instance (the /server REST endpoint), or the server refuses to start rather than guess and hand you someone else's repository.

A read-only MCP server that lets an AI assistant talk to any DSpace 7+ repository.

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" — and the assistant answers by querying the DSpace REST API directly.

It works anonymously out of the box: no account, no configuration beyond the repository URL, and it sees exactly what any visitor sees. You can optionally give it a DSpace username and password, and it will then also read what that account can read — embargoed items, restricted collections and closed files — and can tell you which files the public cannot reach. Logging in is never required, and it never grants the ability to change anything.

Read-only by construction, not by promise

The server cannot deposit, edit or delete anything. Every request that carries data is a GET; the only other request it can make in its entire codebase is the login POST described below, to one hard-coded path. There is no code path that sends PUT, PATCH, DELETE, or a POST anywhere else — so there is nothing to prompt-inject your way into.

That is a property of the code, not of the model's behaviour, and the test suite holds it in place: one test asserts that the only non-GET request ever sent goes to exactly <base-url>/api/authn/login, and another reads the package source to confirm no mutating method appears anywhere in it.

By default the server queries anonymously and sees exactly what any visitor sees: embargoed items, workflow submissions and restricted collections stay invisible. Give it an account (below) and it reads what that account can read — and still cannot change a thing.

Reading non-public material (optional)

Set a username and password and the server logs in at startup, then reads with your account's permissions:

export DSPACE_USERNAME='[e-mail]'
export DSPACE_PASSWORD='...'
uvx dspace-mcp --base-url https://repo.example.org/server

Use the least-privileged account that covers what you need. The server reads everything that account is allowed to read, so pointing it at an administrator account gives the assistant an administrator's view. It cannot modify anything either way, but it can see a great deal.

Logging in adds one tool, compare_access, which answers the question this feature exists for — "the user says files are missing":

compare_access(item="123456789/4271")
→ { "visible_to_anonymous": true,
    "files": { "both": ["abstract.pdf"],
               "authenticated_only": ["full-text.pdf"] },
    "summary": "1 of 2 file(s) are not available to anonymous users." }

It asks twice — once as your account, once anonymously through a separate connection with its own cookie jar — and reports only the difference.

Three things worth knowing:

• If the login fails, the server stops and asks. It does not quietly fall back to anonymous access, because that would make the assistant report "no such record" for material you can plainly see. Instead every tool returns a question, and the assistant puts the choice to you: fix the credentials and restart, or explicitly continue with public data only.
• Only password login is supported. Repositories that authenticate solely through ORCID or Shibboleth need a browser, which a stdio process has no way to open. The server detects this from the instance itself and says so rather than failing obscurely.
• Prefer the environment variable over --password. A command line is visible to every process on the machine. The .mcpb bundle stores the password in your operating system's keychain.

Install

Nothing to install if you have uv:

uvx dspace-mcp --base-url https://demo.dspace.org/server

Or with pip:

pip install dspace-mcp

Configure your MCP client

Claude Code:

claude mcp add dspace -- uvx dspace-mcp --base-url https://demo.dspace.org/server

Claude Desktop / any client using mcp.json:

{
  "mcpServers": {
    "dspace": {
      "command": "uvx",
      "args": ["dspace-mcp", "--base-url", "https://demo.dspace.org/server"]
    }
  }
}

Point --base-url at your own repository's REST API — usually your DSpace URL with /server appended. If you leave /server off, the server detects it and corrects the URL for you.

To connect to several repositories, add several entries under different names. One process serves exactly one repository, which keeps the assistant from mixing them up.

Tools

Tool	What it does
search_items	Search items; filter by year range, author, collection; sort by relevance, date or title. limit=0 returns just the count.
get_item	Fetch one item by UUID, Handle or DOI — whichever identifier you happen to have.
list_communities	Walk the community tree (up to 3 levels).
list_collections	List collections, of one community or of the whole repository.
list_bitstreams	List an item's files with sizes, MIME types, checksums and download URLs.
get_bitstream_text	Extract the text of a bitstream so the assistant can read or summarise it — PDF, Word (.docx/.doc), OpenDocument (.odt/.ods/.odp) and Office XML (.pptx/.xlsx).
list_facet_values	Count values of a facet (authors, subjects, years) — the repository does the counting, so no records are downloaded.
get_item_statistics	View count of an item.
get_repository_info	Name, version, item counts, which search filters, sort fields and facets this instance actually supports, and whether the server is querying anonymously or as an account.

Two more tools appear only if you configure an account — an anonymous install never sees them:

Tool	What it does
compare_access	Compare what your account can see against what the public can see, for one item. Answers "the user says files are missing".
continue_anonymously	Only reachable if the login failed: lets you choose to carry on with public data instead of fixing the credentials.

Two things worth knowing

Ask get_repository_info first. DSpace installations differ: the set of search filters and facets is configured per instance, so a filter that exists on one repository returns an error on another. This tool reports what the instance in front of you supports.

Counting is free. search_items with limit=0, and list_facet_values, answer "how many" questions with a single request and a handful of tokens, instead of downloading records and counting them.

Configuration

Variable	Default	Meaning
DSPACE_BASE_URL	(required)	REST API root, e.g. https://demo.dspace.org/server
DSPACE_TIMEOUT	15	seconds per HTTP request
DSPACE_MAX_RESULTS	50	hard ceiling on how many records any tool may return
DSPACE_EXTRACT_MAX_MB	20	refuse to download bitstreams larger than this for text extraction
DSPACE_USERNAME	(none)	log in as this account to also read non-public material
DSPACE_PASSWORD	(none)	password for that account

Every variable has a matching flag: --base-url, --timeout, --max-results, --extract-max-mb, --username, --password.

Set both DSPACE_USERNAME and DSPACE_PASSWORD or neither — half an account is a configuration mistake, and the server says so at startup instead of silently querying anonymously.

DSPACE_PDF_MAX_MB / --pdf-max-mb still work as backward-compatible aliases for DSPACE_EXTRACT_MAX_MB / --extract-max-mb from before text extraction covered more than PDF.

Compatibility

Nothing here branches on a version number. The server asks each instance which search filters, sort fields and facets it supports and works from that answer, which is what actually varies between installations — two sites on the same DSpace version can differ more than two versions of the same site.

The offline test suite runs against recorded responses from a live DSpace 10.1-SNAPSHOT (demo.dspace.org), covering every endpoint the server touches, plus root and search responses from a vanilla 7.6.5, a DSpace-CRIS 8.2 and an 11.0-SNAPSHOT for comparing response shape. The contract tests (pytest -m live) run against one instance at a time — demo.dspace.org by default, or point DSPACE_TEST_URL at your own.

While the tool was being designed, its assumptions about the REST API were checked by hand against live instances of 7.2.1, 7.5, 7.6.5, 8.2, 8.4, 9.2, 10.1 and 11.0-SNAPSHOT. That was a survey of the API, not a test run of this code. If it misbehaves on a version or a configuration I could not test, a bug report is welcome.

Development

git clone https://github.com/mpasternak/dspace-mcp
cd dspace-mcp
uv sync --dev
uv run pytest              # unit tests, offline
uv run pytest -m live      # contract tests against demo.dspace.org
uv run ruff check .

Contributions are welcome. The design and its rationale — including why several plausible-sounding assumptions about the DSpace API turned out to be wrong — live in docs/superpowers/specs/.

License

MIT — see LICENSE.