Skip to main content
Glama
Jinshin2534

ui-lift

by Jinshin2534
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

ui-lift

公開サイトを取り込み、そこで使われているUIコンポーネントとデザイントークンを、 AIがMCP経由で実装に使える形で取り出すツールです。主な利用者はAI（Claude Code等の コーディングエージェント）で、人はMCPの open_gallery が開くギャラリーで取り込み 結果を眺め、不要なものを間引いてライブラリの品質を保ちます。

これは何ではないか

デザインの参考にするためのツールであり、取り込んだサイトの複製・再公開を 目的としません。

  • 画像・ロゴ・フォントの実体（バイナリ）はダウンロードしません。加えて、 取り込み結果には元サイトを指すアセットURL参照も残りません（例外は 下記の「意図的に残る参照」の1点のみです）。属性は「捨てるものを列挙する」 のではなく「残すものを列挙する」許可リスト方式です（capture/snapshot.py の RETAINED_ATTRS / _prune_attrs()）: type, alt, role, disabled, checked, required, readonly, selected, multiple, open, controls, placeholder, aria-* だけが値ごと残り、それ以外の属性は タグを問わずすべて破棄されます。したがって <img src> / srcset、 <video poster>、<source src> はもちろん、<iframe src>、 <embed src>、<object data>、<track src>、<body background>、 SVG の <image href> のように個別に列挙していなかった参照も、次に 出てくる未知のタグ・属性も同じ規則で自動的に落ちます。href （<a> / <area> / <link> など）だけは特別扱いで、仕様が「値」ではなく 「有無」を残すとしているとおり、値を空文字列 "" に置き換えて 「href が存在した」という構造情報だけを残します。alt などの意味を持つ 属性と、寸法・レイアウトを表す rect は変わらず残ります。CSS側は特定の プロパティ名を決め打ちにせず、CAPTURED_PROPS（取得対象のCSSプロパティ 一覧）に含まれるどのプロパティであっても、値に url(...) 参照が1つでも 含まれていれば取り除きます（background-image はもちろん、カスタム カーソル画像を指定する cursor: url(...) のような他のプロパティでも 同様です）。値はカンマ区切りの「レイヤー」の並びとして扱い、url(...) を 含むレイヤーだけを落とします。linear-gradient() のような他のレイヤーや、 cursor: url(...), auto の auto のようなキーワードフォールバックは、 元サイトの参照を持たない限りそのまま残ります。全レイヤーが url(...) だけだった場合（安全に残せる断片が何もない場合）に限り、値全体を none に置き換えます。ページの表示自体にはブラウザが元サイトから画像・フォント を取得しますが、そのバイナリやURLがui-liftの保存物（スナップショット/ ライブラリ/生成コード）に載ることはありません。

    • background-image が linear-gradient(...) と url(...) を1つの値の 中で組み合わせている場合、url(...) レイヤーだけが落ち、グラデーション レイヤーは残ります。全レイヤーが url(...) のときだけ none（背景なし） になり、複数の背景画像を重ねていたページでは結果がフラットな背景に 見えることがあります。

    • 意図的に残る参照: get_component / get_design_tokens の出力先頭に 付く出典コメント（下記）には、取得元ページの URL（source_url、 ページ全体のURLであってアセットURLではない）がそのまま文字として 載ります。これは帰属表示のための意図した仕様で、render/html_css.py の _neutralize_html_comment_value により HTML コメント終端シーケンス （--> / --!>）は無害化されるため、値がコメントを抜け出して生きた マークアップになることはありません。この1箇所以外に、元サイトを指す 参照が出力に残る経路は現時点でありません。

    • <style> 要素に埋め込まれる CSS 値（StyleValue.raw、取得したページの computed style をそのまま使う）についても、</style> のような HTML の 生テキスト終了パターンを含む宣言は丸ごと破棄します（render/html_css.py の _declaration）。HTML は <style> を「生テキスト要素」として扱い、 CSS の文字列・コメント構文に関係なく </ + 英字で終端するため、 </style> の文字列一致だけでは </style foo> や </STYLE> を防げず、 ブラウザのgetComputedStyleが返した値をそのまま埋め込む以上、CSS引用符 の外側にリテラルに現れうる値として一般化して扱う必要があるためです。

  • 元サイトの class / id は保存しません（構造シグネチャの安定のためにも 意図的に捨てています）。生成されるクラス名は uil-<kind> 形式の独自命名です。

  • robots.txt を尊重します。Disallow されているパスは取り込み時に例外 (RobotsDisallowed) になり、取り込まれません。

  • ログインが必要なページは対象外です。ブラウザは毎回まっさらなコンテキストで 開くだけで、Cookie・認証情報を扱う仕組みは持ちません。

  • get_component / get_design_tokens が返すコードには、必ず取得元URLと 取得日時（と「デザインの参考用であり複製を目的としない」旨）がコメントとして 先頭に入ります。

