Skip to main content
Glama
Sign In
design-inspiration

design-inspiration

by SankofaForge
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Search design styles

design_search_styles
Read-onlyIdempotent

Search for design style inspiration by running image and web searches in parallel. Returns combined color palettes, typography, layouts, and animation references.

Instructions

Search for a specific aesthetic direction — color palettes, typography, layouts, or animation references. Runs image and web search in parallel and returns combined results.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "style": "<style>"
    },
    "name": "design_search_styles"
  }
}

Input Schema

NameRequiredDescriptionDefault
numNoNumber of results (1-20, default: 10)
typeNoType of style inspiration to search forgeneral
styleYesDesign style to search for. Examples: "minimalist dark theme", "brutalist web design", "glassmorphism"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (read-only, idempotent, open-world), the description discloses that it runs image and web searches in parallel and merges results — genuinely useful operational knowledge an agent wouldn't get from the schema alone. This tells the agent to expect combined, multi-source output from a single call. The annotations already cover the safety profile, so the description earns credit for adding the execution model on top.

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 tight sentences: the first front-loads the purpose with concrete examples, the second covers the single non-obvious behavioral trait (parallel execution). Not a single wasted word.

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 read-only search tool with three well-documented parameters, the description covers purpose, scope, and combined-result behavior. The main gaps are an unspecified return format (no output schema exists) and no disambiguation from the similarly named sibling tools — minor for a low-risk, read-only 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 100%, so all parameters (style, type, num) are already documented. The description's style examples map naturally onto the type enum values ('color-palette', 'typography', 'layout', 'animation'), which provides a slight bridge between intent and schema. But it adds no format, syntax, or behavior details that the schema doesn't already state, landing at a solid baseline.

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: searching for a specific aesthetic direction with concrete examples like color palettes, typography, layouts, and animation references. The parallel image/web search detail adds specificity beyond a generic search. However, it doesn't explicitly distinguish itself from the closely related siblings design_search_images or design_search_references, which an agent would need to infer on its own.

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 opening 'Search for a specific aesthetic direction' conveys when to use the tool, and the style examples give useful intent context. But there's no explicit when-not-to-use guidance or any mention of alternatives, which is a real gap given sibling tools like design_search_images and design_search_references are topically adjacent. Usage is implied rather than stated.

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

Deploy Server

Other Tools