Provides access to Cisco's official network diagram icon set, allowing agents to search, list, and retrieve icons as RGB PNG images with metadata for building topology diagrams.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cisco-network-diagrams-mcp-server Find the router icon and get its image and metadata."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server exposing the 308 official icons from the Cisco Systems Corporate Iconography package — the free-to-use icon set Cisco itself distributes for diagrams and materials — so an LLM can look up the right icon and fetch it as an image while building a network topology diagram.
All icons are shipped pre-converted from Cisco's original CMYK JPEGs to RGB PNG. The CMYK originals render blank, discolored, or cropped in most web/collaborative tools (Miro, Figma, FigJam, browsers) — this fixes that at the source, and the PNGs are ~4x smaller too.
Tool | Description |
| List the 7 catalog categories with icon counts. |
| Keyword search across id/name/description (metadata only). |
| Paginated listing, optionally filtered by category or curated-only. |
| Fetch one icon's metadata and its RGB PNG image by id. |
29 of the 308 icons are curated: the equipment most common in
classroom/enterprise topologies (router, switch, firewall, server, access
point, cloud, etc.), annotated with glossary_name, function, and
when_to_use in addition to the base description every icon has.
Related MCP server: Cisco RADKit MCP Server
npm install -g cisco-network-diagrams-mcp-serverOr run without installing:
npx cisco-network-diagrams-mcp-serverAdd to your client's MCP server config (e.g. Claude Desktop's
claude_desktop_config.json):
{
"mcpServers": {
"cisco-network-diagrams": {
"command": "npx",
"args": ["-y", "cisco-network-diagrams-mcp-server"]
}
}
}The icons are not square — e.g. router is ~77×52 px. When placing the
image returned by cisco_get_icon onto a fixed-size node (Figma, FigJam,
Miro, etc.), use a FIT scale mode, never FILL — FILL stretches or
crops non-square icons.
The icons are Cisco's registered trademark artwork. Cisco authorizes free use in diagrams and materials, unaltered (no redrawing, recoloring the artwork, or distorting proportions). The CMYK→RGB conversion in this package is a technical compatibility fix (same color, different color space), not a visual alteration.
This package's own code is MIT-licensed; the icon artwork itself remains Cisco's property under Cisco's usage terms.
Fetch one Cisco network icon by id: its full metadata plus the actual image (PNG, RGB — pre-converted from Cisco's original CMYK JPEGs, which render blank or with wrong colors in most web/collaborative tools like Miro or Figma/FigJam).
Use this after cisco_search_icons or cisco_list_icons has told you the exact id you need. The image is returned as an embedded PNG you can place directly into a Miro board, Figma/FigJam file, or document.
Args:
id (string, required): exact icon id (case-sensitive), e.g. "router", "cisco_asa_5500"
Returns:
An image content block (PNG, RGB) — pass its dimensions to a 'FIT' scale mode when placing on a canvas; the icons are NOT square (e.g. "router" is ~77x52), so a 'FILL' scale mode will crop or distort it.
A text block with the icon's metadata (name, category, curated flag, description, and — for curated icons — glossary_name/function/when_to_use).
Error Handling:
Returns "Error: icon '' not found" if the id doesn't exist. Call cisco_search_icons first to find the correct id — don't retry with guessed variations.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The icon id, e.g. 'router', 'cisco_asa_5500', 'multilayer_switch'. Get this from cisco_search_icons or cisco_list_icons — do not guess ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the image is pre-converted from CMYK to RGB (addressing rendering issues in Miro/Figma), the icons are not square (affecting scale mode), and the error message format. This goes beyond annotations without contradicting them.
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?
The description is well-structured with clear sections (Args, Returns, Error Handling) and is front-loaded with the core purpose. It's slightly verbose in the Returns section but every sentence adds value (e.g., the FIT vs FILL scale mode warning is important). No wasted words, but could be tightened slightly.
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 single-parameter tool with 100% schema coverage and strong annotations, the description is complete. It covers the return format (image + metadata), the image characteristics (PNG, RGB, non-square), error handling, and usage flow. No output schema exists, so the description appropriately explains the return structure. Nothing critical is missing.
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 100% and the schema already describes the id parameter with examples and guidance to get it from search/list. The description reinforces this with the same examples and adds the case-sensitivity note, which is a small but useful addition. Since the schema does the heavy lifting, a 4 is appropriate for the slight extra value.
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 clearly states the tool fetches a Cisco network icon by id, returning both metadata and the image as PNG/RGB. It distinguishes itself from siblings by specifying it's the retrieval step after search/list, and explains the image conversion from CMYK to RGB, which is unique to this 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?
Explicitly instructs to use after cisco_search_icons or cisco_list_icons to get the exact id, and warns not to guess ids. It also provides error handling guidance (call search first, don't retry with variations), which is clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every category in the Cisco Systems Corporate Iconography catalog, with a human-readable label and how many icons fall into each.
Use this first to understand how the 308-icon catalog is organized before calling cisco_list_icons or cisco_search_icons with a category filter.
Args: none.
Returns JSON: { "categories": [ { "id": "routing_l3", "label": "Roteamento (Camada 3)", "icon_count": 12 } ] }
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint, idempotentHint, and destructiveHint=false, so the description doesn't need to repeat those. It adds value by describing the return JSON structure and the total catalog size (308 icons), which gives the agent useful context beyond annotations. No contradiction exists.
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?
The description is concise and well-structured: a clear opening sentence, a usage note, and an example return JSON. It front-loads the purpose and uses compact formatting without unnecessary fluff. Every sentence earns its place.
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 zero-parameter, read-only catalog listing tool, the description is complete. It explains the output structure (JSON with categories, labels, icon counts), the catalog's scope (308 icons), and its role relative to sibling tools. The inline JSON example compensates for the lack of an output schema.
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?
This tool has zero parameters, and the description explicitly states 'Args: none.' The schema is empty with 100% coverage, so there is nothing more to document. The baseline for zero-parameter tools is 4, and the description meets that adequately.
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 clearly states it lists every category from the Cisco corporate iconography catalog, including a human-readable label and icon count. It explicitly names the resource ('categories') and the verb ('list'), and it distinguishes itself from sibling tools by indicating it should be used first before calling filtered icon tools.
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?
Usage guidance is explicit: use this tool first to understand the catalog organization before calling cisco_list_icons or cisco_search_icons with a category filter. It provides a clear prerequisite context but does not explicitly state when not to use it, which would be a stronger when-not clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List icons from the 308-icon Cisco Systems Corporate Iconography catalog, optionally filtered by category, with pagination.
Defaults to curated_only=true, returning the 29 icons most relevant for teaching/enterprise network diagrams (router, switch, firewall, server, access point, cloud, etc.). Set curated_only=false to browse the full catalog (legacy/specific Cisco products, generic devices, people/buildings/phones icons).
Does NOT return image bytes — call cisco_get_icon with an id from the results to fetch the actual image.
Args:
curated_only (boolean, default true): restrict to the 29 curated icons
category (string, optional): filter by category id (see cisco_list_categories)
limit (number, default 50, max 100): page size
offset (number, default 0): pagination offset
Returns JSON: { "total": number, "count": number, "offset": number, "results": [ { "id": string, "name": string, "category": string, "curated": boolean, "description": string } ], "has_more": boolean, "next_offset": number | null }
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 50). | |
| offset | No | Number of results to skip, for pagination through the full catalog. | |
| category | No | Optional category id to filter by (see cisco_list_categories for valid ids). | |
| curated_only | No | If true (default), list only the 29 curated icons — common classroom/enterprise equipment with full pedagogical context. Set false to list the entire 308-icon catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which the description aligns with. Description adds critical behavioral context beyond annotations: explicitly states the tool does NOT return image bytes, explains pagination mechanics with has_more/next_offset, and documents the default curated_only=true behavior. No contradiction with annotations.
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?
Well-structured with purpose in the first sentence, followed by behavioral notes, args, and return format. The Args section partially duplicates the schema's parameter definitions, but each line adds small value: curated_only gets real-world examples, category gets a cross-reference, and pagination params give defaults inline. The return JSON example is valuable since there's no output schema. Slightly long but every section earns its place.
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?
Comprehensive for a moderate-complexity list tool. With 100% schema coverage, strong annotations, and no output schema, the description fills the gaps: it provides the return shape, pagination behavior, sibling connections, and the critical 'does not return image bytes' note. The only minor gap (missing error handling/rate-limit info) is acceptable for a read-only list operation, and the description covers all decision-relevant context the agent would need.
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 description coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining what the 29 curated icons represent (teaching/enterprise equipment with pedagogical context), clarifying the category parameter is a cross-reference to cisco_list_categories, and reinforcing default values. This adds meaningful context, particularly for curated_only where the schema's phrasing is expanded with concrete examples.
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?
Clearly states 'List icons from the 308-icon Cisco Systems Corporate Iconography catalog' with specific verbs (list), resource (icons from catalog), and scope (optional category filter, pagination). Distinguishes from siblings by mentioning the curated_only behavior and pointing to cisco_get_icon for image retrieval, which differentiates it from related operations.
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?
Provides explicit guidance on when to use curated_only=true (teaching/enterprise network diagrams, 29 icons) vs false (full catalog). Cross-references cisco_get_icon for fetching actual images and cisco_list_categories for valid category ids, giving the agent clear routing between alternatives without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the 308 official Cisco Systems Corporate Iconography icons by keyword. Matches against the icon's id, name, and description text.
This tool does NOT return image bytes — it returns lightweight metadata so you can identify the right icon id, then call cisco_get_icon with that id to fetch the actual image. Use this whenever the user asks "what icon represents X" or before assembling a diagram.
Args:
query (string, required): search term, e.g. "firewall", "roteador", "switch"
curated_only (boolean, default false): restrict to the 29 curated, pedagogically-annotated icons
category (string, optional): restrict to one category id (see cisco_list_categories)
limit (number, default 20, max 50): maximum results
Returns JSON: { "query": string, "total_matches": number, "count": number, "results": [ { "id": string, "name": string, "category": string, "curated": boolean, "description": string } ], "truncated": boolean }
Examples:
Use when: "que ícone eu uso pra representar um firewall?" -> query="firewall"
Use when: "preciso do ícone genérico de roteador wireless" -> query="wireless router"
Don't use when: you already know the exact id (use cisco_get_icon directly)
Error Handling:
Returns an empty "results" array (not an error) when nothing matches — suggest the user try an English equivalent or a generic fallback icon (e.g. "generic_gateway", "generic_processor").
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 20). | |
| query | Yes | Search term to match against icon id, name, and description. Cisco's original names are in English (e.g. 'router', 'firewall', 'switch') — if a Portuguese/Spanish term returns nothing, retry with the likely English equivalent. | |
| category | No | Optional category id to restrict the search to (see cisco_list_categories for valid ids, e.g. 'routing_l3', 'security'). | |
| curated_only | No | If true, only search the 29 curated icons (common classroom/enterprise equipment with full pedagogical context: function, when_to_use). Default false searches the full 308-icon catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description discloses non-obvious behavior: it never returns image bytes, returns an empty results array rather than an error on no match, includes a truncated flag, and distinguishes full catalog vs curated 29-icon scope. This is richer than the annotations alone and does not contradict them.
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?
The description is organized into clear sections (purpose, args, returns, examples, error handling) and every sentence contributes value. The core behavior is front-loaded and the JSON return contract is useful given there is no output schema.
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 search tool with no output schema, this description is fully self-sufficient: it explains the return JSON shape, the empty-match behavior, fallback suggestions, parameter interactions, and the relationship to sibling tools cisco_get_icon and cisco_list_categories. No critical operational detail appears to be missing.
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 100%, so the baseline of 3 applies. The description's Args section mostly restates schema-provided details (search term examples, default limit, category guidance, curated_only meaning). It adds convenient multilingual examples like 'roteador' and 'pedagogically-annotated' phrasing, but the schema already carries most semantic load.
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 opens with a specific verb ('Search'), a concrete resource ('the 308 official Cisco Systems Corporate Iconography icons'), and a clear matching behavior over id, name, and description. It also distinguishes itself from cisco_get_icon by positioning itself as the metadata-search step before actual image retrieval.
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?
Usage guidance is explicit: use it when the user asks what icon represents X or before assembling a diagram; don't use it when the exact id is already known since cisco_get_icon should be called directly. It also directs users to cisco_list_categories for valid category ids and clarifies the tool returns metadata rather than image bytes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0cisco_get_iconcisco_list_categoriescisco_list_iconscisco_search_iconsScored across 4 tools
Each tool has a clearly distinct purpose: listing categories, searching by keyword, listing with filters/pagination, and fetching a specific icon with its image. The search and list tools could overlap, but descriptions differentiate them (search by query vs. browse by category/pagination).
All tools follow the 'cisco_' + verb + noun pattern (cisco_list_categories, cisco_search_icons, cisco_list_icons, cisco_get_icon). The verbs are descriptive and consistent, and naming is uniformly snake_case.
Four tools is a well-scoped set for a read-only icon catalog server. Each tool earns its place: discovery via categories, search, filtered list, and retrieval with image bytes.
The surface covers the full workflow from catalog overview to specific icon retrieval. There are no obvious gaps—agents can discover, search, list, and fetch any icon. The domain is read-only, so no update/delete operations are expected.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Icons for agentic development: search & fetch 366,000+ open-source icons as SVG/PNG. No API key.
Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Search SVG metadata and buy licensed commercial SVG exports for coding agents.