Related MCP server: Hydra ACI

セットアップ

uv sync
uv run playwright install chromium

Playwrightは取り込み（ingest_site）のたびにHeadless Chromiumを起動します。 playwright install chromium を済ませていないと、取り込み時にブラウザ未検出の エラーになります。

Claude Code への登録

claude mcp add ui-lift -- uv --directory /path/to/ui-lift run ui-lift

/path/to/ui-lift はこのリポジトリの絶対パスに置き換えてください。PyPIには まだ公開していないので uvx ui-lift は使えません。

MCPツール

ツール

用途

ingest_site(url, viewports=["desktop"], min_occurrences=2)

サイトを取り込む（ネットワークアクセスあり）

reanalyze_site(site, min_occurrences=2)

保存済みスナップショットから、ネットワークに触れずコンポーネント・トークンを作り直す

list_sites()

取り込み済みサイト一覧

search_components(query=None, kind=None, site=None, limit=20)

検索（要約のみ返す）

get_component(id, format="html-css", variant="default")

貼れるコードを取り出す

get_design_tokens(site, format="css-vars")

トークン一式を取り出す

open_gallery(site=None)

ギャラリーを生成しブラウザで開く

search_components と get_component を分けているのは、AIが検索結果を全部 読み込まずに済むようにするためです。検索は軽い要約（id / site / kind / name / occurrences / summary）だけを返し、1つに絞ってから重いコードを get_component で取りに行く想定です。

viewports に渡せるのは mobile(390×844) / tablet(820×1180) / desktop (1440×900) の3つです。複数指定すると、desktop（無ければ指定した中の最初の ビューポート）を基準に、他のビューポートとの間でスタイルの差分を Component.responsive にビューポートごと・ノードパスごとで記録します。 副ビューポートの解析はベストエフォートで、失敗しても ingest_site の結果の failed_viewports に記録されるだけで取り込み全体は失敗しません。ただし現状 responsive の中身をレンダー出力やMCPのレスポンスとして直接取り出す経路は まだありません（ライブラリのJSONに保存されるのみです）。

