Northwestern University Libraries Digital Collections API
Server Details
Agent integration with the Northwestern University Libraries Digital Collections API
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- nulib/dc-api-v2
- GitHub Stars
- 15
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 8 of 8 tools scored.
Each tool has a reasonably distinct purpose: metadata retrieval (get-work), collection listing (list-collections), general search, semantic similarity search, and four different viewer tools. Some overlap exists between search and similarity-search, but their descriptions clarify the difference. The viewer tools are clearly separated by what they display.
Most tool names follow a verb_noun pattern (get-work, list-collections, view-work, etc.), but 'search' is a bare verb and 'similarity-search' is a reverse compound. Additionally, view-search-results references 'search-works' while the actual tool is named 'search', causing minor inconsistency.
With 8 tools, the server is well-scoped for a digital collections API. The mix of metadata retrieval, search, and interactive viewing tools covers the core needs without being excessive. Each tool appears necessary and earns its place.
The read-only domain is well covered with work metadata retrieval, collection listing, search, similarity search, and viewers. Notable gaps include a dedicated 'get-collection' metadata tool (only an interactive viewer exists) and a direct way to list works within a collection, though search can partially compensate via field filters.
Available Tools
8 toolsget-workGet WorkBRead-onlyIdempotentInspect
Retrieve the full metadata for a work from the NUL Digital Collections.
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | The ID of the work to retrieve |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it retrieves 'full metadata' and specifies the source (NUL Digital Collections), which is useful but does not disclose additional behavioral details like pagination or response format.
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?
The description is a single sentence that directly states the tool's purpose with no redundant information. It is front-loaded and every word contributes meaning.
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?
For a simple one-parameter retrieval with strong annotations and no output schema, the description adequately conveys the core behavior. It does not explain the difference from 'view-work', but that concern belongs more to usage guidance; overall it is sufficiently complete for its complexity.
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?
The input schema fully describes the single required parameter 'work_id' with a clear description, achieving 100% coverage. The tool description adds no extra detail about parameters, so the baseline of 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 clearly states the action 'retrieve' and the resource 'full metadata for a work', making the purpose clear. However, it does not differentiate from the sibling tool 'view-work', which likely serves a similar purpose, so it misses the top score.
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 guidance on when to use this tool versus alternatives like 'view-work' or 'search'. The description provides no context for selecting this tool over siblings, falling into the 'no guidance' category.
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.
| 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond identifying the resource source; it does not mention pagination, output format, or any constraints.
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?
The description is a single sentence with no redundant words. It opens with the action verb and immediately identifies the target resource, making it highly efficient.
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?
Given the tool's simplicity and the presence of a full output schema and annotations, the description is adequate but minimal. It does not mention that results are paginated or that public_only filtering exists, which would be useful context for an agent, but those details are available in the schema.
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 description coverage is 100%, so all three parameters (page, max_results, public_only) are already documented in the schema. The description does not add any additional parameter semantics or explain how they interact.
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 uses the specific verb 'List' and identifies the resource as 'collection records from the NUL Digital Collections.' It clearly states the function but does not explicitly differentiate from sibling tools like 'view-collection' or 'search'.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it returns a paginated list, nor does it reference sibling tools like 'search' or 'view-collection' for other use cases.
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.
| 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses key behaviors: natural language priority over fields, aggregation in results, empty search behavior, and exact-match semantics for quoted values. These are critical behavioral details not inferable from annotations.
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?
Four sentences, each earning its place: purpose, query/fields priority, aggregations, empty-search behavior, and a note on quoting. No redundant phrases; well-structured with a leading statement.
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?
For a search tool with 5 parameters and nested fields, the description covers combination behavior, result contents (aggregations), how to retrieve all works, and exact-match syntax. Combined with output schema and annotations, it is complete enough for an agent to select and invoke correctly.
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 covers 100% of parameter descriptions, but the description adds vital semantics: the interaction between query and fields, and the quoting rule for exact matches. This adds meaning beyond the schema, though parameter-level details remain in schema.
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 clearly states 'Search for works in the Digital Collections using field-based and/or natural language queries,' which identifies the specific action, resource, and query modes. It distinguishes from siblings like 'similarity-search' and 'get-work' by focusing on field/natural language search.
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?
Provides usage context by explaining when to use natural language ('exploratory / conceptual' per schema) vs structured fields ('specific known items or values'), and how they combine with natural language taking priority. However, it does not explicitly name alternative tools or state when not to use this tool, so not a 5.
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.
| 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
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds the useful behavioral detail that similarity is computed via semantic embeddings, which goes beyond basic annotations. With an output schema present, the lack of return-format details in the description is acceptable.
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?
The description is concise at two sentences, front-loaded with the core purpose, and contains no filler or redundancy. Every word adds value.
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?
Given the tool's moderate complexity (pagination, filtering), the description is adequate because the schema and output schema cover parameters and returns, and annotations cover safety. The only missing piece is explicit context on how results are ordered, but that is a minor gap and not critical for basic invocation.
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 has 100% parameter coverage with clear descriptions for all four parameters. The description does not add significant meaning beyond the schema, only referencing 'a given work' which maps to work_id, so the baseline score of 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 clearly states the tool finds works similar to a given work using semantic similarity, which is a specific verb+resource. However, it does not explicitly differentiate from the sibling tool 'view-similar-works', which appears to serve a similar purpose, so it lacks clear sibling distinction.
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?
No guidance is provided on when to use this tool versus alternatives like 'view-similar-works' or 'search'. There is no context about prerequisites, exclusions, or preferred scenarios, which leaves the agent without decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
view-collectionView CollectionARead-onlyIdempotentInspect
View a collection from the NUL Digital Collections in an interactive viewer.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | The ID of the collection to view |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'interactive viewer' detail, which hints at the mode of interaction but does not elaborate on what that entails (e.g., whether it returns a URL, HTML, or triggers a UI). With annotations doing most of the work, the description adds modest behavioral context.
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?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and context. Every word earns its place, with no redundancy or filler.
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?
The tool is simple with one parameter and no output schema. The description covers the essential purpose and the interactive-viewer aspect. While it doesn't detail the exact return format, the simplicity and strong annotations make the description adequate for an agent to use it correctly. A small gap is the ambiguity around 'interactive viewer', but it does not undermine usability.
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?
The input schema has 100% coverage for collection_id, with a clear description ('The ID of the collection to view'). The tool description adds no extra meaning beyond what the schema already provides, so it meets the baseline for high schema coverage.
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 clearly states the action ('View') and resource ('a collection'), adding context ('from the NUL Digital Collections') and a distinguishing feature ('in an interactive viewer'). This differentiates it from sibling tools like view-work or list-collections, which target different resources or modes.
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?
The description implies usage through its verb and resource, but it does not explicitly state when to use this tool versus alternatives like list-collections or view-work. There is no mention of prerequisites, exclusions, or preferred contexts, leaving the guidance at an implied level.
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 ResultsARead-onlyIdempotentInspect
View results from the search-works tool in an interactive viewer.
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'interactive viewer' notion but does not disclose behavioral details such as pagination behavior, statefulness (e.g., requiring prior search results), or return format, which would be valuable since there is no output schema.
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?
The description is a single, direct sentence that front-loads the core purpose without any filler or redundancy. Every word contributes meaning, and it is appropriately sized for a simple viewing tool.
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?
The schema documents all parameters thoroughly, and annotations cover safety characteristics. However, with no output schema, the description does not explain what the interactive viewer returns or whether prior search results are required. This leaves moderate gaps for a tool with nested parameters and a dependency on another tool.
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 description coverage is 100%, and the schema itself includes detailed descriptions for each parameter, including the nested 'fields' object and its many subfields. The tool description adds no parameter-specific information, so it relies on the schema, which is sufficient.
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 uses a specific verb ('View results') and a clear resource ('from the search-works tool'), which distinguishes this tool from siblings like 'search', 'view-work', and 'similarity-search'. It clearly states what the tool does and its relationship to the search workflow.
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?
The description implies that this tool should be used after the search-works tool, but it does not explicitly state when to use it vs. alternatives or provide exclusions. The schema descriptions offer guidance on query vs. field searches, but the tool description itself does not provide this context.
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.
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description adds minimal behavioral context ('interactive viewer'), but does not disclose pagination behavior, return format, or any other traits beyond the annotations. No contradiction with annotations.
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?
The description is a single, concise sentence that front-loads the action and resource. Every word contributes to the purpose, with no unnecessary elaboration or repetition of schema details.
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?
Given the tool's simplicity and the richness of annotations and schema, the description is minimally sufficient but not fully complete. With no output schema, it doesn't describe what the viewer returns or how to interact with results, and it offers no guidance on pagination or filtering beyond what the schema states.
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 description coverage is 100%, so all four parameters are already well-documented. The description does not add new semantic meaning to the parameters (work_id, page, max_results, public_only), but the schema covers them adequately, justifying the baseline score.
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 clearly identifies the tool as viewing results from the similarity-search tool, using a specific verb ('View') and resource ('results from the similarity-search tool'). It differentiates from siblings like view-search-results by referencing similarity-search, though it doesn't explicitly contrast with other viewers.
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?
The description provides clear context: this tool is for viewing results produced by the similarity-search tool. This implies the appropriate time to use it (after running a similarity search), but it doesn't explicitly exclude alternative viewers or mention when not to use it, stopping short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
view-workView WorkARead-onlyIdempotentInspect
View a work from the NUL Digital Collections in an interactive viewer.
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | The ID of the work to view |
Tool Definition Quality
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 safety profile is covered. The description adds the 'interactive viewer' behavior, but does not disclose error behavior, loading states, or any requirements. It does not contradict annotations, but adds only minimal context beyond them.
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?
The description is a single, front-loaded, purposeful sentence. Every word adds value: 'View' (action), 'work from NUL Digital Collections' (scope), 'interactive viewer' (modality). No wasted or redundant phrasing.
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?
This is a simple tool with one required parameter, no output schema, and non-destructive annotations. The description is sufficient for an agent to understand the tool's basic function. However, it lacks details about the viewer behavior, possible errors, or what the output looks like, but given the low complexity and rich annotations, it remains mostly complete.
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?
The input schema has one parameter (work_id) with a description ('The ID of the work to view'), giving 100% schema coverage. The tool description adds no additional meaning to the parameter. Since coverage is high, the baseline of 3 is appropriate.
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 clearly states the action ('View'), the resource ('work'), and the specific context ('NUL Digital Collections', 'interactive viewer'). This distinguishes it from sibling tools like 'get-work' which likely retrieves metadata, and 'view-collection' which handles collections. It is a specific verb+resource statement.
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?
Usage context is implied by the phrase 'interactive viewer' — this is for viewing works in a UI rather than retrieving raw data. However, there are no explicit 'when to use' or 'when not to use' instructions, and no comparison to alternatives like 'get-work' or 'view-search-results'. It is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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 Servers
- AlicenseAqualityBmaintenanceEnables 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.Last updated161MIT
- AlicenseAqualityAmaintenanceMCP server giving AI models direct access to 30M+ resources at ETH Library Zurich – books, maps, images, archival material, and linked-data person records.Last updated71MIT
- AlicenseAqualityAmaintenanceHosted MCP server for antiquarian first-edition identification and New Mexico book-donation logistics. 12 tools over a CC-BY, DOI-cited dataset of 6,700+ titles and 870 publisher conventions.Last updated12MIT