Skip to main content
Glama

Find Icons

find_icons

Search free SVG icons via Iconify without an API key, returning family:name identifiers and preview URLs; limit results to one family for a consistent UI.

Instructions

Search for free SVG icons through Iconify (no API key). Returns family:name identifiers and preview URLs. Choose one family (such as lucide) for a consistent UI.

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of results (1–50; default 20).
queryYesIcon search term, such as 'rocket', 'shopping cart', or 'cloud upload'.
prefixNoLimit icon families, such as 'lucide' or 'lucide,tabler'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It usefully discloses two facts an agent would otherwise have to discover: no API key is required, and results are identifiers plus preview URLs rather than inline SVG markup. It says nothing about result ordering, empty-result behavior, or rate limits, which is a meaningful gap for a search 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?

Three short sentences, zero filler. Capability, return contract, and the key usage tip are all front-loaded, and each sentence earns its place.

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?

With no output schema, the description correctly spends words on return values (family:name identifiers, preview URLs), which is exactly what an agent needs to chain into get_icon. The only shortfall is the missing pointer to that sibling tool and absent guidance on empty results.

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 all three parameters are already documented and the baseline is 3. The description adds meaning beyond that by explaining the intent behind 'prefix' — pin one family (e.g., lucide) for visual consistency rather than mixing families — which is strategy the schema does not convey.

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?

States a specific verb and resource (search for free SVG icons via Iconify) and names the backing source, which distinguishes it from siblings like get_icon or draw_icon. It also previews the return shape (family:name identifiers, preview URLs), though it never explicitly names the alternative retrieval tool.

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 closing sentence gives a real practice tip ('Choose one family... for a consistent UI'), implying this is the discovery step before fetching a single icon. However, it never states when to use this versus get_icon, find_images, or find_design_assets, so the routing decision is left to inference.

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