format は html-css / css-vars / tailwind の3つです。

  • html-css: HTML断片＋<style>ブロック。クラス名は uil-<kind> または そこにタグ・パスを付与したもの。単独では自己完結しません: トークンに乗った値は var(--color-brand) のような参照のまま出力され、 そのカスタムプロパティ自体はここでは定義されません（定義するのは css-vars / get_design_tokens の役目）。実装先のページに同じトークン 定義がまだ無い場合は get_design_tokens(site, format="css-vars") も 合わせて取得し、一緒に貼り付けてください。get_component のレスポンス の notes にもこの旨が明記されます。ギャラリー（後述）のプレビューは この理由から、各コンポーネントの html-css 出力だけでなく css-vars 出力もあわせて同じ <iframe srcdoc> に埋め込んでいます。

  • css-vars: :root { --color-brand: #...; } 形式のCSSカスタムプロパティ。 トークンのみを扱う形式で、個々のコンポーネントの構造には触れません。 get_component(..., format="css-vars") はエラーにならず、指定した id / variant を無視してサイト全体のトークンをそのまま返します （実質 get_design_tokens(site="css-vars") と同じ結果）。この経路を 使ったことに呼び出し側（AI）が気づけるよう、レスポンスの notes に 「id / variant は無視されている」旨が明記されます。出典コメント（取得元 URL・取得日時）は get_component / get_design_tokens のどちらの経路 でも必ず付きます。コンポーネント個別のコードが欲しい場合は html-css か tailwind を使ってください。

  • tailwind: tailwind.config.js の theme.extend スニペット＋（コンポーネント 指定時は）Tailwindユーティリティクラス付きマークアップ。

kind は button / input / nav / card / table / list-item / badge / hero / block の9種類です。DOM構造とスタイルからの推定なので 外れることがあります。ギャラリーの「種類」ボタンで直せます。

Tailwind出力のキーに uil- 接頭辞が付く理由

tailwind.config.js の theme.extend はTailwindの組み込みスケールに マージされ、同名キーを上書きします（別名前空間を作るのではありません）。 つまり生成した spacing["2"] や borderRadius["md"] をそのまま貼り付けると、 既存プロジェクトの p-2 や rounded-md の意味を静かに書き換えてしまいます。 これを避けるため、生成するスケールキーには必ず uil- を前置します （spacing["uil-2"], borderRadius["uil-md"] のように）。Tailwindの 組み込みキーは数字や sm/md/lg のような短い名前なので、uil- を 付けることで衝突がなくなることを保証しています。

使い方の流れ

  1. ingest_site でサイトを取り込む

  2. open_gallery で結果を眺め、ゴミを捨てて（keep=false）、必要なら名前と 種類を直す

  3. 以降は search_components → get_component でAIが必要なものを取り出す

2 の選別をやるほど 3 の質が上がります。同じURLをingest_siteで再取り込み すると、人が付けた名前・種類・keep（残す/捨てる）の判定はそのまま引き継がれ ます。 前回あったコンポーネントが今回のページに見当たらなくなった場合も 削除はせず stale=true を立てるだけです（再度現れれば stale は自動的に 外れます）。stale のコンポーネントは検索から除外されません （削除ではなく印を付けるだけにしているのが目的なので、引き続き search_components / get_component で取り出せます）が、結果の各項目に stale が含まれるので呼び出し側（AI）は見分けられ、出現数が同じ場合は stale のものが後ろに並びます。

ギャラリー

open_gallery はローカルのみで待ち受けるHTTPサーバ（127.0.0.1、ポートは 自動割当）を起動し、既定のブラウザでそのURLを開きます。各コンポーネントは sandbox="" を付けた <iframe srcdoc="..."> の中に個別描画されます。これは、 取り込んだページ由来のCSS（クラス名がコンポーネント間で衝突しうる、任意の セレクタを含みうる等）がギャラリー自身のUI（他のタイルやボタン）を壊したり 隠したりしないようにするためです。iframeの外に一切漏れません。

画面でできること:

  • 名前 ボタン: コンポーネント名を変更

  • 種類 ボタン: kind を直接入力し直す（無効な値はサーバ側の POST /edit が400で拒否）

  • 捨てる ボタン: keep=false にする。以後 search_components の結果や ギャラリー自体（次回生成時）から外れます（ライブラリのJSONからは消えません）

サムネイル画像は撮っていません。ギャラリーは html-css 出力をその場で レンダリングして並べる作りなので、事前に画像を用意する必要がありません （Component.screenshot と Store.thumb_path は将来のための予約フィールドで、 現状どこからも書き込まれません）。

保存先

既定は ~/.ui-lift/。環境変数 UI_LIFT_HOME で変更できます。

<UI_LIFT_HOME>/library/<site-slug>/
  site.json                   # URL・取得日時・デザイントークンを含むサイト情報
  components/<id>.json        # コンポーネント（IR）。keep=false でも消えず残る
  snapshots/<viewport>.json   # 再解析用の生スナップショット（ビューポートごと）

site-slug はURLのホスト名から生成されます（例: https://example.com/ → example-com）。

スナップショットを残しているので、検出アルゴリズムを改善したときに再取得 せずにライブラリ全体を作り直せます。実際にそれをやるのが reanalyze_site MCPツールです。指定したサイトの保存済みスナップショット（全ビューポート） を読み、ingest_site と全く同じマージ（人が付けた名前・種類・keep の 引き継ぎ、消えたコンポーネントへの stale 印付け）を経てライブラリを 更新します。ネットワークには一切触れません。保存済みスナップショットが 1つも無いサイトを指定すると、そのサイト名を含むエラーになります。

開発

uv run pytest

analyze/ と render/ は純粋関数のみで構成されており、テストは保存済みの スナップショットJSON（または手書きのフィクスチャ）に対して行います。テスト内で 外部サイトにはアクセスしません。E2Eテスト（tests/test_e2e.py）は tests/fixtures/pages/ のローカルHTMLをテスト内で自前のHTTPサーバから配信し、 それに対してのみ実行します。

Available Tools

7 tools
get_componentC

コンポーネントを指定形式のコードとして取り出す。

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes
formatNohtml-css
variantNodefault

TDQS

C2.4/5.0
Behavior2/5

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

No annotations exist, so the description must convey behavioral traits. It only states extraction without indicating side effects, auth requirements, or whether the operation is read-only. Minimal behavioral context.

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, front-loading the purpose. However, it is too brief given the three parameters and lack of schema documentation.

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

Completeness1/5

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

With three parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what constitutes a component, supported formats, or variant semantics.

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

Parameters1/5

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

Schema description coverage is 0%, and the description fails to explain any of the three parameters (id, format, variant). It only hints at format via 'specified format' but provides no details on values or defaults.

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 extracts a component as code in a specified format. It distinguishes itself from siblings like search_components and get_design_tokens by focusing on extraction, but does not explicitly mention differentiation.

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 like search_components or open_gallery. The description does not include context, prerequisites, or exclusions.

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

get_design_tokensC

サイト全体のデザイントークンを指定形式で取り出す。

ParametersJSON Schema
NameRequiredDescriptionDefault
siteYes
formatNocss-vars

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only states the basic action. It does not disclose whether the operation is read-only, requires authentication, or what happens in error cases.

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 with no waste. However, it lacks structured formatting (e.g., bullet points) and is only in Japanese.

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 tool's simplicity (2 params, no output schema), the description is insufficient. It does not explain the return value (e.g., structure of design tokens) or provide enough context for correct invocation.

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

Parameters1/5

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

Schema description coverage is 0%. The description does not explain the 'site' parameter or the 'format' parameter beyond implying a format choice. The default value is not mentioned, nor are any valid values.

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 (retrieve) and resource (design tokens for entire site), and mentions the format parameter. However, it does not differentiate from sibling tools like get_component, and the acceptable formats are not specified.

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. There is no comparison with siblings (e.g., get_component) or mention of prerequisites or exclusions.

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

ingest_siteB

公開サイトを取り込み、UIコンポーネントとデザイントークンを抽出する。

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
viewportsNo
min_occurrencesNo

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 fully disclose behavioral traits. It only states extraction, but does not indicate whether the operation is destructive, stores data, requires authentication, or has 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 concise sentence, but it is too brief for a tool with three parameters and no annotations. It front-loads the main action but lacks structure for detailed information.

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 lack of output schema and annotations, the description should provide workflow context (what happens after ingestion, return format). It fails to do so, leaving the agent unsure about the tool's place in the process.

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

Parameters2/5

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

Schema coverage is 0%, yet the description explains none of the three parameters (url, viewports, min_occurrences). It implicitly refers to url but provides no details on viewports or min_occurrences, leaving the agent without semantic guidance.

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 tool ingests a public site and extracts UI components and design tokens. It distinguishes from sibling tools like search_components, get_component, get_design_tokens, and reanalyze_site, which focus on retrieval or reanalysis.

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 the tool is for initial extraction from a public site but does not specify when to use it versus reanalyze_site or other alternatives. No prerequisites or exclusions are mentioned.

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

list_sitesA

取り込み済みサイトの一覧を返す。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description bears full responsibility. It states the basic function but lacks details on pagination, ordering, or scope. The behavior is simple enough, but more transparency would help.

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 with no superfluous words. It is front-loaded and efficiently communicates the tool's purpose.

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 simple listing tool with no parameters and an output schema, the description is minimally adequate. However, it could mention ordering or that it returns all imported sites to be more complete.

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, so baseline is 4. The description adds meaning by specifying what is returned, which is sufficient given the absence of parameters.

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 tool returns a list of imported sites. It uses a specific verb ('returns') and resource ('list of imported sites'), distinguishing it from sibling tools like ingest_site (import) and reanalyze_site (reanalyze).

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. It does not specify context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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

reanalyze_siteA

保存済みスナップショットから、ネットワークに触れずコンポーネント・ トークンを作り直す。検出アルゴリズムを改善したときに、サイトを 再取得せずライブラリを更新するための入口。

ParametersJSON Schema
NameRequiredDescriptionDefault
siteYes
min_occurrencesNo

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that no network access is used and that it rebuilds from snapshots, but doesn't discuss destructive behavior, authentication, or error states.

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 extremely concise, composed of two short sentences that immediately convey the core purpose and use case. No wasted words.

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 lack of annotations, output schema, and parameter explanations, the description is insufficient for an agent to use confidently. It covers high-level intent but omits behavioral details and parameter semantics.

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

Parameters1/5

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

Schema description coverage is 0% and the description adds no meaning to the 'site' or 'min_occurrences' parameters. The description does not explain parameter roles, leaving the agent with only schema names and types.

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 that the tool reanalyzes saved snapshots to recreate components/tokens without network access, specifically for updating the library after algorithm improvements. This distinguishes it from ingest_site.

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

Usage Guidelines4/5

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

The description explains when to use (after detection algorithm improvements) and implies not to use when fresh data is needed (use ingest_site instead). However, it lacks explicit when-not-to-use or alternative names.

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

search_componentsA

コンポーネントを検索する。要約のみを返すので、コードは get_component で取る。

ParametersJSON Schema
NameRequiredDescriptionDefault
kindNo
siteNo
limitNo
queryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns only summaries (not full code), which is key behavioral context. However, it does not describe pagination, rate limits, or search semantics (e.g., exact vs fuzzy match), leaving some gaps.

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 two sentences: the first states the core purpose, the second provides practical usage guidance. It is concise with no unnecessary words, well-structured and front-loaded.

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 the tool's complexity (4 optional parameters, no enums, output schema present), the description covers the essential purpose and linking to get_component. It could mention that site filters by site, but the output schema likely documents return values. Overall sufficient for the task.

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

Parameters2/5

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

Schema description coverage is 0%, and the description adds no information about individual parameters (kind, site, limit, query). The agent must rely solely on parameter names, which provide only minimal guidance. The description fails to compensate for the lack of schema descriptions.

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 explicitly states 'Search for components' (verb+resource) and adds that it returns only summaries, distinguishing it from the sibling tool get_component which returns code. This provides clear purpose and differentiation.

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

Usage Guidelines4/5

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

The description advises to use get_component for obtaining full code after searching, giving clear when-to-use direction. It does not explicitly list alternatives or when-not-to-use scenarios, but the sibling context and this guidance make the intended workflow clear.

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.

  1. 7 tool updatesv0.1.0
    • First observedget_component
    • First observedget_design_tokens
    • First observedingest_site
    • First observedlist_sites
    • First observedopen_gallery
    • First observedreanalyze_site
    • First observedsearch_components
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: ingestion (live or snapshot), listing, searching, retrieving components, retrieving tokens, and opening a gallery. No overlaps.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., ingest_site, list_sites, get_component) with appropriate singular/plural forms.

Tool Count5/5

7 tools is well-scoped for the domain of UI component extraction, covering ingestion, listing, searching, retrieval, and gallery viewing without being excessive.

Completeness4/5

The set covers core workflows (ingest, list, search, retrieve, tokens, open gallery). Minor gaps include missing delete/update for sites or components, but these are not essential for the primary extraction purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/Jinshin2534/ui-lift'

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