cosmos-mcp
Click on "Deploy 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., "@cosmos-mcpsearch images of Tokyo skyline at dusk"
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.
cosmos-mcp
MCP server for searching cosmos.so. Returns direct CDN image URLs — no page scraping.
Used by TVLR to find destination photos for places.json.
Install
git clone https://github.com/vihaanshahh/cosmos-mcp.git
cd cosmos-mcp
npm installRelated MCP server: unsplash-mcp
Cursor / Claude Code
{
"mcpServers": {
"cosmos": {
"type": "stdio",
"command": "node",
"args": ["/path/to/cosmos-mcp/dist/index.js"]
}
}
}Tools
Tool | What it does |
| Search by keyword. Filter by color, content type, sort order. |
| Search curated boards. |
| Look up one element by ID or |
search_images
{
"query": "Tokyo skyline dusk",
"limit": 10,
"exclude_ai": true,
"order": "RELEVANT",
"color": "FF5500"
}Returns results[].media_id, thumbnail_url, image_url, caption.
get_element
{ "element_id": 1169598936 }Or pass a full share URL.
TVLR workflow
search_images({ query: "Porto azulejos tiles", exclude_ai: true })Pick a result → copy UUID from CDN URL → set as
cosmosIdinplaces.jsonURL pattern:
https://cdn.cosmos.so/<cosmosId>?format=webp&w=800
Dev
npm run build
npm run devNotes
No API key. Uses Cosmos's public GraphQL endpoint.
Not an official Cosmos API — same backend the website uses.
Typical search: ~300ms.
License
MIT
Available Tools
3 toolsget_elementA
Fetch a single cosmos.so element by ID or share URL. Returns the image URL, caption, source link, and owner.
| Name | Required | Description | Default |
|---|---|---|---|
| element_id | Yes | Element ID (e.g. 2019059012) or cosmos.so URL (e.g. https://www.cosmos.so/e/2019059012). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the fetch operation and return fields but lacks details on error handling, rate limits, or authentication. Adequate for a simple read tool.
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 concise sentences with clear purpose and output. No wasted words, 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?
Simple tool with one param and no output schema; description covers purpose, input, and output adequately. Lacks error handling but sufficient for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds value by listing return fields (image URL, caption, etc.) not in schema, enhancing parameter understanding.
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 fetches a single element by ID or URL, listing return fields. It distinguishes from sibling search tools which are for broader queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a specific element ID or URL, but does not explicitly state when not to use or mention 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.
search_collectionsA
Search cosmos.so curated collections (thematic boards of saved elements). Returns collection names, cover images, element counts, and follower counts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1-100). Defaults to 20. | |
| query | Yes | Search term for collection names and topics. | |
| page_cursor | No | Pagination cursor from a previous response's next_page_cursor field. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions return fields (names, cover images, counts, followers) but does not disclose pagination behavior, rate limits, or read-only nature. Adequate but not thorough.
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?
Single sentence conveying purpose and output without extraneous words. Perfectly concise 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?
Given three parameters and no output schema, the description is sufficiently complete for a search tool. Could mention pagination but schema already handles that. Overall 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?
Schema coverage is 100% and describes each param. Description adds value by explaining what collections are ('thematic boards of saved elements') and what is returned, enriching understanding of the query parameter.
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?
Clearly states the verb 'search' and resource 'collections'. Distinguishes from sibling tools 'get_element' (gets single element) and 'search_images' (searches images) by specifying it searches curated collections.
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 versus alternatives, but the description implies usage for finding collections. Implied from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_imagesA
Search cosmos.so for images and visual elements. Returns direct CDN image URLs, captions, and metadata without loading web pages. Fast structured results for mood boards, design research, and visual inspiration.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | Filter by dominant color as hex without #, e.g. 'FF0000' for red. | |
| limit | No | Results per page (1-40). Defaults to 20. | |
| order | No | Sort order. Defaults to RELEVANT. | |
| query | Yes | Search term, e.g. 'brutalist architecture', 'editorial typography', 'earth tones' | |
| exclude_ai | No | When true, filters out AI-generated images client-side. | |
| page_cursor | No | Pagination cursor from a previous response's next_page_cursor field. | |
| content_type | No | Filter by element type. Defaults to IMAGE. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses return types (CDN URLs, captions, metadata) and mentions 'fast structured results', but does not cover pagination behavior, required permissions, or error handling.
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 just two sentences with no wasted words. First sentence states purpose, second sentence adds value proposition. Well 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?
No output schema is provided, but the description covers key return elements (CDN URLs, captions, metadata). It lacks explicit mention of pagination or empty result handling, but overall it is reasonably complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any extra meaning beyond the schema; no parameter-specific elaboration is given.
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 verb 'Search' and the resource 'images and visual elements'. It specifies what is returned (CDN URLs, captions, metadata) and adds 'without loading web pages' to differentiate from web scraping. However, it does not explicitly distinguish from sibling tools like 'get_element' or 'search_collections'.
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 context for use cases ('mood boards, design research, and visual inspiration'), implying when to use. However, it does not explicitly state when not to use or mention any alternative tools among the siblings.
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.
3 tool updates
v1.0.0- First observed
get_element - First observed
search_collections - First observed
search_images
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: retrieving a specific element by ID/URL, searching collections, and searching images. There is no overlap in functionality.
All tool names follow a consistent verb_noun pattern with snake_case: get_element, search_collections, search_images. No naming style variations.
With 3 tools, the set is slightly minimal but covers core retrieval and search operations for the cosmos.so domain. It feels appropriately scoped for a read-only search API.
The tools are read-only (get and search), lacking create, update, or delete operations for elements or collections. This is a notable gap if full lifecycle management is expected, but it may be sufficient for a search-focused tool.
Maintenance
Related MCP Connectors
MCP server for searching Airweave collections with natural language queries.
MCP server for OnceAsk, the AI-native current-address layer for people and agents.
MCP server for Google search results via SERP API
Related MCP Servers
- AlicenseBqualityDmaintenanceMCP server for searching images with Google214 npm13MIT
- AlicenseAqualityDmaintenanceAn MCP server for searching and retrieving photos from Unsplash with proper attribution, designed for LLMs building content pages.326MIT
- FlicenseAqualityBmaintenanceMCP server for scraping images from DuckDuckGo and Google Maps place photos without API key.2-
- AlicenseAqualityCmaintenanceMCP server that enables searching and downloading Unsplash photos and collections.4MIT