What can you do with this server?

This MCP server connects AI agents to a FreeVectorIcons design collection, enabling search, retrieval, and version‑aware management of design assets. * Read collection context: Retrieve metadata, strategy brief, and asset summary. * List & search assets: Get all asset metadata, or search by name, type, category, style, or tag. * Asset details & content: Fetch metadata for a specific asset; get inline text content (SVG, Markdown) or short‑lived download URLs for binary files (PNG, PDF, etc.). * Create & upload assets: Generate signed upload targets, park new assets (inline text or base64), and create new versions while preserving history. * Metadata attachment: Optionally attach tags, document types, and DRL project identifiers during uploads. * Read‑only mode: When configured with FVI_READ_ONLY=true, all write tools are disabled.

How do I use fvi-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fvi-mcp search for 'checkmark' icons" 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.

fvi-mcp

Official

by FreeVectorIcons

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@freevectoricons/mcp

Beta. This package is under active development. Tool schemas, configuration options, and error behavior may change before v1.0.0. Report issues or review the product docs before production use.

Model Context Protocol (MCP) server for FreeVectorIcons design collections.

Connects Cursor, Claude Desktop, and other MCP clients to a single FreeVectorIcons collection: catalog icons, uploaded SVGs, strategy briefs, DESIGN.md, and related project files. Access is scoped to one collection token.

npm: @freevectoricons/mcp

Overview

Agents that generate icons inline often produce inconsistent SVG, unstable identifiers, and incorrect licensing across sessions. FreeVectorIcons stores approved assets in versioned collections with stable IDs and metadata.

This server exposes that collection to MCP clients. Agents search and retrieve canonical assets instead of regenerating SVG from scratch, and write designs back into the collection for review. Uploaded assets are versioned, so agents can iterate freely without losing prior work. The server runs over stdio and calls the FreeVectorIcons HTTP API. Responses are metadata-first JSON; file bytes are fetched only when a tool requests inline content or a download URL.

Related MCP server: RemixIcon MCP

Requirements

Node.js 20 or later
A FreeVectorIcons account
A collection-scoped MCP token

Setup

Open a collection at freevectoricons.com.
Go to Integrations → Setup MCP.
Create a token and copy the collection ID and secret.

Add the server to your MCP client configuration (for example .cursor/mcp.json):

{
  "mcpServers": {
    "freevectoricons": {
      "command": "npx",
      "args": ["-y", "@freevectoricons/mcp"],
      "env": {
        "FVI_API_URL": "https://freevectoricons.com/api",
        "FVI_COLLECTION_ID": "<collection-id>",
        "FVI_TOKEN": "<collection-token>"
      }
    }
  }
}

Run the server with npx as shown above. MCP uses stdio for protocol messages; the process must not write non-protocol output to stdout.

See mcp.json.example for a copy-paste template.

macOS (Claude Desktop)

Edit ~/Library/Application Support/Claude/claude_desktop_config.json and add the same mcpServers block.

Windows (Claude Desktop)

Edit %APPDATA%\Claude\claude_desktop_config.json and add the same mcpServers block.

Linux (Claude Desktop)

Edit ~/.config/Claude/claude_desktop_config.json and add the same mcpServers block.

Environment variables

Variable	Required	Default	Description
`FVI_TOKEN`	yes	—	Collection-scoped MCP token
`FVI_COLLECTION_ID`	yes	—	Collection ID
`FVI_API_URL`	no	`https://freevectoricons.com/api`	API base URL (include `/api`)
`FVI_READ_ONLY`	no	`false`	When `true`, write tools are not registered
`FVI_TIMEOUT_MS`	no	`30000`	HTTP request timeout for API calls (milliseconds)
`FVI_UPLOAD_TIMEOUT_MS`	no	`120000`	Timeout for binary upload requests (milliseconds)
`FVI_RETRY_MAX`	no	`3`	Maximum retry attempts for transient failures
`FVI_RETRY_BASE_MS`	no	`500`	Base delay for exponential backoff (milliseconds)
`FVI_LOG_LEVEL`	no	`info`	Log level: `debug`, `info`, `warn`, or `error` (stderr, JSON)

FVI_API_URL can be omitted if you use the production API. The setup example above sets it explicitly for clarity.

Write tools are enabled by default. Agents can park new assets and upload new versions of existing ones; each change is stored as a version you can review or restore in the collection UI. Set FVI_READ_ONLY=true only if you want retrieval without uploads.

Token security

Treat FVI_TOKEN like a password. It grants access to one collection.

