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

pyside-iconify-mcp

by LingChen-tsjmdlc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Check Icons

check_icons
Read-onlyIdempotent

Verify Iconify icon names before using them in code and get status, color/animation properties, and real alternatives for missing icons.

Instructions

Verify icon names before using them in code. For each name returns whether it exists (status 'ok', 'not_found', 'invalid_name' or 'unavailable'), and for existing icons whether they are monotone or multi-color (fixed_colors), whether they animate themselves, and notes about what that means for color and animation arguments. For missing icons returns similar real icons. 'unavailable' means the check failed (for example no network), not that the icon is missing.

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": {
      "names": "<names>"
    },
    "name": "check_icons"
  }
}

Input Schema

NameRequiredDescriptionDefault
namesYesIcon names like 'mdi:home' (1-50 names per call).

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?

Goes well beyond the readOnly/idempotent/openWorld annotations by enumerating the four status values and what each means. The clarification that 'unavailable' signals a failed check (e.g., no network) rather than a missing icon is exactly the kind of behavioral nuance an agent could otherwise misread as a negative result. It also discloses the extra per-icon metadata (monotone vs fixed_colors, self-animation, and notes on what that implies for color/animation arguments).

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 first, then success payload shape, then the fallback behavior for misses, then the failure-mode disambiguation. No redundant restatement of the tool name or title.

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?

Although an output schema exists and technically covers return values, the description supplies the semantic interpretation of status codes and flag fields that a schema alone cannot. Combined with the mutation-free, batch-verification nature of the tool, an agent has everything it needs to call it and interpret results correctly.

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?

With a single parameter and 100% schema description coverage, the schema already documents the names array, the 'mdi:home' format, and the 1-50 per call limit. The description adds no further constraints on name format or batch behavior, so the baseline of 3 applies.

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: verify icon names before using them in code. This is distinguishable from the sibling search_icons because the framing is validation rather than discovery, although the description never names a sibling explicitly. It also notes that missing icons return similar real icons, which blurs the line with search slightly.

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?

Gives clear context: use it before referencing an icon name in code, and it handles batches via the names array. There is no explicit when-not guidance or comparison to search_icons or check_code, so the agent must infer that this tool is for validation and not for discovery.

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