Get popular/featured Infyicon icons without a search query — ideal when the user just wants "a nice icon" for something. Optionally restrict to one style. Returns ids, styles, page/SVG/PNG URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 12) | |
| style | No | Optional: restrict to one style |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read-only retrieval operation returning a list and specifies the output contents: ids, styles, and page/SVG/PNG URLs. It also discloses the optional style restriction behavior, which is useful context beyond the parameter schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The defining use case is front-loaded, the optional parameter is summarized, and the return shape is included. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional parameters and no output schema, the description covers the essential context: what the tool returns, when to use it, and the one significant optional behavior. It doesn't mention ordering, pagination, or rate limits, but for this low-complexity tool those are not critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both limit and style documented in the schema. The description adds only "Optionally restrict to one style," which restates the style parameter without deeper meaning. Since the schema already covers the parameters, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: "Get popular/featured Infyicon icons without a search query." It clearly distinguishes this tool from sibling search-oriented tools like search_icons by emphasizing the no-query use case. It also states what the user gets: ids, styles, and URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on when to use the tool: "without a search query" and "ideal when the user just wants 'a nice icon'." It implies the alternative is a search tool, though it does not explicitly name search_icons or state cases where popular_icons would not be appropriate, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clear, distinct roles: search, list categories, and fetch SVG/PNG by id. Some overlap exists because search_icons already returns SVG and PNG URLs, but get_icon_svg/get_icon_png are clearly meant for direct retrieval by known id.
The naming pattern is generally consistent using verb_noun style: get_icon_svg, get_icon_png, list_categories, search_icons. uicons_lookup deviates slightly by starting with a product name instead of a verb, but it is still understandable and similar in spirit.
Five tools is a well-scoped size for an icon service: search, browse categories, retrieve two format types, and check webfont usage. Each tool has a clear purpose and none feel redundant enough to remove.
The core icon workflow is covered: search, category discovery, SVG/PNG retrieval, and UI-font lookup. Minor gaps exist around category-specific icon listing or richer metadata, but agents can successfully search and fetch icons end-to-end.