Skip to main content
Glama
neno-is-ooo

@mcp/openverse

by neno-is-ooo
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

@mcp/openverse

An MCP (Model Context Protocol) server that provides tools for searching and fetching openly-licensed images from Openverse.

Features

  • 🔍 Search for CC-licensed and public domain images

  • 🎨 Filter by license type, source, file format, and more

  • 📊 Get detailed image information including attribution

  • 🔗 Find related images

  • 📝 Essay-specific image search for content illustration

  • ⚡ Built with TypeScript and fastmcp for excellent performance

Related MCP server: archival-imagery-mcp

Installation

npm install -g @mcp/openverse

Or install from source:

git clone https://github.com/yourusername/mcp-openverse.git
cd mcp-openverse
npm install
npm run build
npm link

Usage

As an MCP Server

Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "openverse": {
      "command": "npx",
      "args": ["@mcp/openverse"]
    }
  }
}

Or if installed locally:

{
  "mcpServers": {
    "openverse": {
      "command": "node",
      "args": ["/path/to/mcp-openverse/dist/index.js"]
    }
  }
}

Available Tools

search_images

Search for openly-licensed images with various filters.

Parameters:

  • query (required): Search terms

  • page: Page number (default: 1)

  • page_size: Results per page (default: 20, max: 500)

  • license: License type (by, by-sa, by-nc, by-nd, cc0, etc.)

  • license_type: commercial or modification

  • creator: Filter by creator name

  • source: Filter by source (flickr, wikimedia, met, etc.)

  • extension: File type (jpg, png, gif, svg)

  • aspect_ratio: tall, wide, or square

  • size: small, medium, or large

  • mature: Include mature content (default: false)

Example:

// Search for nature photos with commercial license
{
  "query": "forest landscape",
  "page_size": 10,
  "license_type": "commercial",
  "extension": "jpg",
  "aspect_ratio": "wide"
}

get_image_details

Get detailed information about a specific image.

Parameters:

  • image_id (required): Openverse image ID (UUID format)

get_related_images

Find images related to a specific image.

Parameters:

  • image_id (required): The image ID to find related images for

  • page: Page number (default: 1)

  • page_size: Results per page (default: 10)

get_image_stats

Get statistics about available images by source.

No parameters required.

search_images_for_essay

High-level tool for finding images to illustrate essays or articles.

Parameters:

  • essay_topic (required): Main topic/title of the essay

  • concepts (required): Array of key concepts to find images for

  • style: photo, illustration, or any (default: any)

  • max_images: Maximum images to return (default: 10)

Example:

{
  "essay_topic": "Climate Change",
  "concepts": ["global warming", "renewable energy", "carbon emissions"],
  "style": "photo",
  "max_images": 15
}

Image Attribution

All images from Openverse come with attribution requirements. The API provides:

  • attribution: Pre-formatted attribution text

  • license: License code (e.g., 'by-sa')

  • license_url: Link to the license

  • creator: Original creator/photographer

  • creator_url: Link to creator's profile

Always include proper attribution when using images.

Rate Limits

The Openverse API has the following rate limits:

  • Anonymous: 100 requests/day, 5 requests/hour

  • Authenticated: 10,000 requests/day, 100 requests/minute

This MCP server currently uses anonymous access. For higher rate limits, consider implementing OAuth authentication.

Development

Building from Source

npm install
npm run build

Running in Development Mode

npm run dev

Testing the Server

You can test the server using the MCP inspector:

npx @modelcontextprotocol/inspector dist/index.js

Examples

Finding Images for a Blog Post

// Using the search_images_for_essay tool
{
  "essay_topic": "Sustainable Architecture",
  "concepts": ["green building", "solar panels", "eco-friendly design"],
  "style": "photo",
  "max_images": 10
}

Searching with Specific Requirements

// Using the search_images tool
{
  "query": "mountain landscape sunrise",
  "aspect_ratio": "wide",
  "license_type": "commercial",
  "extension": "jpg",
  "size": "large",
  "page_size": 20
}

License

