Emblematic

Search designs

search_designs

Read-onlyIdempotent

Use this when the user wants design references: "dark dev-tool sites", "sites using Söhne", "a warm serif editorial look", "something with #5E6AD2". Matches brand, font, style tags, hue/hex, stack and description across the Emblematic index and returns small cards (scheme, key colors, fonts, radius, one-line summary). All filters are optional and combine with AND. Not for fetching one known site (use get_design) or listing facet values (use browse_by).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_designs"
  }
}

Input Schema

Name	Required	Description
`font`	No	Font family substring, accent-insensitive ("inter", "sohne").
`color`	No	Hex ("#5E6AD2", ΔE match against role and palette colors) or hue name ("blue", "green", "neutral").
`limit`	No	Max results (default 8).
`query`	No	Free text, e.g. "dark mono minimal", "inter pill buttons", "next.js".
`style`	No	Style tag: monochrome, single-accent, serif-display, pill, sharp, rounded, flat, layered-shadows, blur-nav, gradients, dark-mode…
`scheme`	No	Page color scheme.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds genuinely new context: what the results look like (small cards with scheme, key colors, fonts, radius, one-line summary) and that all filters are optional and combine with AND. It does not discuss result volume beyond the schema's limit, but that is minor.

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

Conciseness4/5

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

Front-loaded with the trigger and the exclusions at the end, with no filler sentences. The example list is longer than strictly necessary, but for a fuzzy free-text search tool the examples do real work in teaching query phrasing, so the density is largely earned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description explains the returned card shape (scheme, key colors, fonts, radius, one-line summary), so the agent knows what comes back. Combined with full schema coverage and clean annotations, nothing needed to call this correctly is missing.

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?

Schema coverage is 100%, so a baseline of 3 would be defensible, but the description adds cross-cutting semantics the schema does not: filters combine with AND and matching spans brand, font, style tags, hue/hex, stack, and description. That tells the agent how the parameters interact rather than just what each one is.

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

Purpose5/5

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

States a specific verb+resource (search designs across the Emblematic index) and immediately grounds it in concrete example queries like "dark dev-tool sites" and "sites using Söhne". It also names the sibling tools it is not (get_design, browse_by), so an agent can separate it from retrieval-by-id and facet-browsing at a glance.

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

Usage Guidelines5/5

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

Opens with an explicit trigger condition ("Use this when the user wants design references") backed by four representative phrasings, then closes with two explicit exclusions routing to get_design and browse_by. When-to-use, when-not-to-use, and the alternatives are all present.

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

All Emblematic tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?