A
licenseA
qualityA
maintenanceEnables AI models to search and retrieve bibliographic and digitized records from Swiss academic libraries (swisscovery, e-rara, e-periodica, e-manuscripta) via open protocols without requiring API keys.
16
1
MIT
Northwestern University Libraries Digital Collections API
Server Details
Agent integration with the Northwestern University Libraries Digital Collections API
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- nulib/dc-api-v2
- GitHub Stars
- 15
Available Tools
8 toolsget-workGet WorkBRead-onlyIdempotentInspect
Retrieve the full metadata for a work from the NUL Digital Collections.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | The ID of the work to retrieve |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent operation, so the description does not need to re-state safety. It adds useful context that the result is the full metadata record from NUL Digital Collections, but it does not mention response shape, authentication needs, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or repetition. Every word contributes to identifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with rich annotations and no nested objects, the description is mostly complete: it names the collection, the action, and the output scope. It falls slightly short because the absence of an output schema is not compensated by any detail about the return structure, and the relationship to view-work is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter, work_id, already has a clear schema description. The tool description does not add meaningful detail about the expected format or provenance of work_id, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve'), a clear resource ('a work'), and a scope ('full metadata'), so an agent can tell this apart from search or list operations. However, it does not differentiate get-work from the similarly named sibling view-work, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as view-work, search, or similarity-search. The description states what it does but not the conditions that make it the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-collectionsList CollectionsBRead-onlyIdempotentInspect
List collection records from the NUL Digital Collections.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | The page of search results to return | |
| max_results | No | The maximum number of search results to return per page | |
| public_only | No | Only include publicly available works in search results |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The search results returned from the Digital Collections API |
| info | Yes | |
| explain | No | The explain output from Elasticsearch for the search query. Only included if the MCP is running in debug mode. |
| pagination | Yes | |
| aggregations | No |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is fully covered. The description adds modest context by framing the operation as listing records (plural), implying paginated enumeration consistent with the page/max_results parameters, but it does not disclose details like result ordering or pagination limits beyond what the schema's own parameter descriptions state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence with zero filler; the verb and object are front-loaded immediately. Given that the schema and annotations carry the remaining detail, nothing in the description is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with three optional parameters, an output schema, and full annotation coverage, the description is nearly complete. The only notable omission is usage routing context versus sibling tools, which is already penalized under usage_guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — all three parameters (page, max_results, public_only) have descriptions in the input schema, so the baseline of 3 applies. The description itself adds no parameter-level meaning, but this is acceptable because the schema carries the full documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('collection records from the NUL Digital Collections'), clearly conveying this is a browse/enumeration operation. However, it does not explicitly differentiate itself from sibling tools like view-collection or search, leaving the agent to infer the distinction between listing all collections and viewing one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as view-collection, search, or similarity-search. The single-sentence description provides no context about use cases, exclusions, or prerequisites, so an agent must rely on sibling names alone to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearchARead-onlyIdempotentInspect
Search for works in the Digital Collections using field-based and/or natural language queries. If both a natural language query and specific field values are provided, the natural language query will take priority, using the specified field values as additional constraints. The result will also include a list of aggregations that show how many results match different values for certain fields. For example, you could see how many results match each collection, work type, or visibility and use that information to refine your search. Perform an empty search to retrieve all works and their aggregations. NOTE: Structured field values enclosed in double quotes will be treated as exact, case-sensitive matches, while unquoted values will be treated as full-text searches.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | The page of search results to return | |
| query | No | A natural language query. Best for exploratory / conceptual searches. | |
| fields | No | Structured field search. Best when searching for specific known items or values, or for narrowing a search by specifying particular fields to search within. | |
| max_results | No | The maximum number of search results to return per page | |
| public_only | No | Only include publicly available works in search results |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The search results returned from the Digital Collections API |
| info | Yes | |
| explain | No | The explain output from Elasticsearch for the search query. Only included if the MCP is running in debug mode. |
| pagination | Yes | |
| aggregations | No |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses meaningful behaviors: query priority when both inputs are provided, inclusion of aggregations, empty-search behavior, and exact-match semantics for quoted field values. This gives an agent useful expectations before invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: it opens with the core purpose, explains priority and aggregations, covers the empty-search case, and ends with an important quoting note. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—nested fields, multiple parameters, and an output schema—the description covers the non-obvious usage aspects, including aggregation results, empty searches, and exact matching. The output schema handles return-value details, so no critical behavioral gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage, including descriptions for all nested fields. The description adds valuable semantics beyond the schema, especially the exact matching behavior for double-quoted field values and the priority rule when both query and fields are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for works in the Digital Collections using field-based and/or natural language queries, which is a specific verb and resource. It does not explicitly differentiate itself from the sibling similarity-search tool, but the scope and method are clearly communicated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage context: how natural language queries and structured fields interact, when to perform an empty search, and how aggregations can guide refinement. It does not explicitly discuss when to prefer this tool over sibling alternatives like similarity-search, but the internal usage guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
similarity-searchSearch for Similar WorksARead-onlyIdempotentInspect
Find works that are similar to a given work. Uses semantic similarity based on work embeddings.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | The page of search results to return | |
| work_id | Yes | ID of a work to find similar items for. | |
| max_results | No | The maximum number of search results to return per page | |
| public_only | No | Only include publicly available works in search results |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | The search results returned from the Digital Collections API |
| info | Yes | |
| explain | No | The explain output from Elasticsearch for the search query. Only included if the MCP is running in debug mode. |
| pagination | Yes | |
| aggregations | No |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so the description does not need to repeat those traits. It adds useful context by explaining the results come from semantic embeddings, but it does not disclose further behavioral details such as result ranking or pagination behavior. This is acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no redundant language. It conveys the core purpose and the mechanism without wasting the agent's attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, full parameter documentation, and safety-related annotations, the description is largely complete for invoking the tool correctly. The only meaningful gap is the lack of guidance around sibling tools, but that is more about routing than about calling this tool successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents work_id, page, max_results, and public_only with defaults and bounds. The description adds no parameter-specific meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: 'Find works that are similar to a given work.' The added mechanism 'semantic similarity based on work embeddings' clarifies how results are computed. It is unambiguous, though it does not explicitly distinguish itself from sibling tools like view-similar-works, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is clear from the first sentence, but the description gives no explicit guidance on when to use this tool instead of related siblings such as search or view-similar-works. No exclusions or alternatives are mentioned, leaving the routing decision to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
view-collectionView CollectionBRead-onlyIdempotentInspect
View a collection from the NUL Digital Collections in an interactive viewer.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | The ID of the collection to view |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| iiifContentUrl | Yes | A URL to a IIIF manifest or collection |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the safety profile is clear. The description adds only 'interactive viewer' as behavioral context, which hints at the presentation mode but does not explain output form or any viewer prerequisites. This is acceptable given the strong annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler or redundancy. The verb and resource are front-loaded, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with rich annotations and an output schema, the description is largely sufficient. Missing guidance about using list-collections to find a collection_id is a minor gap, but the tool is simple enough that an agent can infer the workflow from sibling names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: collection_id is already described as 'The ID of the collection to view.' The description adds domain context ('NUL Digital Collections') but no additional parameter-level semantics, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('View') and resource ('a collection from NUL Digital Collections'), and 'interactive viewer' hints at a distinct mode from sibling tools like list-collections. It does not explicitly contrast with sibling view tools, but the resource type makes 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to use this tool instead of list-collections, get-work, or view-work, nor does it mention how an agent should obtain a collection_id. Sibling tools are not referenced at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
view-search-resultsView Search ResultsCRead-onlyIdempotentInspect
View results from the search-works tool in an interactive viewer.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | The page of search results to return | |
| query | No | A natural language query. Best for exploratory / conceptual searches. | |
| fields | No | Structured field search. Best when searching for specific known items or values, or for narrowing a search by specifying particular fields to search within. | |
| max_results | No | The maximum number of search results to return per page | |
| public_only | No | Only include publicly available works in search results |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| iiifContentUrl | Yes | A URL to a IIIF manifest or collection |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the description only needed to add behavioral context. Instead, it says the tool 'View[s] results from the search-works tool in an interactive viewer,' while the schema description says it 'Search[es] for items in the Digital Collections' using queries and field filters. This mismatch misleads the agent about what the tool actually does and omits behavior like pagination, default result limits, and public-only filtering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It front-loads the action ('View results'), though it is too terse to convey the tool's actual search behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema, detailed nested parameters, and helpful annotations, the description is not complete enough for an agent to decide when to use this tool. It fails to explain how this relates to the sibling 'search' tool, whether it requires prior results, or that the input schema performs a new search. The vagueness is particularly damaging given the tool's complex param structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter description coverage, including detailed descriptions for all five top-level parameters and nested field properties. The tool description adds no parameter-specific semantics, but the schema already carries the full burden, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource ('View results from the search-works tool') and is not a tautology. However, 'interactive viewer' is vague, and the tool's input schema actually describes a search operation ('Search for items in the Digital Collections'), so the purpose is unclear and not distinguished from sibling tools like 'search' or 'view-work'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It only references a 'search-works tool,' implying some prior search step, but does not state whether this tool should be used after searching, instead of 'search,' or when viewing existing results. This is especially confusing because the schema indicates the tool itself performs searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
view-similar-worksView Similar WorksARead-onlyIdempotentInspect
View results from the similarity-search tool in an interactive viewer.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | The page of search results to return | |
| work_id | Yes | ID of a work to find similar items for. | |
| max_results | No | The maximum number of search results to return per page | |
| public_only | No | Only include publicly available works in search results |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| iiifContentUrl | Yes | A URL to a IIIF manifest or collection |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds the 'interactive viewer' framing, which implies a display surface rather than a raw data return. It does not add much beyond that, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler, and the core action ('View results') is front-loaded. The description is appropriately sized for a tool whose safety profile and return shape are already captured by annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only viewer with an output schema and a fully documented input schema, the description is mostly complete. What is missing is explicit differentiation from view-search-results, which could prevent an agent from choosing the right tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents page, work_id, max_results, and public_only. The description adds only that the results come from similarity-search, giving no extra parameter-level meaning beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('View') and names a concrete resource: results from the similarity-search tool, delivered in an interactive viewer. It clearly distinguishes this from the computation tool similarity-search, though it does not explicitly differentiate from the similarly named sibling view-search-results, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'results from the similarity-search tool' gives an implied usage context: call this after or for similarity-search results. However, it provides no explicit when-not-to-use guidance or comparison with view-search-results, leaving the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
view-workView WorkBRead-onlyIdempotentInspect
View a work from the NUL Digital Collections in an interactive viewer.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | The ID of the work to view |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| iiifContentUrl | Yes | A URL to a IIIF manifest or collection |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the tool is read-only and non-destructive. The description adds the behavioral context that the work is shown in an interactive viewer, which is useful, but it does not explain what the interaction or output entails beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and front-loaded with the key action. It adds useful context ('NUL Digital Collections', 'interactive viewer') despite slightly echoing the tool name and title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with complete schema coverage, clear annotations, and an output schema, the description is mostly sufficient. The main gap is the lack of explicit differentiation from sibling tools, but nothing critical is missing for a basic call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single required parameter work_id is already documented in the schema. The description does not add any additional parameter meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('View') and a resource ('a work from the NUL Digital Collections'), and adds the distinctive detail 'in an interactive viewer.' It is clear, though it does not explicitly differentiate itself from the sibling get-work tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get-work or view-search-results. The 'interactive viewer' phrase implies a UI-oriented use case, but no explicit context, conditions, or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
8 tool updates
- Changed
get-work1 field changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
list-collections2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
search2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
similarity-search2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
- Changed
view-collection2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "iiifContentUrl": { + "description": "A URL to a IIIF manifest or collection", + "format": "uri", + "type": "string" + } + }, + "required": [ + "iiifContentUrl" + ], + "type": "object" +}
- Changed
view-search-results2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "iiifContentUrl": { + "description": "A URL to a IIIF manifest or collection", + "format": "uri", + "type": "string" + } + }, + "required": [ + "iiifContentUrl" + ], + "type": "object" +}
- Changed
view-similar-works2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "iiifContentUrl": { + "description": "A URL to a IIIF manifest or collection", + "format": "uri", + "type": "string" + } + }, + "required": [ + "iiifContentUrl" + ], + "type": "object" +}
- Changed
view-work2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "iiifContentUrl": { + "description": "A URL to a IIIF manifest or collection", + "format": "uri", + "type": "string" + } + }, + "required": [ + "iiifContentUrl" + ], + "type": "object" +}
1 tool update
- Changed
list-collections4 fields changed- added
Output schema / properties / data / items / properties / description / anyOfAdded value: +[ + { + "description": "A brief description of the search result item", + "type": "string" + }, + { + "type": "null" + } +] - removed
Output schema / properties / data / items / properties / description / descriptionRemoved value: -"A brief description of the search result item" - removed
Output schema / properties / data / items / properties / description / typeRemoved value: -"string" - changed
Output schema / properties / data / items / requiredPrevious value: -[ - "id", - "title", - "description", - "thumbnail", - "iiif_collection", - "visibility" -]New value: +[ + "id", + "title", + "thumbnail", + "iiif_collection", + "visibility" +]
8 tool updates
- First observed
get-work - First observed
list-collections - First observed
search - First observed
similarity-search - First observed
view-collection - First observed
view-search-results - First observed
view-similar-works - First observed
view-work
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
W3C DID issuance and verification for autonomous AI agents
Wayback Machine for agents: closest archived copy of a URL with its text, and full capture history
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables MCP agents to discover, import, query, visualize, select, and cite NEON and local scientific datasets while keeping credentials, private paths, and bulk data out of model context.MIT
- AlicenseAqualityAmaintenanceMCP server giving AI models direct access to 30M+ resources at ETH Library Zurich – books, maps, images, archival material, and linked-data person records.71MIT
- FlicenseAqualityBmaintenanceEnables an OpenTrek-hosted agent to persist research activities, project status, and advisor requirements, and generate evidence-based progress reports via MCP tools.16-
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
B3.4/5.0
Disambiguation4/5
Most tools have clear boundaries: search and similarity-search are distinct query modes, and view-* tools are explicitly for interactive viewing while get-work and list-collections return metadata. However, get-work vs view-work and list-collections vs view-collection could cause mild confusion, and view-search-results refers to a 'search-works' tool that is actually named 'search'.
Naming Consistency3/5
Tool names mostly follow a lowercase hyphenated verb-object pattern like get-work, list-collections, and view-work. However, 'search' lacks an object, 'similarity-search' is formatted as a compound noun rather than a verb phrase, and the description for view-search-results references a non-existent 'search-works' tool name.
Tool Count5/5
Eight tools is a well-scoped set for a digital collections API. Each tool serves a distinct function covering search, retrieval, similarity, and interactive viewing without feeling bloated or sparse.
Completeness4/5
The tool surface covers the core read-only workflows: searching, similarity matching, retrieving work metadata, listing collections, and viewing results interactively. A minor gap is the lack of a direct get-collection metadata tool separate from list-collections, but agents can likely work around this.