PickAPIcon MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_icon_reposC | get all icon repo NAME |
| get_icons_by_desc_and_prefixC | get icons by desc and prefix (LIKE AS ant-design) |
| get_icon_detail_by_prefix_and_nameC | get icon detail by prefix and svg name |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: one retrieves details for a specific icon, one lists all icon repositories, and one searches icons by description and prefix. There is no overlap in functionality, making it easy for an agent to select the correct tool.
All tool names follow a consistent verb_noun pattern with 'get_' prefix and descriptive suffixes (e.g., get_icon_detail_by_prefix_and_name, get_icon_repos, get_icons_by_desc_and_prefix). The naming is uniform and predictable throughout.
With 3 tools, the count is appropriate for a focused icon retrieval service, though it feels slightly minimal. Each tool serves a distinct function, but the scope might benefit from additional utilities like listing icons by repository or updating metadata.
The tools cover basic retrieval (details, repos, search), but there are notable gaps for a full icon management system, such as creating, updating, or deleting icons or repositories. The surface is functional but incomplete for advanced workflows.