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 discloses that the call requires no search query, supports optional style restriction, and returns ids, styles, page/SVG/PNG URLs. However, it does not mention pagination, result limits, or other operational behavior beyond what the schema already implies.
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?
Two sentences with no filler. The main purpose and use case are front-loaded, followed by the optional parameter and return value summary. Every phrase 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?
The tool is simple, has only two optional parameters, and no output schema. The description covers the core return fields and the no-query behavior. It could mention default/max limits explicitly, but the schema already covers those, so the description is sufficiently complete for correct invocation.
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%, so the schema already documents both parameters. The description adds only a minor clarification with 'Optionally restrict to one style', which is already reflected in the schema's enum and optional status. This aligns with the baseline 3.
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 clearly states a specific verb and resource: 'Get popular/featured Infyicon icons'. It also differentiates the tool from search-based alternatives with 'without a search query', though it does not name a specific sibling tool, so it stops short of the strongest sibling differentiation.
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?
It gives clear context for when to use the tool: 'ideal when the user just wants "a nice icon" for something'. It does not explicitly state when not to use it or name alternatives, but the usage scenario is concrete enough for an agent to route appropriately.
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.
get_icon_png and get_icon_svg are clearly format-specific retrievers, while search_icons handles discovery and uicons_lookup covers the webfont. Slight overlap exists because search_icons already returns SVG/PNG URLs, but the getters serve distinct purposes.
Most names follow a verb_noun snake_case pattern like get_icon_png and list_categories, but uicons_lookup reverses the noun-verb order and looks like a compound noun rather than an action. The case style is consistent, but the ordering convention is not.
Five tools is well-scoped for an icon library: search, SVG retrieval, PNG retrieval, category browsing, and webfont lookup each earn their place. There is no bloat or obvious redundancy in the overall count.
The core search-and-download workflow is covered, and uicons_lookup provides a meaningful extra lookup path. However, list_categories is a dead end because there is no way to fetch icons within a category or filter search_icons by category, creating a notable workflow gap.