Get the full SVG markup of an Infyicon icon by id (format: slug_number, e.g. hammer-16_66091 — get ids from search_icons). Returns ready-to-embed SVG code.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Icon id like hammer-16_66091 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states the output is ready-to-embed SVG markup, which goes beyond simply naming the operation. It does not cover error behavior, but for a simple single-parameter retrieval tool this is reasonably transparent.
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 tight sentences, front-loaded with the main action, an example, a source for valid IDs, and the return format. No wasted words.
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?
Given one required parameter, no output schema, and no annotations, the description provides everything needed to call the tool: the ID format, where IDs come from, and what the returned value looks like.
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 documents the id parameter with an example, so the baseline is 3. The description adds value on top by specifying the slug_number format and explicitly pointing to search_icons as the source of valid IDs.
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: 'Get the full SVG markup of an Infyicon icon by id.' It also explains the ID format and how to obtain IDs, making the tool's purpose unmistakable and easily distinguished from the sibling get_icon_png.
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 clearly tells the agent that IDs come from search_icons, which is a useful precondition. It does not explicitly say when to choose this SVG tool over get_icon_png, but the resource name and return type make the intended use clear.
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.