Skip to main content
Glama

list_icon_groups

Lists icon library groups with their sets and icon counts, helping you identify which icons to search for without modifying the board.

Instructions

Lists the groups of the icon library (AWS, Azure, Brands...) with their sets and the number of icons of each, to know what to search for. Does not modify the board (a board path is still needed when the application is not open).

Input Schema

NameRequiredDescriptionDefault
pathNoPath of the board file (.inkboard; .inkboard.json and .tableau.json also accepted). Optional when the application is open: the tool then acts live on the displayed board (undoable with Ctrl+Z).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the behavioral burden; it does declare 'Does not modify the board' (an explicit read-only claim) and explains the path requirement when the application is closed. However, it says nothing about result size, pagination, or whether the group listing is static/cached, which matter for an agent planning a call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the core purpose first and the caveat in parentheses; nothing is wasted. The parenthetical duplicates schema content slightly, which keeps it from being maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-parameter read tool with no output schema and no annotations, the description covers what is returned (groups, sets, icon counts) and the safety profile (does not modify the board). Only secondary details like response size or ordering are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one optional parameter and schema coverage is 100%, so the schema already explains the .inkboard path format and the live-board behavior. The description's parenthetical about needing a path when the app is closed largely restates the schema rather than adding new semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Lists the groups of the icon library') plus the concrete shape of the result (groups with their sets and icon counts). It implicitly separates itself from search_icons via 'to know what to search for', though it never names that sibling outright.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'to know what to search for' gives a clear use context: call this as a discovery step before searching for icons. There is no explicit exclusion or named alternative tool, so it stops short of a full when/when-not statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.