Prefer OS keychain integration or a secrets manager in team environments.
If you use environment variables in config files, restrict file permissions and never commit tokens to version control.
Rotate tokens from the collection Integrations tab if a token may have been exposed.
Set FVI_READ_ONLY=true if an agent should only read from the collection, not upload.

Tools

Read (always available)

Tool	Description
`get_design_collection_context`	Collection metadata, strategy brief, asset summary
`list_design_collection_assets`	All assets (metadata only)
`search_design_collection_assets`	Search by name, tag, category, or style
`get_design_asset`	One asset by ID
`get_design_asset_content`	Inline UTF-8 for catalog SVGs, uploaded SVGs, Markdown
`get_design_asset_download_url`	Short-lived URL for PNG, PDF, and other binaries

Write (enabled by default)

Tool	Description
`create_design_asset_upload`	Create asset record and signed upload target
`park_design_asset`	Upload inline text or base64 into the collection
`create_design_asset_version`	Upload a new version of an existing asset (prior versions retained)

Uploaded assets keep version history in FreeVectorIcons. Agents should prefer create_design_asset_version when refining an existing design, and park_design_asset for new files. Agents should use metadata and download URLs for images and PDFs.

Optional write metadata: drlProjectId, drlAssetType, documentType, tags.

Limitations

Collection-scoped. One token grants access to one collection, not the global icon catalog.
Catalog quality. Catalog SVGs are AI-generated and refined on a schedule; verify assets before production use.
No design review. The server moves files and metadata; it does not evaluate brand fit.

Development

For local API development against a running FVI API server:

FVI_API_URL=http://localhost:5001/api \
FVI_COLLECTION_ID=<collection-id> \
FVI_TOKEN=<collection-token> \
node dist/mcp-server.mjs

npm install
npm run build
npm run smoke
node dist/mcp-server.mjs

To run from a local checkout:

"args": ["-y", "file:/absolute/path/to/fvi-mcp"]

Build first (npm run build). The bundled entry is dist/mcp-server.mjs.

Packaging

Runtime libraries (@modelcontextprotocol/sdk, zod) are build-time only. esbuild inlines them into dist/mcp-server.mjs, and published dependencies stays empty so npx does not install a second unused tree. Add new libraries as devDependencies, rebuild, and run npm run smoke before publish.

Maintainers still scan build inputs:

npm run audit:consumer    # install graph consumers see (must stay clean at moderate+)
npm run audit:maintainer  # includes devDependencies (high+)

After bumping a build dependency, rebuild and republish so dist/ picks up the fix. See Keeping @freevectoricons/mcp vulnerability-free.

Publishing (CD only)

Releases are published from GitHub Actions on this repository — not from laptops.

Who can publish: only @hemantasapkota (hard-coded actor check). The npm-publish GitHub Environment further limits deploys to main and v* tags. When the repo is public, collaborators with write still cannot publish unless that actor gate is updated.

Triggers

Manual (preferred): Actions → Publish → Run workflow on main, set confirm_version to the exact package.json version (e.g. 0.2.0-beta.1).
Tag: push v<package.json version> (e.g. git tag v0.2.0-beta.1 && git push origin v0.2.0-beta.1) as @hemantasapkota.

One-time setup (maintainer)

On npmjs.com for @freevectoricons/mcp → Trusted Publisher / Access:
- GitHub org/user: FreeVectorIcons
- Repository: fvi-mcp
- Workflow filename: publish.yml
- Environment: npm-publish
Confirm the GitHub Environment npm-publish exists (branch/tag policy: main, v*).
No long-lived npm automation token is required in GitHub secrets when trusted publishing is configured.

The workflow runs typecheck, build, smoke, audits, refuses to republish an existing version, then npm publish --access public --provenance --tag latest (an explicit tag is required for prerelease versions such as 0.2.0-beta.1).

@freevectoricons/mcp package architecture — Solution Design Architecture (stdio transport, tool mapping, security boundary)
Keeping @freevectoricons/mcp vulnerability-free — empty published dependencies, audit gates, Dependabot
freevectoricons.com/mcp — product documentation
ai-icon-generator — open pipeline for catalog icons

License

MIT — applies to this MCP server software only. See LICENSE.

Icon usage is governed separately by the FreeVectorIcons Community License. Attribution may be required depending on your plan and how icons are used.

Available Tools

9 tools

create_design_asset_uploadCreate Design Asset UploadB

