Penpot MCPは、AI言語モデルとオープンソースの設計・プロトタイピングプラットフォームであるPenpot間のギャップを埋める革新的なモデルコンテキストプロトコル（MCP）サーバーです。この統合により、Claude（Claude DesktopとCursor IDEの両方）などのAIアシスタントが、設計ファイルをプログラム的に理解、分析、操作できるようになります。
🤖 AIネイティブデザイン分析：Claude AIがUI/UXデザインを分析し、フィードバックを提供し、改善を提案します
⚡ 自動化された設計ワークフロー: AIを活用した自動化で反復的な設計タスクを効率化
🔍 インテリジェントなデザイン検索: 自然言語を使用してプロジェクト全体のデザインコンポーネントとパターンを検索します
📊 デザインシステム管理：AIの支援によりデザインシステムを自動的に文書化および維持します
🎨 クロスプラットフォーム統合：MCP 互換の AI アシスタント (Claude Desktop、Cursor IDE など) と連携します。
Related MCP server: AI-Canvas MCP Server
Penpot MCP の動作を確認するには、デモ ビデオをご覧ください。
MCPプロトコル実装: モデルコンテキストプロトコル標準に完全準拠
リアルタイム設計アクセス: ペンポットのAPIと直接統合してライブ設計データを利用
コンポーネント分析: AIを活用した設計コンポーネントとレイアウトの分析
エクスポート自動化: 複数の形式でのデザインアセットのプログラムによるエクスポート
設計検証：自動設計システムのコンプライアンスチェック
コマンドラインユーティリティ: 設計ファイルの分析と検証のための強力なCLIツール
Python SDK : カスタム統合のための包括的な Python ライブラリ
REST API : Webアプリケーション統合用のHTTPエンドポイント
拡張可能なアーキテクチャ: カスタム AI ワークフロー用のプラグイン システム
Claude Desktop と Cursor の統合: Claude Desktop と Cursor IDE の両方で Claude AI アシスタントをネイティブにサポート
設計コンテキストの共有: AIモデルに設計コンテキストを提供して、より適切な応答を実現します。
視覚コンポーネント認識: AIは設計コンポーネントを「見て」理解することができます
自然言語クエリ: デザインについて分かりやすい英語で質問できます
IDE統合: 最新の開発環境とのシームレスな統合
デザインレビューの自動化: アクセシビリティ、ユーザビリティ、デザイン原則に関する AI フィードバックを即座に取得
コンポーネントドキュメント: デザインシステムのドキュメントを自動生成
デザインの一貫性チェック: プロジェクト全体でブランドガイドラインに準拠していることを確認する
アセットの整理: AIを活用したデザインコンポーネントのタグ付けと分類
設計からコードまでのワークフロー: AI 支援により設計と開発のギャップを埋める
API統合:カスタムツールとワークフローの設計データへのプログラムによるアクセス
自動テスト: 設計仕様から視覚的な回帰テストを生成する
デザインシステムの同期: デザイントークンとコードコンポーネントを同期させます
デザイン分析: デザインシステムの採用とコンポーネントの使用状況を追跡
コラボレーションの強化：AIを活用した設計レビューとフィードバック収集
ワークフローの最適化: 反復的な設計操作と承認を自動化
ツール間の統合:デザインワークフローでPenpotを他のツールに接続します
Python 3.12+ (最適なパフォーマンスを得るには最新の Python を推奨)
ペンポットアカウント（無料登録）
Claude Desktop または Cursor IDE (オプション、AI 統合用)
Python 3.12以上
Penpotアカウントの資格情報
pip install penpot-mcp# Install directly with uvx (when published to PyPI)
uvx penpot-mcp
# For local development, use uvx with local path
uvx --from . penpot-mcp
# Or install in a project with uv
uv add penpot-mcp# Clone the repository
git clone https://github.com/montevive/penpot-mcp.git
cd penpot-mcp
# Using uv (recommended)
uv sync
uv run penpot-mcp
# Or using traditional pip
python -m venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
pip install -e .Penpot の資格情報を使用して、 env.exampleに基づいて.envファイルを作成します。
PENPOT_API_URL=https://design.penpot.app/api
PENPOT_USERNAME=your_penpot_username
PENPOT_PASSWORD=your_penpot_password
PORT=5000
DEBUG=true# Using uvx (when published to PyPI)
uvx penpot-mcp
# Using uvx for local development
uvx --from . penpot-mcp
# Using uv in a project (recommended for local development)
uv run penpot-mcp
# Using the entry point (if installed)
penpot-mcp
# Or using the module directly
python -m penpot_mcp.server.mcp_serverMCP サーバーをデバッグするには、次の操作を実行します。
.envファイルでDEBUG=trueを設定してデバッグモードを有効にします。
API 操作をテストするには、Penpot API CLI を使用します。
# Test API connection with debug output
python -m penpot_mcp.api.penpot_api --debug list-projects
# Get details for a specific project
python -m penpot_mcp.api.penpot_api --debug get-project --id YOUR_PROJECT_ID
# List files in a project
python -m penpot_mcp.api.penpot_api --debug list-files --project-id YOUR_PROJECT_ID
# Get file details
python -m penpot_mcp.api.penpot_api --debug get-file --file-id YOUR_FILE_IDパッケージにはユーティリティ コマンドライン ツールが含まれています。
# Generate a tree visualization of a Penpot file
penpot-tree path/to/penpot_file.json
# Validate a Penpot file against the schema
penpot-validate path/to/penpot_file.json# Start your MCP server in one terminal
python -m penpot_mcp.server.mcp_server
# In another terminal, use mcp-cli to monitor and interact with your server
python -m mcp.cli monitor python -m penpot_mcp.server.mcp_server
# Or connect to an already running server on a specific port
python -m mcp.cli monitor --port 5000# Start your MCP server in one terminal
python -m penpot_mcp.server.mcp_server
# In another terminal, run the MCP Inspector (requires Node.js)
npx @modelcontextprotocol/inspector# Run the example client
penpot-clientserver://info - サーバーの状態と情報
penpot://schema - JSON形式のPenpot APIスキーマ
penpot://tree-schema - JSON 形式の Penpot オブジェクト ツリー スキーマ
rendered-component://{component_id} - レンダリングされたコンポーネント画像
penpot://cached-files - キャッシュされたPenpotファイルのリスト
list_projects - すべてのPenpotプロジェクトを一覧表示する
get_project_files - 特定のプロジェクトのファイルを取得する
get_file - IDでPenpotファイルを取得し、キャッシュする
export_object - ペンポットオブジェクトを画像としてエクスポートする
get_object_tree - ペンポットオブジェクトのオブジェクトツリー構造を取得します
search_object - ペンポットファイル内のオブジェクトを名前で検索する
Penpot MCPサーバーは、モデルコンテキストプロトコル（CMP）を介してAIアシスタントと統合できます。Claude DesktopとCursor IDEの両方をサポートし、シームレスな設計ワークフローの自動化を実現します。
Claude Desktop の詳細なセットアップ手順については、 CLAUDE_INTEGRATION.md を参照してください。
Claude Desktop 構成ファイル (macOS の場合は~/Library/Application Support/Claude/claude_desktop_config.json 、Windows の場合は%APPDATA%\Claude\claude_desktop_config.json ) に次の構成を追加します。
{
"mcpServers": {
"penpot": {
"command": "uvx",
"args": ["penpot-mcp"],
"env": {
"PENPOT_API_URL": "https://design.penpot.app/api",
"PENPOT_USERNAME": "your_penpot_username",
"PENPOT_PASSWORD": "your_penpot_password"
}
}
}
}Cursor IDEは、AI統合機能を通じてMCPサーバーをサポートします。Penpot MCPをCursorで設定するには、以下の手順に従ってください。
MCP サーバーをインストールします(まだインストールされていない場合)。
pip install penpot-mcpカーソル設定にMCPサーバーを追加して、カーソル設定を構成します。カーソル設定を開き、以下を追加します。
{
"mcpServers": {
"penpot": {
"command": "uvx",
"args": ["penpot-mcp"],
"env": {
"PENPOT_API_URL": "https://design.penpot.app/api",
"PENPOT_USERNAME": "your_penpot_username",
"PENPOT_PASSWORD": "your_penpot_password"
}
}
}
}代替案: プロジェクト ルートに.envファイルを作成して環境変数を使用します。
PENPOT_API_URL=https://design.penpot.app/api
PENPOT_USERNAME=your_penpot_username
PENPOT_PASSWORD=your_penpot_passwordプロジェクトでMCP サーバーを起動します。
# In your project directory
penpot-mcpカーソルでの使用: 設定が完了すると、次のような質問をして、カーソル内で直接ペンポットのデザインを操作できるようになります。
「Penpotアカウント内のすべてのプロジェクトを表示」
「プロジェクトXの設計コンポーネントを分析する」
「メインボタンコンポーネントを画像としてエクスポートする」
「このファイルではどのようなデザインパターンが使用されていますか？」
Claude Desktop と Cursor の統合はどちらも以下を提供します。
Penpotプロジェクトとファイルへの直接アクセス
AIを活用した洞察による視覚的なコンポーネント分析
アセットとコンポーネントの設計エクスポート機能
デザインファイルに関する自然言語クエリ
リアルタイムのデザインフィードバックと提案
デザインシステムドキュメント生成
penpot_mcp/
├── api/ # Penpot API client
├── server/ # MCP server implementation
│ ├── mcp_server.py # Main MCP server
│ └── client.py # Client implementation
├── tools/ # Utility tools
│ ├── cli/ # Command-line interfaces
│ └── penpot_tree.py # Penpot object tree visualization
├── resources/ # Resource files and schemas
└── utils/ # Helper utilitiesこのプロジェクトではテストに pytest を使用します。
# Using uv (recommended)
uv sync --extra dev
uv run pytest
# Run with coverage
uv run pytest --cov=penpot_mcp tests/
# Using traditional pip
pip install -e ".[dev]"
pytest
pytest --cov=penpot_mcp tests/# Using uv (recommended)
uv sync --extra dev
# Set up pre-commit hooks
uv run pre-commit install
# Run linting
uv run python lint.py
# Auto-fix linting issues
uv run python lint.py --autofix
# Using traditional pip
pip install -r requirements-dev.txt
pre-commit install
./lint.py
./lint.py --autofix貢献を歓迎します！お気軽にプルリクエストを送信してください。
リポジトリをフォークする
機能ブランチを作成します（ git checkout -b feature/amazing-feature ）
変更をコミットします ( git commit -m 'Add some amazing feature' )
ブランチにプッシュする ( git push origin feature/amazing-feature )
プルリクエストを開く
コードがプロジェクトのコーディング標準に準拠しており、適切なテストが含まれていることを確認してください。
このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。
Penpot - オープンソースのデザインとプロトタイピングのプラットフォーム
モデルコンテキストプロトコル- AIモデルコンテキストの標準化されたプロトコル
Export a Penpot design object as an image.
Args:
file_id: The ID of the Penpot file
page_id: The ID of the page containing the object
object_id: The ID of the object to export
export_type: Image format (png, svg, etc.)
scale: Scale factor for the exported image
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | ||
| page_id | Yes | ||
| object_id | Yes | ||
| export_type | No | png | |
| scale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Export') but lacks details on permissions needed, whether it's a read-only or write operation, rate limits, or what the output entails (e.g., file download link, binary data). This is inadequate for a tool with potential side effects like file generation.
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 appropriately sized and front-loaded, starting with the core purpose in the first sentence. The parameter explanations are listed efficiently in bullet-point style under 'Args:', though some could be more concise (e.g., 'etc.' in export_type is vague). Overall, it avoids unnecessary verbosity.
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?
Given no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It covers the basic action and parameters but misses critical behavioral context (e.g., output format, side effects) and usage guidelines relative to siblings. For a 5-parameter tool with potential file operations, this leaves significant gaps for an agent.
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 0%, so the description must compensate. It lists all 5 parameters with brief explanations (e.g., 'Image format (png, svg, etc.)' for export_type), adding basic semantics beyond the schema's titles. However, it doesn't provide deeper context like valid export_type values beyond examples or scale constraints, leaving gaps in understanding.
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 ('Export') and resource ('a Penpot design object as an image'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_rendered_component' or 'search_object', which might also involve object retrieval or rendering, so it falls short of a perfect score.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_rendered_component' and 'search_object' available, there's no indication of scenarios where 'export_object' is preferred, such as for image file generation versus in-app viewing, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all files currently stored in the cache.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists files from the cache, implying a read-only operation, but does not specify details like whether the list is paginated, sorted, filtered, or includes metadata. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, clear sentence that directly states the tool's function without unnecessary words. It is front-loaded and efficiently conveys the core purpose, making it easy to understand at a glance.
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?
Given the tool has no parameters and no output schema, the description adequately covers the basic purpose. However, it lacks details on behavioral aspects (e.g., output format, caching specifics) and usage guidelines, which are important for an agent to invoke it correctly. The simplicity of the tool means the description is minimally viable but could be more informative.
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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description does not need to add parameter semantics, but it correctly implies no inputs are required. A baseline score of 4 is appropriate as it aligns with the lack of parameters.
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 ('List') and resource ('files currently stored in the cache'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_file' or 'get_project_files', which might also retrieve files but from different sources or with different scopes.
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 provides no guidance on when to use this tool versus alternatives, such as 'get_file' (which might retrieve a specific file) or 'get_project_files' (which might list files in a project context). There is no mention of prerequisites, exclusions, or recommended contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a Penpot file by its ID and cache it. Don't use this tool for code generation, use 'get_object_tree' instead.
Args:
file_id: The ID of the Penpot file
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes |
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 reveals two important behavioral traits: 1) the tool caches the retrieved file, and 2) it's specifically not intended for code generation purposes. However, it doesn't mention potential side effects, error conditions, or response format.
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 appropriately sized with two main sentences and a parameter section. The first sentence states the purpose, the second provides usage guidance, and the Args section documents the parameter. There's minimal waste, though the formatting could be cleaner.
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 tool with no annotations, no output schema, and 0% schema description coverage, the description provides adequate basics (purpose, usage guidance, parameter meaning) but lacks details about return values, error handling, caching behavior specifics, or authentication requirements that would be helpful for an AI agent.
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?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation. It provides the parameter name 'file_id' and clarifies it's 'The ID of the Penpot file', which adds meaningful context beyond the bare schema. However, it doesn't specify format requirements or validation rules.
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 specific action ('Retrieve a Penpot file by its ID') and resource ('Penpot file'), and distinguishes it from sibling tools by explicitly naming 'get_object_tree' as an alternative for code generation. This provides excellent differentiation.
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 provides explicit guidance on when NOT to use this tool ('Don't use this tool for code generation') and names a specific alternative ('use get_object_tree instead'). This gives clear context for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the object tree structure for a Penpot object ("tree" field) with rendered screenshot image of the object ("image.mcp_uri" field). Args: file_id: The ID of the Penpot file object_id: The ID of the object to retrieve fields: Specific fields to include in the tree (call "penpot_tree_schema" resource/tool for available fields) depth: How deep to traverse the object tree (-1 for full depth) format: Output format ('json' or 'yaml')
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | ||
| object_id | Yes | ||
| fields | Yes | ||
| depth | No | ||
| format | No | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes what the tool returns (tree structure and screenshot) but lacks behavioral details such as whether this is a read-only operation, potential rate limits, authentication needs, error handling, or how the screenshot is generated (e.g., rendering time, size). For a tool with 5 parameters and no annotations, this is a significant gap in transparency.
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 appropriately sized and front-loaded, starting with the core purpose followed by parameter details in a structured list. Every sentence adds value, such as explaining parameter purposes and referencing other tools. Minor improvements could include briefer phrasing, but overall it's efficient and well-organized.
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?
Given 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers parameter semantics well and references another tool for schema details, but lacks information on return values, error cases, or behavioral traits. For a tool with this complexity, it should provide more context on output structure and usage constraints to be fully helpful.
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 0%, so the description must compensate. It provides clear semantics for all 5 parameters: 'file_id' and 'object_id' identify the target, 'fields' specifies what to include with a reference to another tool, 'depth' controls traversal with -1 meaning full depth, and 'format' sets output format. This adds substantial meaning beyond the bare schema, though it could elaborate on default behaviors beyond the schema's defaults.
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 action ('Get') and the resource ('object tree structure for a Penpot object'), including specific output fields like 'tree' and 'image.mcp_uri'. It distinguishes from siblings like 'get_file' or 'search_object' by focusing on tree structure and screenshot rendering. However, it doesn't explicitly contrast with 'penpot_tree_schema', which is mentioned as a reference 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?
The description implies usage when needing object tree structure with a rendered screenshot, but doesn't explicitly state when to use this versus alternatives like 'get_file' for basic file info or 'search_object' for finding objects. It references 'penpot_tree_schema' for field details, providing some context, but lacks clear exclusions or comparative guidance with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all files contained within a specific Penpot project.
Args:
project_id: The ID of the Penpot project
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves files but doesn't describe return format (e.g., list structure, file metadata), pagination, rate limits, authentication needs, or error conditions. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 appropriately concise with two sentences: one for the purpose and one for the parameter. It's front-loaded with the core functionality. However, the formatting includes unnecessary indentation and whitespace, slightly detracting from structure.
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?
Given the complexity (a read operation with no annotations, no output schema, and 0% schema coverage), the description is incomplete. It doesn't explain what 'files' means in this context (e.g., file types, metadata), how results are returned, or potential limitations. For a tool that likely returns a list of resources, more context is needed to use it effectively.
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 description adds minimal parameter semantics: it explains that 'project_id' is 'The ID of the Penpot project.' With 0% schema description coverage (schema has no descriptions), this provides basic meaning. However, it doesn't clarify format (e.g., UUID), sourcing, or validation rules. Since there's only one parameter, the baseline is 4, but the lack of detail beyond a tautological explanation reduces it to 3.
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's purpose: 'Get all files contained within a specific Penpot project.' It specifies the verb ('Get') and resource ('files'), and distinguishes it from siblings like 'get_file' (singular) and 'list_projects' (different resource). However, it doesn't explicitly differentiate from 'get_cached_files' or 'export_object', which could be 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when-not scenarios, prerequisites, or compare it to siblings like 'get_file' (for a single file) or 'search_object' (for filtered searches). The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a rendered component image by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| component_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns an image, but doesn't describe format, size, caching behavior, error handling, or authentication needs. For a tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
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, efficient sentence that directly states the tool's purpose. It's front-loaded with no wasted words, making it easy to parse quickly.
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?
Given the tool's complexity (retrieving rendered images), lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't address return values, error cases, or operational context, leaving the agent with insufficient information for reliable invocation.
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 0%, so the description must compensate. It mentions 'component_id' but doesn't explain what a component ID is, its format, or where to find it. With one undocumented parameter, the description adds minimal value beyond the schema's basic structure.
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 action ('Return') and resource ('rendered component image by its ID'), making the purpose understandable. However, it doesn't distinguish this tool from siblings like 'get_file' or 'get_cached_files', which might also retrieve files or images, so it lacks sibling differentiation.
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 guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, leaving the agent without usage instructions. This is a significant gap in helping the agent select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a list of all available Penpot projects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the action ('Retrieve a list') but does not cover critical traits like pagination, rate limits, authentication needs, or what 'all available' entails (e.g., permissions, archived projects). This leaves significant gaps for a read operation.
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, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple retrieval tool.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks details on return format, pagination, or error handling, which are important for a list retrieval tool, making it incomplete for optimal agent use.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not add parameter details, aligning with the schema's completeness, but could have mentioned implicit constraints like authentication or scope.
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 ('Retrieve') and resource ('list of all available Penpot projects'), making the purpose unambiguous. However, it does not differentiate from sibling tools like 'get_project_files' or 'search_object', which might also involve project retrieval, so it misses full sibling distinction.
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 guidance is provided on when to use this tool versus alternatives such as 'get_project_files' or 'search_object'. The description implies a broad retrieval but lacks context on use cases or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide the Penpot API schema as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states what the tool does but fails to describe key traits such as whether it's a read-only operation, potential rate limits, authentication needs, or what the JSON output structure entails. This leaves significant gaps in understanding the tool's behavior.
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, direct sentence that efficiently conveys the core function without any wasted words. It is front-loaded with the essential information, making it highly concise and well-structured for quick comprehension.
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?
Given the tool's simplicity (0 parameters, no output schema), the description is minimal but insufficient. It lacks context about the schema's scope (e.g., full API vs. partial), format details, or how it differs from 'penpot_tree_schema'. Without annotations or output schema, more completeness is needed to guide effective use.
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 tool has zero parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it appropriately avoids redundancy. A baseline of 4 is applied since no parameters exist, and the description doesn't mislead about inputs.
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 action ('Provide') and resource ('Penpot API schema as JSON'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'penpot_tree_schema', which appears to serve a similar schema-related function, preventing a perfect score.
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 offers no guidance on when to use this tool versus alternatives like 'penpot_tree_schema' or other schema-related operations. It lacks context about prerequisites, timing, or comparisons with sibling tools, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide the Penpot object tree schema as JSON.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on traits like whether it's read-only, requires authentication, has rate limits, or returns structured data. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's function with zero waste. It is front-loaded and appropriately sized for a simple tool, making it easy for an agent to parse and understand quickly.
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?
Given the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is minimally adequate but has clear gaps. It explains what the tool does but omits behavioral context and usage guidelines relative to siblings, making it incomplete for optimal agent decision-making in a server with multiple related tools.
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 tool has 0 parameters, and schema description coverage is 100%, so there is no need for parameter semantics in the description. The baseline for this scenario is 4, as the description appropriately avoids redundant information and focuses on the tool's purpose without unnecessary details.
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 ('Provide') and resource ('Penpot object tree schema as JSON'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'penpot_schema' or 'get_object_tree', which likely serve related but different purposes, preventing a perfect score.
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 offers no guidance on when to use this tool versus alternatives. With sibling tools such as 'penpot_schema' and 'get_object_tree' available, there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for objects within a Penpot file by name.
Args:
file_id: The ID of the Penpot file to search in
query: Search string (supports regex patterns)
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches for objects by name and supports regex patterns, which adds some context. However, it doesn't cover critical aspects like whether this is a read-only operation, what happens if no matches are found, if there are rate limits, or the format of the return value (especially since there's no output schema). For a search tool with zero annotation coverage, this leaves significant gaps.
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 appropriately sized and front-loaded, with the main purpose stated first in a clear sentence. The Args section is structured and adds necessary details without redundancy. However, the use of triple quotes and extra whitespace slightly detracts from efficiency, but overall, it's concise and well-organized.
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?
Given the complexity of a search operation with 2 parameters, no annotations, and no output schema, the description is incomplete. It explains the parameters but lacks information on behavioral traits (e.g., error handling, performance), output format, or how results are returned. Without annotations or an output schema, more context is needed for the agent to use the tool effectively.
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 description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'file_id' is 'The ID of the Penpot file to search in' and 'query' is a 'Search string (supports regex patterns)', providing clarity on their roles. Since the schema only lists titles ('File Id', 'Query') without descriptions, this compensates well, though it doesn't detail constraints like format or length.
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's purpose: 'Search for objects within a Penpot file by name.' It specifies the verb ('Search'), resource ('objects within a Penpot file'), and method ('by name'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_object_tree' or 'get_file', which might also retrieve objects or file data.
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 provides no guidance on when to use this tool versus alternatives. It mentions searching by name but doesn't compare to siblings like 'get_object_tree' (which might list all objects) or 'get_file' (which might retrieve file metadata). There's no mention of prerequisites, such as needing a valid file ID, or exclusions, leaving the agent to infer usage context.
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.
export_objectget_cached_filesget_fileget_object_treeget_project_filesget_rendered_componentlist_projectspenpot_schemapenpot_tree_schemasearch_objectScored across 10 tools
Most tools have distinct purposes, but 'get_file' and 'get_object_tree' could be confused as both retrieve file/object data, though their descriptions clarify different use cases (caching vs. tree structure with image). Other tools like export_object, list_projects, and search_object are clearly differentiated.
Tools follow a consistent verb_noun pattern (e.g., export_object, get_file, list_projects) with minor deviations: 'penpot_schema' and 'penpot_tree_schema' use noun-only names, breaking the pattern slightly but remaining readable and domain-specific.
With 10 tools, the count is well-scoped for a Penpot design server, covering key operations like listing projects, retrieving files, exporting objects, and searching, without being overwhelming or too sparse.
The toolset covers essential Penpot operations such as listing, retrieving, exporting, and searching, with minor gaps like updating or creating design objects (e.g., no create_file or update_object tools), but agents can likely work around this for basic workflows.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
AI-agent design tools: fonts, font recognition, palettes, color naming, contrast, code, SVG, CSS.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
