archival-imagery-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
Disambiguation5/5
Each tool is clearly scoped to a specific institution and action (search vs. fetch vs. utility). The institution prefixes make it immediately clear which API a tool targets, and search/fetch pairs within each institution are unambiguous. Even the generic download_image is distinct as a utility.
Naming Consistency4/5
The naming follows a predictable {institution}_{search|get_*} pattern for the source-specific tools, with snake_case throughout. The only deviation is wellcome_image_url, which uses a noun phrase instead of a verb, but it is still recognizable and consistent in style.
Tool Count5/5
12 tools is well-scoped for a multi-institution archival imagery server. Each institution has at least a search and a fetch tool, plus a generic download utility and a IIIF URL builder. No tool feels redundant or unnecessary.
Completeness5/5
The server covers the complete lifecycle for the domain: search each institution's collections, retrieve detailed metadata and image URLs, and download images. All included institutions have both search and fetch capabilities, so there are no dead ends or obvious missing operations.
Average 3.9/5 across 12 of 12 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that no API key is needed and that the category parameter can restrict the search, which is useful behavioral context. However, it doesn't describe return format, pagination, rate limits, or other operational traits, leaving significant gaps for an unannotated tool.
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 three sentences, front-loaded with the resource and purpose, and keeps extra details short. Every sentence earns its place, though the ordering of 'no API key' before the category instruction could be slightly improved. Overall it's concise and readable.
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?
For a search tool with no output schema, the description doesn't explain what results look like or how to use related tools like loc_get_item. It mentions collection scope but lacks details on pagination, query syntax, or integration with siblings. The description provides a basic foundation but is incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only category has a description). The description reinforces category usage with examples but fails to explain 'query' (the required parameter) or 'pageSize' (with a default). Since coverage is low, the description should compensate more, but it does the bare minimum for category only.
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 identifies the tool as a search for the Library of Congress, using the verb 'Search' and a specific resource. It also lists the collection types, which adds useful scope. However, it doesn't explicitly contrast with sibling search tools, so it falls short of fully distinguishing itself beyond the resource name.
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 description gives some usage context: it notes there is no API key and hints at using the category parameter to restrict results. But it doesn't explicitly state when to use this tool over other museum search tools (e.g., wellcome_search, met_search) or mention exclusion scenarios. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses what the tool returns (image URLs and metadata), but does not mention authentication, rate limits, error handling, or any other behavioral constraints. Basic operational facts are present, but no deeper transparency.
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 that conveys the essential purpose and output without any wasted words. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers the core purpose and main output, but lacks caveats about missing IDs, authentication requirements, or possible response limitations. It's minimally viable but leaves some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'id' as a string, and the description adds no additional meaning beyond restating 'by ID'. There is no guidance on the format, source, or examples of the ID, which is a significant gap given 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Fetch), the resource (Smithsonian object), and the method (by ID), while also noting the included content (all image URLs and metadata). This distinguishes it from search tools and other museum-specific get tools.
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 description implies that the tool is used when you have an ID and need full object details, but it does not explicitly say to use search first or provide any when/when-not alternatives. The usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does mention the return content (all image URLs and metadata), but it does not address read-only safety, error handling, or potential limitations. This is a simple fetch operation, so the risk is low, but more transparency could be provided.
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 a single, front-loaded sentence with no fluff. It efficiently conveys the core action, resource, and return value.
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?
Given the low complexity (single parameter, no output schema), the description adequately explains the return content. However, it omits usage context and edge-case behavior, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only says 'numeric ID', which merely echoes the schema's type 'number'. It does not name the parameter 'objectId' or add constraints, ranges, or examples, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a Met object by numeric ID, listing the return content (image URLs and metadata). This distinguishes it from sibling tools like met_search (search vs. fetch) and other museum get tools (specific to the Met).
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 explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where another tool (e.g., met_search) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It reveals that the search defaults to CC0-only images and requires an API key, which is valuable. Missing are details about return format, pagination, error handling, or what happens without a valid key, so behavioral disclosure is partial.
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 sentences, front-loaded with the primary action, followed by essential details on default behavior and prerequisites. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one required parameter and no output schema, the description covers scope and authentication, but lacks return value expectations, parameter detail, and pagination/error behavior. This leaves the agent with moderate completeness; it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only hints at 'onlyCC0' via 'defaults to CC0-only images' and implies 'query' from the act of searching. 'pageSize' receives no explanation, and there is no explicit mapping of parameters to behavior, leaving the agent with limited semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Smithsonian Open Access with a specific verb ('Search') and resource ('Smithsonian Open Access'), distinguishing it from sibling museum search tools (e.g., wellcome_search, met_search). The item count (4.5M+) adds useful context without confusing the core purpose.
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 clear context that this tool is for Smithsonian Open Access searches, which implicitly steers usage away from sibling tools for other institutions. It also mentions a required API key, an important precondition. However, it does not explicitly state when to use it vs alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that this is a fetch (read-only) operation and that the response includes all associated IIIF image URLs. However, it does not describe error behavior, response format validity, or any potential rate limits, leaving some gaps.
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 a single, front-loaded sentence with no filler. Every word adds value in specifying the action, resource, and key output detail.
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?
Given the tool's simplicity (1 parameter, no output schema), the description covers the primary purpose and the notable return behavior (IIIF image URLs). It does not explain error cases or full response structure, but these are secondary for a straightforward fetch operation.
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 0%, so the description must compensate. It does so by indicating that the 'id' parameter is the Wellcome work identifier, but it lacks examples or format details. For a single parameter, this is adequate but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Fetch'), the target resource ('Wellcome work'), and the unique distinguishing feature (includes IIIF image URLs). This clearly differentiates it from sibling tools like wellcome_search and wellcome_image_url.
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 description implies usage: when you have a Wellcome work ID and need the work with its IIIF image URLs. It provides no explicit exclusions or comparisons to alternatives like wellcome_search or wellcome_image_url, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose a useful side-effect (parent directories are created automatically) and broad source compatibility, but does not mention return values, error handling, or whether existing files are overwritten. It is adequate but not rich.
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?
Three short sentences with no wasted words. The primary purpose is front-loaded, and each sentence adds a distinct piece of information (what, side-effect, source compatibility).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but because there is no output schema and no annotations, the description should explain what the tool returns or how success/failure is indicated. It does not mention the return value or error scenarios, leaving a gap. The description is clear but not fully complete for an agent to invoke without assumptions.
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 coverage is 50%, with only savePath having a description. The description clarifies the overall function (url to local file path) but does not add specific details about the URL format or constraints beyond what is already implied by the tool name and schema. It compensates partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads any image URL to a local file path, using a specific verb and resource. It also distinguishes itself from the sibling search/get tools by noting it works with images returned from those sources.
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 implies usage context by stating it works with images from any of the above sources, which guides the agent to use this tool when a URL is available. However, it does not explicitly state when not to use it or name alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It reveals a critical prerequisite (EUROPEANA_API_KEY env var) and a behavioral default (open-licensed media only), but does not describe what the search returns, pagination behavior, rate limits, or error handling. The default is also already visible in the schema, so the description adds less unique value here.
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 compact sentences with zero fluff. It front-loads the core purpose, then supplies the default behavior and the API key requirement. Every clause earns its place and the structure is ideal for quick scanning.
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?
Given the lack of an output schema and annotations, the description covers the essential facts for invoking the tool: what it searches, the default open-license filter, and the required environment variable. It does not describe the return shape, but that is not critical for correct invocation. The inclusion of example institutions helps with the provider parameter. It is complete enough for an agent to use the tool correctly.
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 50% (onlyOpen and provider have descriptions). The description does not clarify the semantics of 'query' or 'pageSize', though these are self-explanatory from names. It provides helpful context about provider examples by naming institutions, but overall it adds limited value beyond the schema for the remaining parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Search Europeana', a specific verb and resource. It also names the aggregator and examples of included institutions, which clearly distinguishes this search tool from sibling tools like wellcome_search or met_search, and from europeana_get_record which is for retrieving a specific record.
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 provides clear context: this tool is for searching a broad EU cultural heritage aggregator. While it does not explicitly say 'use X instead', the scope and examples implicitly signal when this tool is appropriate versus siblings. It lacks explicit exclusions or alternative tool mentions, but the context is strong enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the default filters for hasImages and isPublicDomain, the CC0 licensing of results, and the lack of an API key requirement. It also mentions the large object count and advises narrowing queries, which sets expectations about search performance. However, it does not describe the output format or pagination behavior.
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 four short sentences, each contributing important information: purpose, default filters, dataset scale, and API key requirement. It is front-loaded with the core action and contains no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no output schema, and no annotations, the description covers the core search behavior and key defaults, but it does not mention what the search returns (e.g., object IDs) or indicate that met_get_object is needed to fetch full details. This missing workflow context makes it less complete for an agent planning multi-step interactions.
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 low (only departmentId is described). The description adds meaning to hasImages and isPublicDomain by explaining the default filters and that results are freely usable, and it advises narrow queries for the query parameter. However, it does not clarify pageSize semantics or further detail query matching behavior, leaving gaps that the description could have filled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the Met Museum (US)', which is a specific verb and resource. It also mentions unique default filters for hasImages and isPublicDomain, distinguishing it from sibling museum search tools. This makes the tool's purpose immediately clear.
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 provides useful usage context: defaults filter to freely usable CC0 results, there are 470k+ objects, narrow queries are recommended, and no API key is needed. It does not explicitly exclude alternatives or say 'use this when searching the Met', but the description and name clearly imply that. It offers guidance on how to query effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the API key requirement and gives an example ID, but does not mention return format, error handling, or whether the operation is read-only. For a fetch tool this is adequate but not rich.
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 sentences, front-loaded with the verb and resource. The API key note is concise and relevant. No wasted words.
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 tool with one parameter, no output schema, and no annotations, the description covers the core purpose, required auth, and an ID example. It lacks explicit return-value details, but for a fetch operation the return is implied. Overall, it's sufficient but not exhaustive.
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 schema has no description for recordId (0% coverage), but the description provides an example value ('/2048128/618580') that clarifies the expected format. This adds meaning beyond the schema's bare type string, though it could further explain where to find the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Fetch') on a specific resource ('a Europeana record by ID'), with an example ID format. This distinguishes it from the sibling europeana_search tool, which is for searching rather than fetching by ID.
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 implies the tool is for retrieving a known record by ID, which contrasts with the search tool. It also notes the API key requirement, which is a prerequisite. However, it doesn't explicitly state 'use this when you have an ID' or mention alternatives, so it's clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states what the tool returns ('metadata and all image file URLs') and gives an example URL format, but does not disclose potential error behaviors, URL validity requirements, or any side effects. This is adequate but not rich.
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?
Two concise, front-loaded sentences. The verb 'Fetch' starts the description, and the example URL provides concrete guidance without unnecessary verbosity.
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, the description is largely complete: it states the purpose, input format, and return payload. However, it would be stronger if it noted behavior for invalid URLs or explicitly linked to the download_image sibling for handling returned image URLs.
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?
Schema description coverage is 0%, but the description effectively documents the single parameter by defining it as a 'full URL' and providing an explicit example. This gives the agent enough semantic understanding to construct a valid itemUrl value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Fetch') and resource ('a Library of Congress item'), and specifies the key input method (by full URL). The example URL further disambiguates the tool, distinguishing it from sibling search tools like loc_search.
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 implies usage when the agent has a full item URL, which provides clear context. However, it does not explicitly mention alternatives or exclusions, such as 'use loc_search when you only have a query'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. It discloses that the tool accepts arbitrary IIIF size strings and builds a direct URL. It does not detail error handling or return type, but for a simple pure URL builder, the main behavior is clearly stated.
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 sentence containing all essential information, with practical examples inline. No wasted words.
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?
Given the low complexity, no annotations, and no output schema, the description covers the primary function and size options. However, it omits explicit clarification of what 'iiifId' should be and does not state the output is a URL string, though implied. This gap prevents a perfect score.
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 has zero per-property descriptions (0% coverage), so the description must compensate. It thoroughly explains the 'size' parameter with examples, but leaves 'iiifId' undefined, relying on the parameter name and tool context. This partial coverage warrants a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the imperative verb 'Build' and the specific resource 'direct Wellcome IIIF image URL', making the function unambiguous. It also includes concrete size examples, and it is clearly distinct from sibling metadata/search tools.
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 implies the use case: construct a direct image URL for the Wellcome IIIF API. It does not explicitly mention alternatives like download_image or wellcome_get_work, but the context makes it clear this is for URL generation. No exclusions or when-not-to-use guidance is provided, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds valuable context: 'No API key' (access requirement), 'mostly CC-BY or Public Domain Mark' (licensing behavior), and mentions that 'images' mode returns 'direct IIIF image hits' (output format). However, it does not explicitly state read-only behavior, rate limits, pagination, or error handling, leaving some gaps for a search 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 two sentences with no redundancy. The first sentence front-loads the main purpose, the second efficiently delivers parameter guidance and contextual notes. Every clause earns its place, making it concise and well-structured.
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?
Given the absence of annotations and output schema, the description gives a reasonably complete picture: the target collection, content focus, access requirement (no API key), and the two result kinds. It does not specify response schema or pagination, but for a simple search tool with three parameters, this is adequate. It also distinguishes from siblings through the UK-specific collection context.
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?
Schema coverage is low (33%), but the description compensates by explaining the 'kind' parameter clearly: kind='works' for catalogue entries and kind='images' for IIIF image hits. This adds meaning beyond the bare enum. pageSize is not discussed, but its name and default make it self-explanatory; overall, the description provides meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search the Wellcome Collection catalogue (UK)' – a specific verb and resource that immediately identifies the tool's function and scope. It further distinguishes from sibling search tools by naming the unique collection and explicitly dividing searches into 'works' and 'images' modes, making 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains the meaning of the 'kind' parameter with concrete examples ('works' vs 'images') and notes that no API key is required, which sets expectations. It also hints at content relevance ('medical/scientific/esoteric/astrological history'). However, it does not explicitly compare with alternatives like europeana_search or wellcome_get_work, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![archival-imagery-mcp MCP server](https://glama.ai/mcp/servers/chandhoke/archival-imagery-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chandhoke/archival-imagery-mcp)

Score Badge

Copy to your README.md:

[![archival-imagery-mcp MCP server](https://glama.ai/mcp/servers/chandhoke/archival-imagery-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chandhoke/archival-imagery-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chandhoke/archival-imagery-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server