Create a signed upload target and collection asset record for parking a DRL/FVI design asset.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	File name for the asset.
`tags`	No	Optional searchable tags.
`metadata`	No	Additional JSON metadata to store on the asset.
`sizeBytes`	Yes	Exact byte size that will be uploaded.
`contentType`	Yes	MIME type for the uploaded asset.
`documentType`	No	Optional document type for Markdown/PDF supporting documents.
`drlAssetType`	No	Optional DRL asset role, e.g. logo, brief, source_art, mockup.
`drlProjectId`	No	Optional DRL project identifier to store in metadata.
`checksumSha256`	No	Optional SHA-256 checksum for provenance.

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions creating a signed upload target and record, but doesn't disclose important behaviors: that the upload URL is temporary, that the asset is not finalized until an upload step, or any permission/rate limit implications. For a write operation, this is incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundancy. However, it is too brief for the complexity; essential details are missing, so it's not as helpful as it could be. Still, it's concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters, no output schema, and no annotations, the description is too sparse. It doesn't explain the two-step upload process, what the response contains (signed URL?), or how to complete the upload. The tool is complex but the description doesn't reflect that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are well-described in schema. Description adds no extra meaning beyond what's in the property descriptions. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action: create a signed upload target and collection asset record for parking a DRL/FVI design asset. This distinguishes it from siblings like park_design_asset and create_design_asset_version, which do different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. With 8 sibling tools, the description should indicate context (e.g., 'use this to initiate an upload; after uploading, use park_design_asset to finalize'). It lacks any usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_design_asset_versionCreate Design Asset VersionB

Upload inline text or base64 content as a new version of an existing uploaded design asset.

ParametersJSON Schema

Name	Required	Description
`name`	No	Optional file name for the new current asset version.
`tags`	No	Optional searchable tags.
`assetId`	Yes	Existing uploaded asset id.
`metadata`	No	Additional JSON metadata to store on the version.
`contentType`	Yes	MIME type for the uploaded version.
`textContent`	No	UTF-8 text content for SVG, Markdown, or other text assets.
`documentType`	No	Optional document type for Markdown/PDF supporting documents.
`drlAssetType`	No	Optional DRL asset role, e.g. revision, source_art, approved_art.
`drlProjectId`	No	Optional DRL project identifier to store in metadata.
`contentBase64`	No	Base64-encoded binary content for image/PDF assets.
`checksumSha256`	No	Optional SHA-256 checksum for provenance.

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full behavioral burden. It only states mutation ('upload as new version') without disclosing permissions, side effects on previous versions, rate limits, or relationships between optional parameters (e.g., textContent vs contentBase64).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that efficiently conveys the core action and resource. No unnecessary words or details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite high parameter count (11) and no output schema or annotations, the description provides minimal context. It omits return behavior, required preconditions (e.g., asset must exist), constraints on parameter combinations, and typical use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains each parameter. The description adds the notion of 'inline text or base64 content' which loosely maps to textContent and contentBase64, but provides no additional meaning beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'upload' and the resource 'new version of an existing uploaded design asset', specifying inline text or base64 content. It distinguishes from sibling 'create_design_asset_upload' by focusing on version creation, but does not explicitly name the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when inline text or base64 content needs to be added as a new version. However, it provides no guidance on when not to use this tool (e.g., for new assets) and does not mention sibling alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_design_assetGet Design AssetB

Get metadata for one asset by asset id or collection item id.

ParametersJSON Schema

Name	Required	Description	Default
`assetId`	Yes	Asset id or collection item id.

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fails to disclose behavioral traits like read-only safety, authentication requirements, or side effects. It only states the action without specifying that it does not modify data or require special permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no superfluous words. It is front-loaded with the action and resource, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (1 parameter, no output schema) and high schema coverage, the description is largely complete. It explains the identifier and the purpose. However, it lacks details about the returned metadata structure or potential errors, which would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description repeats the schema's 'asset id or collection item id' but adds no new meaning. The term 'metadata' is vague and does not clarify the shape or content of the response beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get', the resource 'metadata for one asset', and the identifier method 'by asset id or collection item id'. It distinguishes itself from sibling tools like 'get_design_asset_content' and 'get_design_asset_download_url' by focusing on metadata retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., get_design_asset_content for file content, search_design_collection_assets for multiple assets). No when-not or exclusion criteria are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_design_asset_contentGet Design Asset ContentA

Get inline text content for safe design assets such as catalog SVGs, uploaded SVGs, and Markdown files.

ParametersJSON Schema

