Click on "Deploy 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., "@svg2vector-mcp convert the SVG icon.svg to Android vector drawable and save as icon.xml"
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 (Model Context Protocol) server for converting SVG files to Android Vector Drawable XML format.
✅ Converts SVG files to Android Vector Drawable XML
✅ Supports local files and remote URLs
✅ Handles common SVG shapes: path, rect, circle, polygon, line
✅ Converts shapes to path elements
✅ Preserves stroke and fill properties
✅ Handles CSS styles and presentation attributes
✅ Works seamlessly with SVGs exported from Figma MCP
Related MCP server: tr-figma-mcpserver
npm install -g svg2vector-mcpgit clone <your-repo>
cd svg2vector-mcp
npm install
npm linkAdd to your MCP client configuration (e.g., Claude Desktop):
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"svg2vector": {
"command": "svg2vector-mcp"
}
}
}Or if installed from source:
{
"mcpServers": {
"svg2vector": {
"command": "node",
"args": ["/path/to/svg2vector-mcp/src/index.js"]
}
}
}convert_svg_to_vectorConverts an SVG file to Android Vector Drawable XML format.
Parameters:
svgPath (string, required): Path to SVG file (local path or URL)
outputPath (string, required): Output path for the generated XML file
Example:
// Convert local SVG file
{
"svgPath": "/path/to/icon.svg",
"outputPath": "/path/to/output/icon.xml"
}
// Convert remote SVG file
{
"svgPath": "https://example.com/icon.svg",
"outputPath": "./output/icon.xml"
}
// Convert SVG exported from Figma MCP
{
"svgPath": "/path/to/figma-export.svg",
"outputPath": "./android/res/drawable/ic_figma_icon.xml"
}This MCP server works seamlessly with the official Figma MCP server. You can use Figma MCP to export SVG assets from Figma designs, and then use this server to convert them to Android Vector Drawables.
Workflow example:
Use Figma MCP to export SVG from your Figma design
Use svg2vector-mcp to convert the exported SVG to Android Vector Drawable XML
Use the generated XML in your Android project
This makes it easy to maintain design consistency between Figma and Android applications.
<path> - Path elements
<rect> - Rectangles (converted to paths)
<circle> - Circles (converted to paths)
<polygon> - Polygons (converted to paths)
<line> - Lines (converted to paths)
<g> - Groups
stroke - Stroke color
stroke-opacity - Stroke alpha
stroke-width - Stroke width
stroke-linecap - Stroke line cap
stroke-linejoin - Stroke line join
fill - Fill color
fill-opacity - Fill alpha
opacity - Overall opacity
Text elements
Gradients
Filters
Animations
Ellipses (use circle or convert manually)
Polylines (use polygon instead)
Embedded images
Clipping paths
The tool generates Android Vector Drawable XML files compatible with Android API 21+:
<vector xmlns:android="http://schemas.android.com/apk/res/android"
android:width="24dp"
android:height="24dp"
android:viewportWidth="24"
android:viewportHeight="24">
<path
android:pathData="M12,2 L2,22 L22,22 Z"
android:fillColor="#000000"/>
</vector>svg2vector-mcp/
├── src/
│ ├── index.js # MCP server entry point
│ ├── constants.js # Shared constants and mappings
│ ├── converter/
│ │ ├── index.js # Converter module exports
│ │ ├── SvgConverter.js # Main converter class
│ │ └── XmlWriter.js # XML output writer
│ ├── parser/
│ │ ├── index.js # Parser module exports
│ │ └── SvgParser.js # SVG parsing logic
│ ├── tree/
│ │ ├── index.js # Tree module exports
│ │ ├── SvgNode.js # SVG node classes
│ │ └── SvgTree.js # SVG tree container
│ └── utils/
│ ├── index.js # Utils module exports
│ ├── ColorUtils.js # Color conversion utilities
│ └── PathBuilder.js # Path construction builder
├── test/
│ ├── ColorUtils.test.js # Color utilities tests
│ ├── PathBuilder.test.js # Path builder tests
│ ├── SvgParser.test.js # Parser tests
│ ├── SvgConverter.test.js # Converter tests
│ └── integration.test.js # Integration tests
├── test-data/ # Test SVG/XML files
├── package.json
└── README.md# Install dependencies
npm install
# Run the server
npm start
# Or directly
node src/index.js# Run all tests
npm test
# Run tests in watch mode
npm run test:watchimport { SvgConverter } from 'svg2vector-mcp/converter';
const converter = new SvgConverter();
const result = converter.convert(svgContent);
if (result.success) {
console.log(result.xml);
} else {
console.error(result.errors);
}Ensure the file contains a valid <svg> root element
Add a viewBox attribute to your SVG element
Or ensure width and height attributes are present
The converter will log warnings for unsupported SVG features
The conversion will continue but may not include all visual elements
MIT
Based on the Android SVG to VectorDrawable converter from the Android Open Source Project.
Convert SVG file to Android Vector Drawable XML format. Accepts local file paths or remote URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| svgPath | Yes | Path to SVG file (local path or URL starting with http:// or https://) | |
| outputPath | Yes | Output path for the generated Vector Drawable XML file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only covers input types and output format, omitting details like error handling, file overwriting behavior, validation of SVG features, or success/error messages. This lack of depth for a conversion tool with no annotation safety net is insufficient.
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 extremely concise at two sentences, front-loading the purpose and then clarifying input types. Every word adds value, with no redundancy or extraneous 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?
Despite lacking an output schema, the description clearly identifies the output format ('Android Vector Drawable XML'). For a simple conversion tool with two required parameters, this covers essential usage context. Minor omission: could mention overwrite behavior or supported SVG version, but not critical.
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%, both parameters have clear descriptions. The description reiterates that svgPath can be a local path or URL, but adds no new semantics beyond what the schema already provides. Baseline 3 is appropriate as the description is adequate but not additive.
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 verb 'convert' and the specific resource: SVG files to Android Vector Drawable XML format. It explicitly mentions input types (local file paths or remote URLs), which distinguishes it from hypothetical tools that might handle other vector formats.
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 description specifies that the tool accepts both local file paths and remote URLs, providing clear input guidance. However, it does not explicitly state when to prefer this tool over potential alternatives (like generic SVG converters), though no siblings exist to require such differentiation.
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.1.0convert_svg_to_vectorScored across 1 tool
With only one tool, there is no possibility of ambiguity or confusion between tools.
Single tool follows a clear verb_noun pattern in snake_case, so consistency is inherent.
A single tool feels too sparse for an MCP server; most servers offer multiple operations to justify their existence.
The server covers its stated purpose of converting SVG to Android vector drawable, but lacks auxiliary features like validation or batch processing.
The Figma MCP server brings Figma design context directly into your AI workflow.
MCP server for Appcircle mobile CI/CD platform.
An MCP server that provides asset auto generator
MCP server for Google Veo AI video generation
