Skip to main content
Glama

i_search

Search iconfont.cn by keyword to find icons or multi-color illustrations, then download SVG files via i_download_svg.

Instructions

Search icons OR illustrations (插画) on iconfont.cn by keyword. Set type="illustration" for multi-color artwork (returns original SVG downloadable via i_download_svg, no color override). Icons must be downloaded via i_download_svg with a recent search.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (default: 1)
typeNoContent type: "icon" (default, single-color icons) or "illustration" (multi-color 插画 artwork)icon
keywordYesSearch keyword, e.g. "home", "arrow", "雪人"
pageSizeNoResults per page (default: 20, max: 100)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.6/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 full disclosure burden. It usefully reveals non-obvious downstream behavior: illustration results are original SVGs that cannot be recolored, and icon downloads require a recent search. It omits whether a search requires login/auth, what a result record contains, and any rate limits, which are significant gaps for a no-annotation tool.

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?

Three dense sentences, front-loaded with the core action and the type semantics before the download caveats. The second sentence's nested parenthetical is slightly tangled but nothing is redundant.

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 4-parameter, no-output-schema search tool, the description covers type semantics and the handoff to i_download_svg, which is the key workflow an agent needs. It would be stronger if it sketched what the results contain so the agent knows what IDs/URLs it can pass downstream.

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 coverage is 100%, so keyword, page, pageSize and the type enum are already documented in the schema; baseline 3 applies. The description adds only marginal meaning, mainly the color-override caveat for illustration results, which is more a downstream behavior than a parameter semantic.

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 (Search) and resource (icons OR illustrations on iconfont.cn) and clarifies the two content types. It does not differentiate itself from plausible siblings such as i_search_all or l_search, so an agent cannot rule those out from the description alone.

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 explicit when-to guidance for the type parameter ("Set type='illustration' for multi-color artwork") and states the required follow-up workflow ("Icons must be downloaded via i_download_svg with a recent search"). It stops short of naming any alternative or exclusion, e.g. versus i_search_all or l_search.

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