Name	Required	Description	Default
`assetId`	Yes	Asset id or collection item id.

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions 'safe design assets' and examples but does not disclose behavior for unsafe assets, error conditions, return format, or authentication needs. Incomplete for a tool with no annotation support.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence efficiently conveys purpose with examples. No wasted words, appropriately front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Simple tool with 1 parameter and no output schema. Description covers basic functionality but lacks details on response format, error handling, or constraints. Sufficient for low complexity but could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with 'assetId' fully described (string, minLength, 'Asset id or collection item id.'). Description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Get', the resource 'inline text content', and scope 'for safe design assets such as catalog SVGs, uploaded SVGs, and Markdown files'. It effectively distinguishes from sibling tools like get_design_asset (metadata) and get_design_asset_download_url (URL).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when text content from safe assets is needed, but lacks explicit when-to-use or when-not-to-use guidance. No contrast with alternatives such as get_design_asset or search tools. Prerequisites (e.g., asset type must be one of listed) are not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_design_asset_download_urlGet Design Asset Download URLB

Get a short-lived download URL for an uploaded design asset.

ParametersJSON Schema

Name	Required	Description	Default
`assetId`	Yes	Uploaded asset id or collection item id.

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits. It only mentions 'short-lived' without specifying duration or requirements. It does not clarify input validation, error conditions, or authentication needs, leaving significant gaps for the agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence of 10 words efficiently conveys the purpose. No filler or unnecessary information, perfectly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and a single parameter, the description adequately communicates the output (a URL) but lacks details like URL expiry or error responses. It is minimally complete but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% as the assetId parameter has a description. The description adds no extra meaning beyond the schema's 'Uploaded asset id or collection item id.' Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'short-lived download URL for an uploaded design asset'. It distinguishes from sibling tools like get_design_asset and get_design_asset_content by specifying the return of a download URL.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives like get_design_asset or get_design_asset_content. The agent is left to infer usage from the description alone, which lacks context about prerequisites or scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_design_collection_contextGet Design Collection ContextB

Return metadata-first context for the configured FreeVectorIcons design collection.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions 'metadata-first' but does not state safety traits (e.g., read-only, side-effects, response size). For a zero-parameter tool, this lack of transparency is a moderate gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise and front-loaded with the verb and object. Every word adds value, making it efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description adequately conveys the purpose but leaves ambiguity about the exact content of 'context'. It could specify whether it returns metadata, counts, or links to assets.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the input schema is empty (100% documented). Baseline score 4 applies because the description adds no parameter information, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns 'metadata-first context' for a specific design collection, using a specific verb and resource. However, it does not differentiate from siblings like 'list_design_collection_assets' or 'search_design_collection_assets' beyond implying a high-level overview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. The term 'metadata-first context' implies a high-level summary, but without contrasting with siblings, the agent must infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_design_collection_assetsList Design Collection AssetsB

List metadata for assets in the configured design collection.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only states 'list metadata' but doesn't mention pagination, performance implications, or whether the collection must be pre-configured. No details on read-only nature or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler words. It is concise, though could benefit from additional context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list tool with no output schema, the description is minimally adequate. However, it lacks information on return format, potential size limits, or the meaning of 'configured design collection', leaving some ambiguity for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so the schema provides full coverage. The description adds no additional parameter information, but none is needed. Baseline for zero parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: listing metadata for assets in a design collection. However, it does not explicitly differentiate from sibling tools like search_design_collection_assets, though the verb 'list' vs 'search' implies scope difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as search_design_collection_assets or get_design_asset. The description lacks context about prerequisites or filtering capabilities.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

park_design_assetPark Design AssetC

Upload inline text or base64 content directly into the configured FVI collection for DRL handoff.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	File name for the asset.
`tags`	No	Optional searchable tags.
`metadata`	No	Additional JSON metadata to store on the asset.
`contentType`	Yes	MIME type for the uploaded asset.
`textContent`	No	UTF-8 text content for SVG, Markdown, or other text assets.
`documentType`	No	Optional document type for Markdown/PDF supporting documents.
`drlAssetType`	No	Optional DRL asset role, e.g. logo, brief, source_art, mockup.
`drlProjectId`	No	Optional DRL project identifier to store in metadata.
`contentBase64`	No	Base64-encoded binary content for image/PDF assets.
`checksumSha256`	No	Optional SHA-256 checksum for provenance.

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full burden for behavioral disclosure. It indicates a write operation (upload) but fails to disclose important traits like idempotency, overwrite behavior, authentication requirements, or what happens on failure. The lack of detail leaves the agent uninformed about side effects or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but insufficient for a tool with 10 parameters. It front-loads the action and medium but lacks structure or breakdown of complex behavior. For the complexity, it could be more verbose without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 params, nested objects, no output schema), the description is incomplete. It does not explain return values, error handling, or how to specify which content field to use. Critical context is missing for an upload tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema, merely indicating 'inline text or base64 content'. It does not explain the mutual exclusivity of textContent and contentBase64, nor the purpose of optional parameters like tags, metadata, or drlAssetType.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (upload), the content types (inline text or base64), and the destination (FVI collection for DRL handoff). It distinguishes from sibling tools like create_design_asset_upload by focusing on inline content rather than file uploads, though not explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as create_design_asset_upload for file uploads or how to choose between textContent and contentBase64. No when-not-to-use or prerequisite conditions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_design_collection_assetsSearch Design Collection AssetsB

