Given an icon id (from search_icons), return related/similar Infyicon icons — same theme in the same and other styles. Great for offering variations or building a matching icon set.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Icon id like hammer-16_66091 | |
| limit | No | Max results (default 12) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It discloses the matching logic ('same theme in the same and other styles'), which is useful, but it does not mention error handling, whether the original icon is included in results, pagination, or ordering. For a read-only lookup this is adequate but not thorough.
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 core operation is front-loaded, followed by a concise use-case clause. 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 two-parameter tool with full schema coverage and no output schema, the description supplies the essential context: input source (search_icons), behavior (related/similar icons), and a typical use case. It does not describe the return structure, but that is not required when no output schema exists and the operation is straightforward.
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%: id has an example ('hammer-16_66091') and limit has default and range (1-30, default 12). The description only restates that the id comes from search_icons, adding no additional parameter-level meaning beyond the schema.
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 states a specific verb and resource: 'return related/similar Infyicon icons' given an icon id. It clearly anchors the input to 'search_icons,' distinguishing this tool from search itself, and clarifies output scope with 'same theme in the same and other styles.'
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 provides clear context: this tool is a follow-up to search_icons, since it expects an id from search_icons. The use case ('offering variations or building a matching icon set') gives the agent a concrete scenario, though it does not explicitly state when not to use it or name alternative tools beyond the search_icons reference.
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.