Cisco Systems Corporate Iconography 패키지의 공식 아이콘 308개를 노출하는 MCP 서버입니다. 이는 Cisco가 다이어그램 및 자료용으로 직접 배포하는 무료 아이콘 세트로, LLM이 네트워크 토폴로지 다이어그램을 작성하는 동안 올바른 아이콘을 조회하고 이미지로 가져올 수 있게 해줍니다.
모든 아이콘은 Cisco 원본 CMYK JPEG에서 RGB PNG로 미리 변환되어 제공됩니다. CMYK 원본은 대부분의 웹/협업 도구(Miro, Figma, FigJam, 브라우저)에서 비어 있거나, 변색되거나, 잘려서 렌더링됩니다. 이 패키지는 이를 소스에서 해결하며, PNG 크기도 약 4배 더 작습니다.
도구 | 설명 |
| 아이콘 수와 함께 카탈로그의 7개 카테고리를 나열합니다. |
| id/이름/설명을 대상으로 한 키워드 검색(메타데이터 전용). |
| 페이지네이션 목록으로, 카테고리 또는 큐레이션 전용으로 필터링할 수 있습니다. |
| ID로 아이콘 하나의 메타데이터 및 RGB PNG 이미지를 가져옵니다. |
308개 아이콘 중 29개는 큐레이션되었습니다. 교실/엔터프라이즈 토폴로지에서 가장 흔한 장비(라우터, 스위치, 방화벽, 서버, 액세스 포인트, 클라우드 등)로, 모든 아이콘이 가진 기본 description 외에도 glossary_name, function, when_to_use로 주석이 달려 있습니다.
Related MCP server: Cisco RADKit MCP Server
npm install -g cisco-network-diagrams-mcp-server또는 설치 없이 실행:
npx cisco-network-diagrams-mcp-server클라이언트의 MCP 서버 구성(예: Claude Desktop의 claude_desktop_config.json)에 추가하세요:
{
"mcpServers": {
"cisco-network-diagrams": {
"command": "npx",
"args": ["-y", "cisco-network-diagrams-mcp-server"]
}
}
}아이콘은 정사각형이 아닙니다 — 예를 들어 router는 약 77×52px입니다. cisco_get_icon이 반환한 이미지를 고정 크기 노드(Figma, FigJam, Miro 등)에 배치할 때는 FIT 배율 모드를 사용하고, FILL은 사용하지 마세요. FILL은 정사각형이 아닌 아이콘을 늘리거나 자릅니다.
아이콘은 Cisco의 등록 상표 아트워크입니다. Cisco는 수정하지 않는 한(재작성, 색상 변경, 비율 왜곡 금지) 다이어그램 및 자료에서 무료 사용을 허가합니다. 이 패키지의 CMYK→RGB 변환은 기술적 호환성 수정(동일한 색상, 다른 색 공간)이며 시각적 변경이 아닙니다.
이 패키지의 자체 코드는 MIT 라이선스입니다. 아이콘 아트워크 자체는 Cisco의 사용 약관에 따라 Cisco의 자산으로 유지됩니다.
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.
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.
Search and fetch SVG icons from 250,000+ icons across 200+ open-source icon sets.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
