get_research_itemResearch-item metadata, linked entities, rights, media files, IIIF manifest and a generated citation (BibTeX/RIS/CSL-JSON). Long fields cap at 25,000 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Omeka id (the number ending its amira_url, e.g. 9902) or a typed id such as research_item:9902 | |
| citation_format | No | Export format for the generated citation: bibtex (default) → `bibtex`, ris → `ris`, csl-json → `csl_json` |
Changes observed during successful MCP inspections.
Input schema / properties / id / descriptionPrevious value: -"Omeka id (the number ending its amira_url, e.g. 7392) or a typed id such as research_item:7392"New value: +"Omeka id (the number ending its amira_url, e.g. 9902) or a typed id such as research_item:9902"Input schema / properties / id / anyOfAdded value: +[
+ {
+ "maxLength": 1000,
+ "type": "string"
+ },
+ {
+ "type": "number"
+ }
+]Input schema / properties / id / descriptionPrevious value: -"The item's Omeka o:id — the number ending its amira_url, e.g. 7392. Legacy DRE keys also work"New value: +"Omeka id (the number ending its amira_url, e.g. 7392) or a typed id such as research_item:7392"Input schema / properties / id / typeRemoved value: -[
- "string",
- "number"
-]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered; the description adds genuinely new behavioral facts, namely that long fields are truncated at 25,000 characters and that the payload aggregates linked entities, media, IIIF and a generated citation. It stops short of describing truncation signalling or what happens when an id is not found.
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?
A single dense sentence with no filler, and the payload enumeration is front-loaded. It loses a point only because the most decision-relevant information (the retrieval verb and its scope) is omitted rather than compressed.
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?
With no output schema, the description usefully compensates by listing what the caller receives, plus the truncation cap. It is adequately complete for a two-parameter read tool, though it never clarifies the id-form distinction that the schema itself carries.
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 100%, so both parameters (and the accepted id forms) are already documented in the schema. The description restates the three citation formats but adds no syntax or default behavior beyond the enum values already present, so baseline 3 applies.
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 enumerates the response payload (metadata, linked entities, rights, media files, IIIF manifest, citation) but never states a verb or the resource being acted on; the ''get by id'' intent is only recoverable from the title and the schema. It also draws no boundary against siblings such as search_research_items, resolve_entity, or fetch, which an agent must choose between.
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?
There is no when-to-use guidance and no mention of alternatives, despite several plausible competing tools in the sibling list (search_research_items, fetch, resolve_entity, get_entity_graph). The citation_format capability is surfaced but without saying when one would request it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.