Skip to main content
Glama
enesjakozh
glifxyz

Glif

Official
by glifxyz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

glif-mcp-server

glif.app から AI ワークフローを実行するための MCP サーバー。

このサーバーは、Glif の実行、ボットの管理、モデル コンテキスト プロトコル (MCP) を介した Glif メタデータへのアクセスを行うためのツールを提供します。

このサーバーでは、ツールの追加、ツールの削除などのメタツールを介して利用可能なすべてのツールをカスタマイズできます。これには、ツールセット（およびパーソナリティ）として提供される多くの完全なGlifエージェントも含まれます。これは非常に実験的なものです。

詳細については、 https://glif.appをご覧いただくか、Discord サーバーにご参加ください: https://discord.gg/glif

特徴

  • 入力してGLIFSを実行する

  • グリフ、実行、ユーザーに関する詳細情報を取得します

  • URIベースのリソースを通じてglifメタデータにアクセスする

Related MCP server: mcp-comfyui

設定

npx 経由で実行 (推奨)

Node.js がインストールされている場合は、npx 経由で@glifxyz/glif-mcp-serverパッケージを実行できます。

  1. https://glif.app/settings/api-tokensから API トークンを取得します。

  2. Claude Desktopの設定ファイルにサーバーを追加してください。macOSの場合、これは次の場所にあります: ~/Library/Application Support/Claude/claude_desktop_config.json

    {
  "mcpServers": {
    "glif": {
      "command": "npx",
      "args": ["-y", "@glifxyz/glif-mcp-server@latest"],
      "env": {
        "GLIF_API_TOKEN": "your-token-here"
      }
    }
  }
}

地元のレジから実行する

まず、このコードをチェックアウトして依存関係をインストールします。

git clone https://github.com/glifxyz/glif-mcp-server
cd glif-mcp-server
npm install
npm run build
# there's now a build/index.js file which is what we'll run next

次に、このサーバーをディスクからロードするように MCP クライアント (例: Claude Desktop) を構成します。

{
  "mcpServers": {
    "glif": {
      "command": "node",
      "args": ["/path/to/glif-mcp/build/index.js"],
      "env": {
        "GLIF_API_TOKEN": "your-token-here"
      }
    }
  }
}

glifs ID（カンマ区切り）を指定することもできます。これらのIDはサーバーの起動時に自動的に読み込まれます。これはテストや、事前に作成したglif設定を他のユーザーと共有したい場合に便利です。

{
  "mcpServers": {
    "glif": {
      "command": "node",
      "args": ["/path/to/glif-mcp/build/index.js"],
      "env": {
        "GLIF_API_TOKEN": "your-token-here",
        "GLIF_IDS": "cm2v9aiga00008vfqdiximl2m,cm2v98jk6000r11afslqvooil,cm2v9rp66000bat9wr606qq6o",
        "IGNORE_SAVED_GLIFS": true,
      }
    }
  }
}

Smitheryでリモート実行

MCP サーバーをホストして実行するSmithery経由で、Claude Desktop 用の glif-mcp を自動的にインストールするには、次の手順を実行します。

npx -y @smithery/cli install @glifxyz/glif-mcp-server --client claude

使用制限

  • ユーザーアカウントと同じ制限が適用されます

  • https://glif.app/pricingで追加のクレジットを購入してください

リソース

  • glif://{id} - glf メタデータを取得します

  • glifRun://{id} - 実行の詳細を取得する

  • glifUser://{id} - ユーザープロファイルを取得する

ツール

一般的なGlifツール

  • run_glif - 指定されたIDと入力でglifを実行する

  • glif_info - 入力フィールドを含む glif の詳細情報を取得します

  • list_featured_glifs - 注目のグリフの厳選リストを取得します

  • search_glifs - 名前または説明でグリフを検索します

ボットツール

  • list_bots - 注目のボットとシムテンプレートのリストを取得します

  • load_bot - 特定のボットのスキルを含む詳細情報を取得します

  • save_bot_skills_as_tools - ボットのすべてのスキルを個別のツールとして保存します

ユーザー固有のツール

  • my_glifs - グリフのリストを取得する

  • my_glif_user_info - ユーザーアカウント、最近のglif、最近の実行に関する詳細情報を取得します

Glif->ツールツール（メタツール）

  • save_glif_as_tool - glif をカスタムツールとして保存する

  • remove_glif_tool - 保存したglifツールを削除する

  • remove_all_glif_tools - 保存されているすべての glif ツールを削除し、元の状態に戻します。

  • list_saved_glif_tools - 保存されているすべての glif ツールを一覧表示します

