PixelVault
pixelvault-mcp
PixelVault용 MCP 서버 — 사전 승인된 라이선스 에셋을 위한 AI 네이티브 마켓플레이스입니다.
설치
Claude Desktop 설정에 추가하세요:
{
"mcpServers": {
"pixelvault": {
"command": "npx",
"args": ["-y", "pixelvault-mcp"]
}
}
}또는 직접 실행하세요:
npx pixelvault-mcpRelated MCP server: webfetch
도구
search_assets
자연어 브리핑을 사용하여 PixelVault의 사전 승인된 AI 생성 에셋 데이터베이스를 검색합니다. 각 일치 항목에 대한 규정 준수 상태 및 근거가 포함된 순위가 매겨진 단기 목록을 반환합니다.
get_asset_details
ID를 통해 특정 에셋에 대한 전체 메타데이터 및 규정 준수 문서를 검색합니다.
generate_usage_agreement
프로젝트 매개변수(사용 유형, 지역, 기간, 플랫폼)를 기반으로 완성된 사용 계약서 초안을 생성합니다.
소개
PixelVault는 규정 준수가 완료된 AI 에셋 마켓플레이스입니다. 모든 에셋은 라이선스가 부여된 AI 플랫폼(Adobe Firefly, Moonvalley)에서 소싱되며 상업적 사용을 위해 사전 승인되었습니다. 이 MCP 서버를 사용하면 Claude 에이전트가 워크플로우를 벗어나지 않고도 에셋을 검색, 평가 및 라이선스할 수 있습니다.
npm:
pixelvault-mcp
라이선스
MIT
Available Tools
3 toolsgenerate_usage_agreementA
Generate a usage agreement document for approved PixelVault assets. Call after human approval of a shortlist.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_ids | Yes | Approved asset IDs. | |
| project_title | Yes | Production or project title. | |
| production_company | Yes | Production company name. | |
| distribution_platform | Yes | Distribution platforms (e.g. Netflix, Broadcast). | |
| territory | Yes | Distribution territory. | |
| air_date | No | Anticipated air date (YYYY-MM-DD). | |
| license_type | Yes | License type. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits beyond generation, such as side effects, idempotency, or output format. This is a significant gap for a mutation-like tool.
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 a single sentence plus a usage hint, which is concise and front-loaded. However, it could be slightly more structured to include expected output, but overall it's efficient.
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 generation tool with 7 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the output, success/failure indicators, or any prerequisites beyond 'approved' assets.
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?
The input schema describes all 7 parameters with coverage of 100%, so the schema carries the meaning. The description adds no additional semantic value beyond what the schema provides.
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 'generate', the resource 'usage agreement document', and the context 'for approved PixelVault assets'. It distinguishes well from sibling tools (get_asset_details, search_assets) which focus on 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?
The description gives explicit when-to-use: 'Call after human approval of a shortlist.' It provides clear context but does not explicitly mention when not to use or alternatives, though siblings are clearly different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_asset_detailsB
Get full metadata and compliance documentation for a specific PixelVault asset by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | The asset ID returned by search_assets. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it's a read operation but doesn't disclose potential costs, required permissions, error behavior, or rate limits. Lacks details beyond basic purpose.
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?
Single sentence, 13 words, no fluff. Efficient but slightly terse; could include more context without being verbose.
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?
No output schema, and description doesn't outline what 'full metadata and compliance documentation' includes. Agents need more behavioral guidance for a tool that presumably returns complex data.
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 provides a clear description for the sole parameter 'asset_id' (returned by search_assets). Tool description adds no extra meaning beyond 'by ID', so baseline 3 applies.
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 'Get full metadata and compliance documentation for a specific PixelVault asset by ID.' Distinguishes from siblings: search_assets returns lists, generate_usage_agreement creates documents.
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?
No explicit when-to-use or alternatives. Implies use with an asset ID, but doesn't mention prerequisites (e.g., need to call search_assets first) or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_assetsA
Search PixelVault for pre-cleared, commercially licensed AI-generated assets matched to a creative brief. Every asset is sourced from licensed AI platforms (Adobe Firefly, Moonvalley) and carries a compliance-cleared status. Returns a ranked shortlist with compliance status, format, platform, and rationale.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | Natural language description of the visual asset needed. | |
| license_type | No | License type required. Auto-detected from brief if omitted. | |
| format | No | Asset format filter. | |
| vertical | No | Vertical: post production, editorial, or ecommerce. | |
| territory | No | Distribution territory (e.g. Worldwide, US Only). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses asset sourcing, compliance status, and output structure (ranked shortlist with specific fields). Lacks details on limitations, pagination, or rate limits, but sufficient for a search tool.
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?
Two sentences, front-loaded with purpose, second sentence adds output details. No wasted words, efficient and clear.
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 5-parameter search tool with no output schema, description covers source, compliance, and output fields. Missing details on ranking criteria and empty results handling, but still fairly complete.
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 baseline is 3. Description adds context about matching to a brief and output fields, but does not significantly enhance parameter understanding beyond schema.
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?
Description clearly states the tool searches for pre-cleared, commercially licensed AI-generated assets matched to a creative brief, specifies source platforms and output fields. Distinguishes well from sibling tools (generate_usage_agreement, get_asset_details).
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?
No explicit guidance on when to use this tool versus alternatives. Usage is implicitly clear from purpose, but lacks when-not or alternative tool references.
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.
3 tool updates
v1.0.0- First observed
generate_usage_agreement - First observed
get_asset_details - First observed
search_assets
TDQS
Scored across 3 tools
Each tool has a distinct purpose: search assets, get details, and generate agreement. No overlap.
All tools follow a consistent verb_noun pattern with snake_case, e.g., search_assets, get_asset_details, generate_usage_agreement.
Three tools are well-scoped for the asset management workflow; each tool serves a clear role without unnecessary bulk.
The tools cover the full lifecycle for the stated purpose: search, retrieve details, and generate an agreement. No missing operations.
Maintenance
Related MCP Connectors
Licensed, rights-cleared content for AI agents - verifiable license keys + EU AI Act attestation.
AI Visibility and Content Intelligence tools for Claude and MCP-compatible agents.
Brand-safe MCP for AI agents to create editable, on-brand graphics and automate variants.
Build and manage AI-native customer support agents from Claude or any MCP client.
Related MCP Servers
AlicenseNot gradedqualityCmaintenanceAgentic commerce infrastructure for AI agents. MCP-native product discovery, contextual ad matching, and purchase facilitation with European privacy compliance (nDSG/GDPR).MIT- AlicenseAqualityBmaintenanceLicense-first federated image search for AI agents and humans. Exposes MCP tools for concise, attribution-aware image discovery, license probing, and guarded downloads across open, platform, and editorial sources.750 npm3MIT
- AlicenseNot gradedqualityDmaintenanceAffiliate product search for AI agents. Indexes structured merchant feeds — real prices, live stock, affiliate links built in. Works with any MCP client.MIT
- AlicenseAqualityDmaintenanceEnables AI agents to search, license, and pay for rights-clean music per use, returning a verifiable license certificate.5MIT