MIT License - see LICENSE file for details.

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Development Guidelines

  1. Follow TypeScript best practices

  2. Add tests for new features

  3. Update documentation

  4. Ensure all tools have proper error handling

Acknowledgments

  • Openverse for providing the API and openly-licensed content

  • WordPress for maintaining the Openverse project

  • fastmcp for the excellent MCP framework

Troubleshooting

Common Issues

  1. Rate limit errors: You're hitting the anonymous API limits. Wait an hour or implement authentication.

  2. No results: Try broader search terms or remove filters.

  3. Connection errors: Check your internet connection and firewall settings.

Debug Mode

Set the DEBUG environment variable:

DEBUG=mcp:* npx @mcp/openverse

Available Tools

5 tools
get_image_detailsC

Get detailed information about a specific image

ParametersJSON Schema
NameRequiredDescriptionDefault
image_idYesOpenverse image ID (UUID format)

TDQS

C2.9/5.0
Behavior2/5

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 states this is a read operation ('Get'), but doesn't mention permissions, rate limits, error handling, or what 'detailed information' includes. This is inadequate for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.

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?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails, potential response formats, or error cases. For a tool with no structured output documentation, this leaves significant gaps for an AI agent.

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 description coverage is 100%, so the schema already documents the 'image_id' parameter as an Openverse image ID in UUID format. The description adds no additional meaning beyond what the schema provides, such as examples or context for obtaining the ID, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('detailed information about a specific image'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_image_stats' or 'get_related_images' which might also provide image information, so it lacks sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'get_image_stats' for statistics or 'search_images' for broader queries, nor does it specify prerequisites like needing an image ID.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_image_statsB

Get statistics about image providers and counts

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/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 of behavioral disclosure. It mentions 'Get statistics,' implying a read-only operation, but doesn't specify details like whether it requires authentication, has rate limits, returns aggregated data, or handles errors. This leaves significant gaps in understanding the tool's 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 a single, clear sentence that directly states the tool's function without any wasted words. It's front-loaded and efficiently communicates the essential information, making it easy to parse and understand quickly.

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?

Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns statistical data. It doesn't explain what specific statistics are provided (e.g., counts by provider, trends), the format of the output, or any prerequisites, leaving the agent with insufficient context to use it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so there's no need for parameter details in the description. The description appropriately focuses on the tool's purpose without redundant parameter information, earning a high score for not adding unnecessary complexity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('statistics about image providers and counts'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_image_details' or 'search_images', which might provide overlapping or related functionality, so it misses the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools such as 'get_image_details' and 'search_images' available, there's no indication of whether this tool is for high-level summaries, specific queries, or other contexts, leaving usage ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_imagesC

Search for openly-licensed images on Openverse

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch terms (required)
pageNoPage number (default: 1)
page_sizeNoResults per page (default: 20, max: 500)
licenseNoLicense filter (e.g., by, by-sa, cc0)
license_typeNoLicense type (commercial or modification)
creatorNoFilter by creator name
sourceNoFilter by source (e.g., flickr, wikimedia)
extensionNoFile type (jpg, png, gif, svg)
aspect_ratioNoImage shape (tall, wide, square)
sizeNoImage size (small, medium, large)
matureNoInclude mature content (default: false)

TDQS

C2.9/5.0
Behavior2/5

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. While 'Search' implies a read-only operation, the description doesn't mention important behavioral aspects like rate limits, authentication requirements, pagination behavior beyond the parameters, error conditions, or what the response format looks like. This leaves significant gaps for an agent to understand how to interact with this tool effectively.

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, efficient sentence that immediately communicates the core functionality without any wasted words. It's appropriately sized for a search tool and gets straight to the point with no unnecessary elaboration.

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 11 parameters and no output schema, the description is insufficient. It doesn't explain what the search results look like, how pagination works beyond the parameters, what licensing 'openly-licensed' specifically means, or how mature content filtering behaves. With no annotations and no output schema, the agent lacks crucial information about the tool's behavior and results.

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 description coverage is 100%, with all 11 parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions, so it meets the baseline expectation but doesn't provide extra value. The description doesn't explain relationships between parameters or provide usage examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search for') and resource ('openly-licensed images on Openverse'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from its sibling 'search_images_for_essay', which appears to serve a similar search function with potentially different parameters or use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'search_images_for_essay' or other sibling tools. There's no mention of prerequisites, typical use cases, or limitations that would help an agent choose between available options.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_images_for_essayC

Search for images suitable for illustrating an essay

ParametersJSON Schema
NameRequiredDescriptionDefault
essay_topicYesMain topic/title of the essay
conceptsYesList of key concepts to find images for
styleNoPreferred image style (default: any)
max_imagesNoMaximum images to return (default: 10)

TDQS

C2.9/5.0
Behavior2/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 of behavioral disclosure. It mentions 'suitable for illustrating an essay,' hinting at relevance filtering, but does not detail how suitability is determined, what the output format is, or any limitations like rate limits or authentication needs. For a search tool with zero annotation coverage, this is insufficient to guide the agent fully.

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, efficient sentence: 'Search for images suitable for illustrating an essay.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every part of the sentence contributes directly to understanding the tool's intent.

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?

Given the tool's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral traits, output format, and usage guidelines. While the schema covers parameters well, the description does not address gaps in understanding how the tool behaves or what results to expect, making it inadequate for full contextual understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any additional meaning beyond what the schema provides, such as explaining how 'essay_topic' and 'concepts' interact or what 'suitable' entails. With high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search for images suitable for illustrating an essay.' It specifies the verb 'search' and the resource 'images,' with the context of 'illustrating an essay' providing additional clarity. However, it does not explicitly differentiate from sibling tools like 'search_images,' which might be more general, leaving room for ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It mentions the context of 'illustrating an essay,' but does not specify prerequisites, exclusions, or when to choose this over sibling tools such as 'search_images' or 'get_related_images.' This lack of explicit usage instructions reduces its effectiveness for an AI agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updates
    • First observedget_image_details
    • First observedget_image_stats
    • First observedget_related_images
    • First observedsearch_images
    • First observedsearch_images_for_essay
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation4/5

Most tools have distinct purposes: get_image_details, get_image_stats, get_related_images, and search_images are clearly differentiated. However, search_images and search_images_for_essay have overlapping functionality, as the latter seems like a specialized version of the former, which could cause minor confusion for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_image_details, search_images). There are no deviations in naming conventions, making the set predictable and easy to parse.

