Look up CSS class names in the Infyicon UI webfont (61,000+ glyphs). Use the returned class like with stylesheet https://infyicon.com/uicons/uicons.css
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Glyph name to search, e.g. "home", "arrow" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It conveys what the tool returns (a CSS class usable in an <i> element) and gives a concrete example. It does not cover search semantics like exact-match vs fuzzy, but for a simple lookup this is not a major gap.
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, clearly front-loaded with the action and resource. Every element—glyph scope, usage example, and stylesheet link—contributes directly to correct invocation and no text is wasted.
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 single-parameter, no-output-schema, no-annotation tool, this description is complete enough to guide an agent. It explains what to search, how to use the result, and how to render the icon. The missing details are non-essential given the minimal complexity of this tool.
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?
The schema already describes 'name' with concrete examples ('home', 'arrow'), achieving 100% schema description coverage. The tool description reinforces the input concept but adds little meaning beyond the schema's existing parameter documentation.
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?
States a specific action ('Look up CSS class names') and a specific resource (the Infyicon UI webfont), which clearly distinguishes it from sibling tools like get_icon_png or get_icon_svg. The inclusion of a concrete usage example reinforces the purpose.
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 shows how to apply the returned class ('Use the returned class like <i class=...>...') and references the stylesheet URL, giving clear context for when this tool is appropriate. It does not explicitly name sibling alternatives or exclusion criteria, but the resource type makes the usage context unambiguous.
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.