Teaching AI assistants to read the SSH Open Marketplace

A small experiment in making research infrastructure legible to LLM-based agents — and what it suggests about the broader relationship between AI and Research Infrastructures (RIs).

The discoverability gap

Research infrastructures in the Social Sciences and Humanities have, over the past decade, done a remarkable amount of work to expose data in a machine-readable and open format. The SSH Open Marketplace (SSHOMP) exposes every tool, training resource, dataset, publication and workflow in its catalogue through a public REST API. The schema is documented, the identifiers are persistent and the relations between items are explicit. From a purely technical standpoint, the resource graph is already there, ready to be traversed.

What is still missing is a layer of interpretive fluency: the ability to turn a researcher’s half-articulated need (“I want to get started with network analysis, but I’m not sure what’s out there”) into a sequence of API calls, and then into a synthesised, contextual answer. Historically that layer has been human — a data steward, a librarian, a colleague who happens to know the landscape. It doesn’t scale, and it doesn’t travel well across disciplines or languages. However, this interpretative layer is exactly what early career researchers in our DARIAH Community Engagement workshops regularly requested. Approaches exist, but naturally it is hard to find matching domain expertise and availability.

LLM-based assistants are increasingly plausible candidates for that layer. The question is what it takes to let them do it well.

What was built?

I put together a small “skill” — in Anthropic’s terminology, a self-contained package of instructions — that teaches Claude how to query the SSHOMP API effectively. It is short: around 200 lines of markdown, one file, no dependencies. What it encodes is:

• The base URL and the authentication model (none needed for read operations).
• Which endpoint to hit for free-text search, category-filtered search, autocomplete, and detail retrieval.
• The mapping from category (tool-or-service, training-material, etc.) to detail endpoint — something the API doesn’t make symmetrical.
• The shape of the response, with attention to the fields that matter for downstream synthesis (persistentId, accessibleAt, properties, relatedItems).
• A protocol for handling related items: process them as context on the first pass, and selectively fetch 2–3 of the most relevant at depth rather than expanding the whole graph.

The last point is where the skill earns its keep. A single item detail response already carries rich neighbourhood information — citing publications, related tools, training materials that teach the tool. Instructing the model to surface and grouped that information, rather than stopping at the first result, is the difference between “here’s a link” and “here’s a pathway”.

A worked example

Given the prompt “Help me find tools for network analysis”, the skill produces — in one or two turns — a ranked selection of approved tools (Vistorian, Gephi, VISONE, Sci2), paired with their metadata, URLs, and the training materials and datasets the Marketplace links to them. A follow-up prompt of “draft a learning pathway based on the resources” then produces a staged progression from no-code exploration (Vistorian, Onodo) through GUI analysis (Gephi, VISONE) to programmatic work (NetworkX, Programming Historian lessons) to four specialised branches: temporal, big-data, statistical, and multi-modal.

Every resource in that pathway comes from SSHOMP. Every persistent ID resolves. No hallucinated references, no stale links — because the model is reading the catalogue, not remembering it.

Why this matters for research infrastructures?

Three observations, in ascending order of interest.

First, the mechanical one: a good API and a small prose description are enough to unlock a meaningful layer of machine-mediated discovery. SSHOMP didn’t need to change. No endpoint was added, no schema extended. The work was interpretive, not structural.

Second, the epistemic one: the assistant’s output is only as good as the catalogue itself. When the pathway omitted certain resources, it was because they weren’t in SSHOMP under the search terms used, or their status was suggested rather than approved. This is arguably a feature — it makes the model’s limitations legible to curators and gives them a concrete handle on what to improve. “AI” here is a mirror for data quality, not a veil over it.

Third, the structural one: what RIs offer — curated, persistent, relationally linked resources — is exactly what LLM-based agents do badly on their own and need most. The relationship is naturally complementary. RIs supply the ground truth; models supply the interpretive glue. This is a more interesting framing, I think, than the dominant one of “AI assistants as competitors to curated infrastructure”. They are consumers of it.

How portable is this?

A natural question: is this skill LLM-agnostic?

Honestly, partially. The content is just markdown describing an API — any model capable of tool use could follow it. The packaging is specific to Claude: the SKILL.md format, the loading model, the .skill bundle. OpenAI’s custom GPTs, LangChain tool descriptions, and framework-specific agent instructions all serve the same purpose with different grammar. Porting the content is mechanical; none of the SSH-specific work would need to be redone.

The genuinely portable direction is MCP (Model Context Protocol), an open specification that several vendors now support. If SSHOMP exposed an MCP server, any MCP-compatible client — Claude Desktop, Cursor, an increasing range of others — could consume it directly. A skill is a pragmatic shortcut in the Claude ecosystem today; an MCP server would be the standards-based equivalent, and probably the right next step. Given similar skills for other DARIAH-services, we could easily increase the discoverability of resources across the RI.

Where this goes?

The skill, as it stands, is a prototype. It does read-only discovery; it doesn’t create, update, or curate. It lives in a single user’s environment rather than in any official DARIAH or SSHOMP deployment. What it demonstrates is not a finished product but a proof of concept: that the gap between “the API exists” and “a researcher gets a useful answer” can be closed with remarkably little code, provided the underlying infrastructure is in good shape.

For research infrastructures considering their relationship with AI assistants, I’d suggest the interesting work isn’t training models or building vertical chat interfaces. It’s the less glamorous layer underneath: making sure the API is clean, the metadata is rich, the relations between items are explicit, and — increasingly — that there is a standards-based way (MCP or its successors) for any compliant agent to consume what you’ve built. The rest takes care of itself.

You can find the skill here.

 

---

---