list_collectionsBrowse available icon collections. Returns prefix, name, icon count, author, license, and category. Use the prefix with search_icons or get_icons.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| total | Yes | Total number of available collections | |
| collections | Yes | Array of collection metadata objects |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {}
+]Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "collections": {
+ "description": "Array of collection metadata objects",
+ "items": {
+ "properties": {
+ "author": {
+ "description": "Author name or null if not specified",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "category": {
+ "description": "Collection category or null if not specified",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "license": {
+ "description": "License title or null if not specified",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "Human-readable collection name",
+ "type": "string"
+ },
+ "prefix": {
+ "description": "Collection prefix identifier",
+ "type": "string"
+ },
+ "total_icons": {
+ "description": "Number of icons in the collection",
+ "type": "number"
+ }
+ },
+ "required": [
+ "prefix",
+ "name",
+ "total_icons",
+ "category",
+ "author",
+ "license"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "Total number of available collections",
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "collections"
+ ],
+ "type": "object"
+}Input schema / examplesRemoved value: -[
- {}
-]Output schema / (root)Previous value: -{
- "properties": {
- "collections": {
- "description": "Array of collection metadata objects",
- "items": {
- "properties": {
- "author": {
- "description": "Author name or null if not specified",
- "type": [
- "string",
- "null"
- ]
- },
- "category": {
- "description": "Collection category or null if not specified",
- "type": [
- "string",
- "null"
- ]
- },
- "license": {
- "description": "License title or null if not specified",
- "type": [
- "string",
- "null"
- ]
- },
- "name": {
- "description": "Human-readable collection name",
- "type": "string"
- },
- "prefix": {
- "description": "Collection prefix identifier",
- "type": "string"
- },
- "total_icons": {
- "description": "Number of icons in the collection",
- "type": "number"
- }
- },
- "required": [
- "prefix",
- "name",
- "total_icons",
- "category",
- "author",
- "license"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "total": {
- "description": "Total number of available collections",
- "type": "number"
- }
- },
- "required": [
- "total",
- "collections"
- ],
- "type": "object"
-}New value: +nullOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "collections": {
+ "description": "Array of collection metadata objects",
+ "items": {
+ "properties": {
+ "author": {
+ "description": "Author name or null if not specified",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "category": {
+ "description": "Collection category or null if not specified",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "license": {
+ "description": "License title or null if not specified",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "Human-readable collection name",
+ "type": "string"
+ },
+ "prefix": {
+ "description": "Collection prefix identifier",
+ "type": "string"
+ },
+ "total_icons": {
+ "description": "Number of icons in the collection",
+ "type": "number"
+ }
+ },
+ "required": [
+ "prefix",
+ "name",
+ "total_icons",
+ "category",
+ "author",
+ "license"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "Total number of available collections",
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "collections"
+ ],
+ "type": "object"
+}Input schema / examplesAdded value: +[
+ {}
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by detailing what data is returned and how the output connects to other tools. It does not contradict annotations and adds helpful context about the output structure.
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, front-loaded with the core action, and no filler. Every sentence adds value: the first defines the operation, the second lists outputs and usage guidance.
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 the trivial complexity (no params) and the presence of an output schema, the description is complete: it states what the tool returns, the key fields, and how to use them with sibling tools. Nothing more is needed.
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 tool takes zero parameters, so the baseline is 4. The description compensates by explaining the return fields and their purpose, which is sufficient for a parameterless tool.
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 clear action ('Browse available icon collections') with a specific resource and lists the returned fields (prefix, name, icon count, author, license, category). It distinguishes itself from sibling tools by explaining how the prefix will be used with search_icons and get_icons.
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?
Explicitly tells the agent when to use this tool (to browse collections before using search_icons/get_icons) and names the exact sibling tools that consume the prefix. This provides clear direction and prevents confusion with other list tools.
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.
Multiple tools have heavily overlapping purposes: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, and deep_research all route questions to the same data sources, and the Polymarket family (polymarket_edges, polymarket_edge_tracker, polymarket_arbitrage, polymarket_fill_risk, polymarket_kalshi_spread) has blurred boundaries. Agents would struggle to pick the right one without reading every description carefully.
Naming is mostly snake_case but follows no consistent verb_noun pattern. Verbs vary widely (ask_, get_, list_, search_, compare_, scan_, validate_, remember, recall, forget, subscribe, unsubscribe, discover, generate, resolve, suggest) and many tools are bare nouns (entity_profile, recent_alerts, polymarket_edges). The inconsistency makes the set feel ad hoc.
34 tools is on the heavy side, and the count is inflated by many near-duplicate data-router and prediction-market tools. The server is named 'iconify' yet only 3 of 34 tools actually relate to icons, indicating poor scoping for the stated purpose.
For the icon domain, the surface is minimal (list, search, get) with no create/update/delete. For the broader data/prediction-market domain, there are significant gaps in lifecycle coverage (e.g., subscriptions have create/cancel but no pause/resume, and the memory tools lack namespacing). The mixed focus means no single domain is fully covered.