Tool Count5/5

With 5 tools, the count is well-scoped for an image search and retrieval server. Each tool serves a specific function in the domain, and there are no extraneous or redundant tools, making the set appropriately sized.

Completeness4/5

The tool surface covers core operations for image search and retrieval, including search, details, stats, and related images. A minor gap exists in lacking explicit tools for actions like filtering or advanced search parameters, but agents can likely work around this using the provided search tools.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Wikimedia-Search-Images

    xiaobenyang-com
    A
    license
    B
    quality
    D
    maintenance
    This MCP server enables AI assistants to search for images on Wikimedia Commons, providing detailed metadata and optional thumbnail combinations to assist AI models in visual comparisons.
    1
    2
    Apache 2.0

  • archival-imagery-mcp

    chandhoke
    A
    license
    A
    quality
    D
    maintenance
    An MCP server for browsing and downloading open-licensed imagery from major museum and archive APIs including Wellcome, Met, Library of Congress, Smithsonian, and Europeana.
    12
    23
    MIT

  • unsplash-mcp

    cevatkerim
    A
    license
    A
    quality
    D
    maintenance
    An MCP server for searching and retrieving photos from Unsplash with proper attribution, designed for LLMs building content pages.
    3
    24
    MIT

  • MCP Image Resolver

    ahmaddioxide
    A
    license
    A
    quality
    F
    maintenance
    An MCP server that enables AI assistants to search for royalty-free images from Pexels and Unsplash using natural language, returning structured results with metadata.
    5
    59
    MIT

Appeared in Searches

Latest Blog Posts

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/neno-is-ooo/mcp-openverse'

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