Skip to main content
Glama
enesjakozh
glifxyz

Glif

Official
by glifxyz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

glif-mcp-服务器

MCP 服务器用于从 glif.app 运行 AI 工作流。

该服务器提供运行 glifs、管理机器人以及通过模型上下文协议 (MCP) 访问 glif 元数据的工具。

该服务器还允许通过添加工具、删除工具等元工具自定义所有可用工具，包括大量完整的 glif 代理，并将其作为一套工具（和个性化）进行自定义。此功能目前处于高度实验阶段。

欲了解更多信息，请访问https://glif.app或加入我们的 Discord 服务器： https://discord.gg/glif

特征

  • 使用输入运行 glifs

  • 获取有关 glifs、运行和用户的详细信息

  • 通过基于 URI 的资源访问 glif 元数据

Related MCP server: mcp-comfyui

设置

通过 npx 运行（推荐）

如果您安装了 nodejs，您可以通过 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 远程运行

要通过Smithery自动为 Claude Desktop 安装 glif-mcp，Smithery 为您托管和运行 MCP 服务器：

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

使用限制

资源

  • glif://{id} - 获取 glif 元数据

  • glifRun://{id} - 获取运行详情

  • glifUser://{id} - 获取用户资料

工具

通用 Glif 工具

  • run_glif - 使用指定的 ID 和输入运行 glif

  • glif_info - 获取有关 glif 的详细信息，包括输入字段

  • list_featured_glifs - 获取精选的 glifs 列表

  • search_glifs - 按名称或描述搜索 glifs

机器人工具

  • list_bots - 获取特色机器人和模拟模板列表

  • load_bot - 获取有关特定机器人的详细信息，包括其技能

  • save_bot_skills_as_tools - 将机器人的所有技能保存为单独的工具

用户特定工具

  • my_glifs - 获取你的 glifs 列表

  • my_glif_user_info - 获取有关您的用户帐户、最近的 glif 和最近运行的详细信息

Glif->工具工具（metatools）

  • save_glif_as_tool - 将 glif 保存为自定义工具

  • remove_glif_tool - 删除已保存的 glif 工具

  • remove_all_glif_tools - 删除所有已保存的 glif 工具并恢复到原始状态

  • list_saved_glif_tools - 列出所有已保存的 glif 工具

如何将 glifs 变成自定义工具

我们有一个通用的run_glif工具，但它 (a) 描述性不够强，并且 (b) 需要先调用glif_info才能了解如何调用该 glif。另外，你还需要知道 glif 的存在。

我们正在试验几种新的元工具，将特定的 glif 转变为新的独立工具：

提示会话示例：

  • 有哪些很酷的新 glif？

  • [工具调用： list_featured_glifs ...]

  • 好的，我喜欢 1970 年代科幻书籍封面生成器，将其制作成一个名为“scifi_book_image”的工具

  • [工具调用： save_glif_as_tool glifId=... toolName=scifi_book_image ]

  • [现在用户只需输入“制作科幻书籍图像即可”]

您可以使用list_saved_glif_tools列出这些特殊工具，并使用remove_glif_tool删除您不喜欢的工具

请注意，Claude Desktop 需要重启才能加载新的工具定义。Cline & Cursor 似乎会在更改后自动重新加载，并重新查询可用的工具。

有关经过身份验证的用户的 glifs 的信息：

  • my_glifs - 当前用户发布的 glifs（无 drats）

  • my_liked_glifs - 当前用户喜欢的 glifs

  • 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 ，你可以在 GitHub 网页界面中手动执行上述操作。

  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