Skip to main content
Glama
Sign In
pyside-iconify-mcp

pyside-iconify-mcp

by LingChen-tsjmdlc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Search Icons

search_icons
Read-onlyIdempotent

Find real Iconify icons by keyword and return valid prefix:name strings plus their icon sets, so you can use confirmed names instead of guessing.

Instructions

Find real icons by keyword (use this instead of guessing an icon name). Returns 'prefix:name' strings that exist in Iconify, plus the icon sets they belong to. A query with several words must match all of them; narrow with 'prefix' (e.g. 'mdi', 'lucide'). status 'unavailable' means the lookup failed (for example no network), not that nothing exists.

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": {
      "query": "<query>"
    },
    "name": "search_icons"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of icons to return (1-100).
queryYesKeywords, e.g. 'arrow left'. At most 100 characters.
prefixNoOnly search this icon set, e.g. 'mdi'. Omit to search all sets.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses two behaviors that materially change how an agent should react: multi-word queries are AND-matched (so adding words narrows rather than broadens), and a status of 'unavailable' means the lookup itself failed rather than that no icon exists. That second point is exactly the kind of failure-semantics disclosure that prevents an agent from wrongly concluding an icon is missing.

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?

Four sentences, each carrying distinct information: purpose and anti-guessing directive first, then return shape, then matching semantics, then error-state meaning. No filler and the most decision-relevant content is front-loaded.

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 an output schema and full parameter descriptions already supplied, the description covers the remaining gaps an agent needs: matching logic, narrowing, and failure interpretation. Only minor gaps remain, such as the result-count limit behavior, which the schema already handles.

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% and each parameter already self-documents, so the baseline is 3. The description adds real meaning beyond the schema for 'query' by stating that several words must all match, a semantic the schema does not convey; the prefix guidance largely restates the schema field.

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 gives a specific verb and resource ('Find real icons by keyword') and states the output shape ('prefix:name' strings plus icon sets), so the agent knows exactly what comes back. It does not name or differentiate itself from the siblings (check_icons, get_reference), so it falls short of the 5 bar.

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

Usage Guidelines4/5

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

It gives an explicit directive: 'use this instead of guessing an icon name', which is precisely the situation in which an agent would otherwise hallucinate a name. It also explains how to narrow a broad search with the prefix parameter, but names no sibling alternative or when-not case (e.g. when to use check_icons to validate an existing name).

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