Search design collection asset metadata by name, type, category, style, or tag.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query for asset metadata.

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention if the tool is read-only, whether results are paginated, or what happens with no results. The minimal description does not adequately convey behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that communicates the tool's function. It is front-loaded and has no unnecessary words. However, it could benefit from a slightly more structured format (e.g., listing supported filters).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one parameter and no output schema, the description is minimally adequate. It explains what the tool searches but does not cover return format, sorting, or result limits. For a search tool, this is a noticeable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with one parameter 'query' described as 'Search query for asset metadata.' The description adds valuable semantics by specifying the searchable fields (name, type, category, style, or tag), which goes beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches design collection asset metadata by specific fields (name, type, category, style, or tag). This distinguishes it from sibling tools like 'list_design_collection_assets' (which lists all assets) and 'get_design_asset' (which retrieves a specific asset).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. It does not mention that it is for filtering or searching as opposed to listing or retrieving individual assets. The description lacks context on prerequisites or scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv0.1.2Jun 27, 2026
- First observedcreate_design_asset_upload
- First observedcreate_design_asset_version
- First observedget_design_asset
- First observedget_design_asset_content
- First observedget_design_asset_download_url
- First observedget_design_collection_context
- First observedlist_design_collection_assets
- First observedpark_design_asset
- First observedsearch_design_collection_assets

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct operation on design assets, such as creating, uploading versions, retrieving metadata or content, listing, searching, and collection context. No two tools overlap in purpose.

Naming Consistency5/5

All tool names follow the verb_noun pattern with underscores, using consistent verbs (create, get, list, park, search) and nouns (design_asset, design_collection_assets, etc.). The pattern is uniformly applied.

Tool Count5/5

With 9 tools covering creation, retrieval, listing, searching, and context, the set is well-scoped for managing a design asset collection without being too sparse or bloated.

Completeness4/5

The tool set covers most common operations but lacks update and delete functionality for assets, which could create dead ends for agents needing to modify or remove assets.

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SVGFarmOAuth
io.github.joshuajansen
Search open SVG icon packs and fetch exact SVG markup from coding agents through MCP.
Design Tools Developer Tools
2
Figma MCP ServerOAuth
com.figma.mcp
The Figma MCP server brings Figma design context directly into your AI workflow.
Developer Tools Content Management Systems
31,960
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
AgentMarketplace A
io.github.raditotev
MCP Server for an Agent Task Marketplace
Autonomous Agents Agent Orchestration
221

Related MCP Servers

PickAPIcon MCP
Art & Culture Search Developer Tools
Leee62
A
license
B
quality
D
maintenance
MCP server that allows FE/UI/Designers to retrieve SVG icons via the Iconify API by simply asking LLMs rather than manually searching websites.
Updated a year ago (2025-05-26 02:36 UTC)
3
30
4
MIT
RemixIcon MCPofficial
Search Developer Tools
Remix-Design
A
license
A
quality
C
maintenance
An MCP server that enables users to search the Remix Icon catalog by mapping keywords to icon metadata using a high-performance local index. It returns the top five most relevant icon matches with categories and tags to streamline icon selection for design and development tasks.
Updated a month ago (2026-08-07 02:27 UTC)
1
77
92
MIT
icogenie-mcp
albertnahas
A
license
Not graded
quality
C
maintenance
AI-powered SVG icon generation MCP server. Generate production-ready SVG icons from text descriptions with customizable styles, sizes, and themes.
Updated 6 months ago (2026-03-06 08:23 UTC)
44
6
MIT
mdi-mcp-server
Design Tools Art & Culture
romeldev
F
license
Not graded
quality
C
maintenance
MCP server for searching Material Design Icons, enabling AI agents to find icons by name, alias, category, or concept.
Updated 2 months ago (2026-07-15 22:09 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/FreeVectorIcons/fvi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@freevectoricons/mcp

Overview

Requirements

Setup

macOS (Claude Desktop)

Windows (Claude Desktop)

Linux (Claude Desktop)

Environment variables

Token security

Tools

Read (always available)

Write (enabled by default)

Limitations

Development

Packaging

Publishing (CD only)

Related

License

Available Tools

Tool Schema Changelog

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

RemixIcon MCPofficial

Latest Blog Posts

MCP directory API