グリフをカスタムツールに変える方法

汎用的なrun_glifツールはありますが、(a)あまり説明的ではなく、(b)glifの呼び出し方法を知るためにまずglif_info呼び出す必要があります。さらに、glifが存在することさえ知っておく必要があります。

私たちは、特定のグリフを新しいスタンドアロン ツールに変えるいくつかの新しいメタ ツールを試しています。

プロンプトセッションの例:

  • 新しいクールな GIF は何ですか?

  • [ツールコール: list_featured_glifs ...]

  • 1970年代のSF本の表紙ジェネレーターが気に入ったので、「scifi_book_image」というツールを作成します

  • [ツールコール: save_glif_as_tool glifId=... toolName=scifi_book_image ]

  • [これでユーザーは「何とかのSF本のイメージを作る」と入力するだけで済みます]

これらの特別なツールはlist_saved_glif_toolsでリストでき、不要なものはremove_glif_toolで削除できます。

Claude Desktopでは、新しいツール定義を読み込むために再起動が必要です。ClineとCursorは変更時に自動的に再読み込みされ、利用可能なツールを再クエリするようです。

認証されたユーザーのグリフに関する情報:

  • my_glifs - 現在のユーザーが公開した glifs (drats なし)

  • my_liked_glifs - 現在のユーザーが「いいね！」した glif

  • my_runs - 現在のユーザーの公開実行

MCPレジストリ

鍛冶屋のバッジ

発達

依存関係をインストールします:

npm install

サーバーを構築します。

npm run build

自動リビルドを使用した開発の場合:

npm run dev

テスト スイートを実行するには:

npm run test

変更に対するテストを継続的に実行するには:

npm run test:watch

デバッグ

MCPサーバーはstdio経由で通信するため、デバッグが困難になる場合があります。MCP Inspectorの使用をお勧めします。

npm run inspector

インスペクターは、ブラウザでデバッグ ツールにアクセスするための URL を提供します。

Claude Desktop を使用している場合は、Claude ログ ダイレクト内の glif-mcp ログを確認することもできます。

新バージョンのリリース

  1. package.jsonとsrc/index.tsを編集してバージョン番号を上げる

  2. npm install実行して、ロックファイルに保存されているバージョンを更新します。

  3. 変更をGitHubにコミットしてプッシュし、メインにマージします

  4. ghがインストールされている場合は、メインに切り替えてnpm run releaseを実行してください。これにより、新しいバージョンの git タグが作成され、そのタグが github にプッシュされます。その後gh release create 、自動生成された変更ログを含む新しいバージョンを公開します。gh ghインストールされていない場合は、GitHub の Web UI で上記の手順を手動で実行できます。

  5. GitHub ActionはNPM_TOKENシークレットを使用してNPMに公開します。

ライセンス

このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。

Available Tools

6 tools
my_user_infoA
Read-only
Inspect

Get detailed information about your Glif account, including profile info, recent workflows, and recent runs.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, confirming no side effects. The description adds value by specifying returned data categories (profile, workflows, runs), going beyond the annotation. No contradictions.

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, front-loaded sentence that efficiently communicates purpose and key return categories. No wasted words.

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 zero parameters and a simple read-only operation, the description adequately covers what the tool returns (profile, workflows, runs). No output schema, but the listing of categories provides sufficient context for an 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 in input schema (100% coverage by schema). Baseline is 4; description does not need to add parameter details. No additional semantics required.

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's purpose: retrieving detailed account info including profile, recent workflows, and recent runs. It distinguishes itself from siblings like my_workflows (which likely focuses on workflows alone) and search_workflows.

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 for getting the current user's account details, but lacks explicit guidance on when to use versus siblings (e.g., when to use my_workflows instead for workflow-only data). No when-not or alternative suggestions.

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

my_workflowsA
Read-only
Inspect

Get a list of your published workflows (glifs). Shows your AI workflows with run counts and creation dates.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

Annotations include readOnlyHint=true, which is consistent with the description. The description adds minor behavioral context (what data is shown) but does not cover potential issues like pagination or rate limits. No contradiction with annotations.

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?

