Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Museum MCP Server get highlights from the Metropolitan Museum of Art"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Server for global museum collections — give AI agents access to 570,000+ artworks from the world's greatest museums. No API key required.
Museum | Collection Size | API Key |
Metropolitan Museum of Art (NYC) | 470,000+ objects | None required |
Art Institute of Chicago | 100,000+ objects | None required |
Related MCP server: Smithsonian Open Access MCP Server
Tool | Description |
| Search artworks by keyword in Met or Chicago |
| Full metadata for a specific artwork |
| Find all works by a specific artist |
| List all Met Museum departments |
| Search within a specific Met department |
| Curated highlights from either museum |
| Discover a random artwork |
| Search by historical period (Renaissance, Baroque, etc.) |
| Compare results across both museums simultaneously |
pip install museum-mcp-serverAdd to your Claude Desktop config (claude_desktop_config.json):
{
"mcpServers": {
"museum": {
"command": "museum-mcp-server"
}
}
}"Search for Monet paintings in both museums"
"Show me highlights from the Metropolitan Museum of Art"
"Find Renaissance artworks in the Art Institute of Chicago"
"Give me details about artwork 436535 from the Met"
"Show me a random artwork from Chicago"
"Compare results for 'ancient Egypt' across both museums"Metropolitan Museum of Art: metmuseum.github.io — Open Access API, 470,000+ objects spanning 5,000 years
Art Institute of Chicago: api.artic.edu — Free API, 100,000+ works including paintings, sculptures, prints
Both APIs are completely free and require no authentication. This server works out of the box.
MIT — Free to use, modify, and distribute.
AiAgentKarl — Building the AI Agent Economy, one MCP server at a time.
Einen Suchbegriff in beiden Museen gleichzeitig suchen und Ergebnisse vergleichen.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Suchbegriff (Kuenstler, Thema, Stil, Periode) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys the basic search-and-compare action but fails to mention any side effects, authentication needs, rate limits, or the nature of the comparison (e.g., merged results vs. separate lists). The presence of an output schema may partially compensate, but the description itself adds little transparency.
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, efficient German sentence with no wasted words. It is front-loaded with the key action. However, the extreme brevity sacrifices some informative detail that could aid understanding without harming conciseness.
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?
Despite having an output schema, the description lacks completeness for a compare tool. It does not explain the comparison mechanism (e.g., side-by-side or merged results), and the mention of 'beiden Museen' is ambiguous without naming the museums. Given the complexity of comparing across collections, more context is needed.
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% description coverage for the single 'query' parameter, providing its meaning (artist, subject, style, period). The tool description does not add further semantics beyond restating 'Suchbegriff'. Per guidelines, with high schema coverage the baseline is 3, and no extra value is added.
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 German description clearly states the tool's function: searching a term in both museums simultaneously and comparing results. The verb 'suchen' and 'vergleichen' with the resource 'beiden Museen' uniquely identifies its purpose. However, it does not name which two museums, leaving ambiguity for an agent unfamiliar with the context.
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 sibling tools like tool_search_artworks or tool_search_by_artist. The description merely states the action without explaining scenarios where comparing both museums is preferred over single-museum searches, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vollstaendige Details zu einem Kunstwerk abrufen.
| Name | Required | Description | Default |
|---|---|---|---|
| museum | No | 'met' oder 'chicago' | met |
| artwork_id | Yes | ID des Kunstwerks |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It does not state whether the tool is read-only or destructive, nor any side effects. However, the tool name and schema suggest a safe read operation. The description adds minimal behavioral context beyond the name.
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 short sentence that states the core purpose clearly. It is concise and front-loaded, no wasted words.
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 is a simple single-artwork detail retrieval with an output schema (which presumably defines the return structure), the description covers the basics. However, it could mention that details include specific fields or that museum parameter affects which artwork details are retrieved. The output schema likely handles the rest.
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 baseline is 3. The description does not add any extra meaning to parameters beyond what the schema already says. It is a simple lookup by ID with an optional museum selection.
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 it retrieves complete details of an artwork, using the verb 'abrufen' (retrieve) and the object 'Vollstaendige Details zu einem Kunstwerk' (complete details of an artwork). It distinguishes from sibling tools like tool_search_artworks which likely return lists rather than full details.
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 on when to use this tool over siblings. Siblings include search tools and a comparison tool, but the description does not clarify that this tool is for a single artwork by ID. Context of required vs optional parameters is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alle Abteilungen des Metropolitan Museum of Art abrufen.
Returns: Liste aller Departmente mit ID und Name fuer gezielte Suchen
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states what the tool returns (ID and name) and implies a read operation via 'abrufen', but does not disclose idempotency, caching, authentication requirements, or other behavioral traits. Adequate for a simple retrieval, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The purpose is stated first, followed by return value. Efficient and front-loaded.
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 zero-parameter, simple list retrieval tool with an output schema, the description is complete. It explains the purpose and what the return contains (ID and name), which is sufficient for an agent to use it 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?
The input schema has no parameters, and schema description coverage is 100% (trivially). The description adds no parameter info, but none is needed. Baseline 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 tool retrieves all departments of the Metropolitan Museum of Art, using a specific verb ('abrufen') and resource ('Abteilungen'). It distinguishes from sibling tools that focus on artworks, artists, or highlights.
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 explicit guidance on when to use this tool vs alternatives. The hint 'fuer gezielte Suchen' implies utility for filtering, but it does not direct an agent to use this before search_by_department or mention that it provides IDs needed for other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kuratierte Highlights aus einem Museum abrufen.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Anzahl der Highlights (max 20) | |
| museum | No | 'met' (Metropolitan) oder 'chicago' (Art Institute of Chicago) | met |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'abrufen' implies a read-only operation, but the description does not explain how highlights are selected, whether pagination is involved, or any other behavioral details beyond the basic action.
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 with no filler or redundant information. It is front-loaded with the purpose and is appropriately sized for a simple retrieval 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?
Given the schema's full parameter documentation and the presence of an output schema, the description is minimally sufficient. However, it lacks any usage guidance or additional context about the curation logic, making it complete only at a basic level.
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% parameter description coverage, clearly documenting both 'limit' and 'museum' with defaults and allowed values. The description adds no additional semantic detail beyond what the schema already 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb, 'abrufen' (retrieve), and a distinct resource, 'Kuratierte Highlights aus einem Museum' (curated highlights from a museum). This distinguishes it from sibling tools that focus on departments, artwork searches, or artist searches.
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 gives no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. It simply states the action, leaving the agent to infer usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ein zufaelliges Kunstwerk aus einem Museum abrufen.
| Name | Required | Description | Default |
|---|---|---|---|
| museum | No | 'met' oder 'chicago' | met |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does, not how it behaves (e.g., read-only, no side effects, API endpoint). No additional behavioral traits are disclosed.
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, front-loaded, and contains no wasted words. However, it is extremely short and could benefit from a bit more context without being verbose.
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 (1 optional parameter, output schema exists) and the sibling context, the description is minimally adequate. It does not mention the available museums (though the schema does), and it lacks context about the random selection behavior.
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% (the parameter 'museum' has a description). The description adds no extra meaning beyond the schema, so baseline 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 tool's purpose: retrieving a random artwork from a museum. This is a specific verb+resource combination that distinguishes it from sibling tools like search, get details, or get departments.
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 its siblings (e.g., search_artworks, get_artwork_details). There is no mention of use cases, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kunstwerke in Museumssammlungen suchen.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximale Anzahl Ergebnisse (Standard: 10, max: 20) | |
| query | Yes | Suchbegriff (Kuenstler, Thema, Periode, Stil, etc.) | |
| museum | No | 'met' (Metropolitan, New York) oder 'chicago' (Art Institute of Chicago) | met |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description is minimal and does not mention non-obvious behaviors such as whether the tool supports fuzzy search, case sensitivity, or what happens with empty queries. This is a basic search tool, so the lack of detailed behavior is somewhat acceptable, but more context would help.
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 is concise and front-loaded. It could be slightly expanded to differentiate from siblings, but it is not verbose. Every word earns its place.
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 output schema exists (not shown but referenced in context), the description does not need to explain return values. However, given the tool has 3 parameters and 8 siblings, the description is sparse. It does not specify if the search is case-insensitive, supports partial matching, or if there are rate limits. For a general search tool, minimal but adequate.
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 covers 100% of parameters with descriptions. The schema already describes 'query' as a search term including artist, theme, period, style, etc., and 'museum' specifies the supported museums. The description does not add much beyond the schema, but the schema itself is thorough. The description adds no new meaning, but since schema coverage is 100%, 4 is merited.
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 'Kunstwerke in Museumssammlungen suchen' clearly states it searches artworks in museum collections. It distinguishes from siblings like tool_search_by_artist and tool_search_by_department by being a general-purpose search across all fields. The title is not provided, but the name 'tool_search_artworks' aligns well with the purpose.
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 implicitly states when to use the tool (general search across museums), but provides no guidance on when not to use it or how it differs from siblings like tool_search_by_artist. With eight sibling tools, explicit alternatives are missing, making it hard for the agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kunstwerke eines bestimmten Kuenstlers suchen.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximale Anzahl Ergebnisse | |
| museum | No | 'met' oder 'chicago' | met |
| artist_name | Yes | Name des Kuenstlers (z.B. 'Monet', 'Picasso', 'Rembrandt') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the search action, omitting that the operation is read-only, whether authentication is needed, or pagination behavior. The default limit and museum selection are not mentioned in the description, leaving the agent to infer from the 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 sentence of 6 words, which is very concise. However, it is too brief given the tool's complexity (3 parameters, output schema, sibling tools). It lacks front-loaded context about the museum and limit defaults. Conciseness should not sacrifice necessary information; here it borders on under-specification.
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?
Despite having an output schema, the description does not explain that the tool defaults to the Met museum and returns up to 8 results. It provides no context about the scope of the search or how it relates to sibling tools. The description is insufficient for an agent to fully understand the tool's capabilities and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters documented. The description adds no additional meaning beyond the schema; it does not clarify the default limit or museum options. Baseline 3 is appropriate as the schema already covers parameter meaning, but the description could have provided rationale or usage hints.
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 searches for artworks by a specific artist ('Kunstwerke eines bestimmten Kuenstlers suchen'). It distinguishes from siblings like 'search_artworks' (general) or 'search_by_department' by specifying the filtering criterion. The verb and resource are explicit, though the German language may reduce clarity for non-German-speaking agents.
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 gives no guidance on when to use this tool versus alternatives. With siblings like 'search_artworks' and 'search_by_period', an explicit statement of when to prefer this tool (e.g., 'Use when the user asks for works by a specific artist') is missing. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kunstwerke in einer bestimmten Met-Abteilung suchen.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximale Anzahl Ergebnisse | |
| query | No | Optionaler Suchbegriff innerhalb der Abteilung | |
| department_id | Yes | ID der Abteilung (aus tool_get_met_departments) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'search artworks in a specific Met department' without disclosing behavior like result limits, handling of empty query, or required prerequisite calls (e.g., using department_id from tool_get_met_departments). The schema hints at defaults but the description adds no 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 concise sentence with no unnecessary words. It is front-loaded and to the point, earning full marks for brevity.
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 presence of an output schema and comprehensive parameter descriptions in the schema, the description provides minimal additional context. It is adequate for a simple search tool but lacks details like pagination, sorting, or example usage that would aid completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions in German (e.g., 'Maximale Anzahl Ergebnisse'). The tool description adds no further parameter meaning, so it meets the baseline for high schema coverage but does not exceed it.
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 'Search artworks in a specific Met department' uses a clear verb and resource, and the name combined with sibling tools (e.g., tool_get_met_departments, tool_search_artworks) implies its focused scope. However, the description itself does not explicitly distinguish it from siblings like tool_search_by_artist or tool_search_by_period.
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 such as tool_search_artworks or tool_search_by_period. Sibling tool names are available but the description does not reference them or explain selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kunstwerke nach historischer Periode suchen.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximale Anzahl Ergebnisse | |
| museum | No | 'met' oder 'chicago' | met |
| period | Yes | Zeitperiode (z.B. 'Renaissance', 'Baroque', 'Impressionism', 'Ancient Egypt', 'Medieval') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. The description is minimal and does not reveal any side effects, limitations, or special behaviors. It does not contradict annotations, as none exist. A score of 3 reflects a neutral baseline: the description is not harmful but leaves significant behavioral aspects unaddressed.
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, which is concise. It front-loads the core purpose. However, the omission of usage guidelines and behavioral context means the description is concise but not optimally helpful. The sentence earns its place, but could be expanded slightly to include when to use it.
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 complexity (3 parameters, 1 required) and the presence of an output schema, the description is notably incomplete. It does not explain the interaction between period and museum, nor the expected return format (though the output schema covers that). The lack of sibling differentiation or usage context makes it inadequate for an AI agent to choose and invoke correctly without trial and error.
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 the baseline is 3. The description adds value by providing a use example for 'period' (e.g., 'Renaissance', 'Baroque'), which goes beyond the schema's minimal description. It also clarifies that 'museum' defaults to 'met' and accepts 'chicago'. This context helps the agent choose appropriate values, warranting a 4.
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 'Kunstwerke nach historischer Periode suchen' clearly states the verb (suchen = search) and the resource (Kunstwerke = artworks) with the dimension (historical period). It is distinct from sibling tools like tool_search_by_artist or tool_search_by_department, providing good differentiation.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention context such as supported periods, error handling for invalid input, or that it restricts to a single museum. Usage is implied by the period parameter, but no explicit exclusions or trade-offs are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tools are mostly distinct, but `tool_search_artworks` (generic search) and `tool_search_by_artist`, `tool_search_by_department`, and `tool_search_by_period` could be confused, especially if the generic search already supports filtering. However, the focused search tools have clear parameters, so overlap is manageable.
Tools follow a consistent `tool_` prefix followed by a verb_noun pattern (e.g., `tool_get_met_departments`, `tool_search_artworks`). There are minor inconsistencies like `tool_compare_museums` (verb_object without underscore) and `tool_get_artwork_details` vs `tool_get_museum_highlights` but overall the pattern is recognizable.
With 9 tools, the server is well-scoped for a museum-focused MCP server. Each tool addresses a specific need (departments, search, details, random, highlights, comparisons), and the count is within the ideal range of 3-15.
The tool set covers the main museum browsing workflows: get departments, search by various criteria, get details, highlights, random, and comparison. Missing features might include artwork filtering by medium or sorting, but the current set supports core discovery and exploration without critical gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Free public MCP for AI agents — 193 tools, 44 workflows. No API key.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AiAgentKarl/museum-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
