search_iconsFinds bundled Phosphor icon names by keyword query to help you pick icons for GlideDeck slides. Returns matching names with an optional result limit.
Searches the ~1,500 bundled Phosphor icon names (e.g. 'rocket', 'chart', 'users').
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false; the description usefully reinforces the closed-set nature with '~1,500 bundled' names, so the agent knows results are exhaustive within a fixed catalog. However, with no output schema, it never says what a hit looks like (name only? name plus category?) or how matching works (substring vs prefix).
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?
A single front-loaded sentence that states the capability, the corpus size, and examples of valid input with zero filler. Nothing could be removed without losing information.
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 read-only search with no output schema, the definition should at minimum cover the search field's match semantics and the limit/truncation behavior, and it covers only the first. An agent could call it successfully but might not know results are capped at 40.
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?
Schema coverage is 0%, so the description must carry parameter meaning, and it only partially does: the query semantics are conveyed through the 'rocket'/'chart'/'users' examples. The `limit` parameter (default 40) is never mentioned in either the schema or the description, leaving its purpose and paging behavior entirely undocumented.
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?
Names a specific verb (searches) and a precisely bounded resource (~1,500 bundled Phosphor icon names), with concrete query examples. Nothing in the sibling list overlaps — the rest are slide/presentation operations — so an agent can immediately tell this is the only icon-lookup tool.
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 intent (find icon names to use) is implied by the examples, but there is no explicit statement of when to call this versus other ways of resolving imagery, and no preconditions or exclusions. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.