Two concise sentences with no fluff. The purpose is front-loaded, and the second sentence adds relevant details. Every word earns its place.

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 no parameters and no output schema, the description adequately explains what the tool returns. It could mention pagination or ordering but is largely sufficient for a simple list tool.

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 no parameters, so schema coverage is 100%. The description adds value by clarifying that the list is scoped to the user's own workflows, which is not evident from 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 the verb 'get a list', the resource 'your published workflows (glifs)', and specific details like 'run counts and creation dates'. It distinguishes from sibling tools such as list_featured_workflows and search_workflows.

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 for personal workflows but does not explicitly state when to use this tool over alternatives like list_featured_workflows or search_workflows. No when-not or alternative naming is provided.

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

run_workflowAInspect

Run a workflow (glif) with the specified ID and inputs. Workflows can generate images, text, audio, and more. Inputs can include text, URLs, or base64-encoded media.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe ID of the workflow (glif) to run
inputsYesArray of input values. Can be text, media URLs, or base64-encoded media (data:image/png;base64,... or data:image/jpeg;base64,...)

TDQS

A3.9/5.0
Behavior3/5

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

Annotations indicate non-read-only and non-destructive behavior. The description adds that it generates media but does not disclose potential side effects, idempotency, or reliability characteristics.

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 concise with two sentences, front-loading purpose and adding relevant context about output types and input formats without redundancy.

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?

The description mentions potential output types but lacks details on return values, as there is no output schema. It also omits guidance on error handling or post-invocation steps, leaving gaps for an 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?

The input schema covers both parameters, and the description adds value by specifying acceptable input formats (text, URLs, base64-encoded media) beyond the array-of-strings type, aiding correct usage.

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 'Run' and the resource 'workflow (glif)', specifying that workflows generate various outputs. This distinguishes it from sibling tools like list_featured_workflows and search_workflows.

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 by stating its function but does not provide explicit guidance on when to use it versus alternatives. It lacks exclusion criteria or context about prerequisites.

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

search_workflowsA
Read-only
Inspect

Search for workflows (glifs) by name, description, or keywords. Find AI tools for image generation, text processing, and more.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query string

TDQS

A3.8/5.0
Behavior3/5

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

Annotations include readOnlyHint: true, which is consistent. The description adds that it searches by name, description, or keywords, but no additional behavioral details beyond what annotations provide.

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?

Two sentences, front-loaded with purpose, no unnecessary words. Efficient and clear.

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 simple tool (one parameter, no output schema), the description adequately covers what it does and the types of results it returns. Could mention return format but not critical.

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?

Schema coverage is 100% with one parameter. The description adds context that the query can be by name, description, or keywords, which adds meaning beyond the schema's 'Search query string'.

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 tool name and description clearly state the action (search) and resource (workflows/glifs). It distinguishes from sibling tools like list_featured_workflows by implying a general search across all workflows.

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 like list_featured_workflows or my_workflows. No context on when to search vs list.

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

workflow_infoA
Read-only
Inspect

Get detailed information about a workflow (glif) including its input fields, recent runs, and creator info.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe ID of the workflow (glif) to show details for

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already indicate read-only (readOnlyHint: true). The description adds valuable detail about the return content (input fields, recent runs, creator info), making behavior transparent beyond the annotation.

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 that is concise, front-loaded with the action, and contains no extraneous words.

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

Completeness5/5

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

Given the tool's simplicity (one parameter, no output schema), the description provides sufficient context—what the tool does and what it returns—making it 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 covers the single parameter 'id' fully (100% coverage). The description does not add additional meaning about the parameter beyond the schema, leading to baseline score.

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 it retrieves detailed information about a specific workflow, including inputs, runs, and creator. It distinguishes from siblings like list_featured_workflows (list) and run_workflow (execute), but does not explicitly contrast with alternatives.

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 siblings such as search_workflows or my_workflows. The description only explains the tool's function without providing use-case context.

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.

  1. 6 tool updatesv0.9.5
    • First observedlist_featured_workflows
    • First observedmy_user_info
    • First observedmy_workflows
    • First observedrun_workflow
    • First observedsearch_workflows
    • First observedworkflow_info
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: listing featured workflows, user info, personal workflows, running a workflow, searching workflows, and workflow details. No overlap or ambiguity.

Naming Consistency3/5

Naming patterns are mixed: some use verb+noun (list_featured_workflows, run_workflow, search_workflows), some use possessive+noun (my_user_info, my_workflows), and one uses noun+noun (workflow_info). This inconsistency could confuse an agent.

Tool Count5/5

6 tools is well-scoped for a workflow platform, covering essential operations without being overwhelming or too sparse.

Completeness3/5

Missing CRUD operations for workflows (create, update, delete), which are important for managing workflows. The set focuses on consumption and view only, leaving gaps for workflow creation and management.

Maintenance

ActivityStale
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches