Loading ToolBench
Unofficial MCP server for cosmos.so. Search, browse and build visual moodboards with Claude, Cursor or any MCP client.
cosmos-mcp demonstrates solid fundamentals with consistent naming conventions and clear descriptions, but lacks formal schema documentation and has gaps in error handling guidance. All 12 tools follow verb_noun naming patterns (cosmos_search, cosmos_create_cluster, cosmos_delete_cluster), which is excellent. Descriptions are present and contextual (averaging ~120 chars), explaining both what tools do and when to use them. However, input parameter schemas are not visible in the provided source, only parameter names and basic types can be inferred from the tool definitions listed. No output schemas are documented. The server includes excellent pedagogical instructions in INSTRUCTIONS constant that guide agent behavior, but this does not compensate for missing formal schema documentation. Error handling is implicit (not visible in code samples); destructive operations like cosmos_delete_cluster require explicit confirmation parameter, which is good practice. Risk classifications (READ_ONLY, WRITE, DESTRUCTIVE) are present but not surfaced as tool annotations in the MCP protocol.
Get information about the authenticated user's cosmos.so account
Get visual recommendations for elements that belong with the current cluster based on its visual content
Create a new moodboard (cluster) on cosmos.so
Permanently delete a cluster (requires explicit confirmation)
Check how many boards have saved a specific element (rarity indicator)
Nest a cluster inside another cluster as a subcluster
Save elements (images, videos, products) to a cluster
Input and output schemas not documented in source code. Tools list parameter names and types, but formal JSON Schema declarations with type definitions, constraints (enums, ranges, patterns), and descriptions are not visible. This violates the requirement that every parameter have a description and schema.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not visible in the MCP protocol layer. Risk classifications (READ_ONLY, WRITE, DESTRUCTIVE) exist in metadata but are not surfaced via tool annotations in the server definition, preventing clients from understanding operation safety without reading descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Save an image URL from outside cosmos.so to a cluster
Search cosmos.so for elements (images, videos, products) matching a query term
Get elements visually similar to a specific element
Update a cluster's name, description, or visibility
View images of elements before saving them to verify they match the intended content
Output schemas not documented. Clients cannot know what fields to expect from tool responses, forcing LLMs to guess at the structure and making it impossible to plan downstream tool calls with certainty. E.g., cosmos_search returns results but the response structure is not documented.
Error handling and recovery guidance not visible. Tools have implicit error paths (e.g., invalid element ID, network failures), but recovery guidance for LLMs is not documented. Per the rubric, error responses should tell the agent what to do next.
cosmos_account_info tool has empty input schema (no parameters required). Description is minimal (27 chars: 'Get information about the authenticated user's cosmos.so account'). While accurate, it could be more explicit about auth requirements and what 'account info' includes.