Skip to main content
Glama
enesjakozh
glifxyz

Glif

Official
by glifxyz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

glif-mcp-서버

glif.app에서 AI 워크플로를 실행하기 위한 MCP 서버입니다.

이 서버는 MCP(Model Context Protocol)를 통해 glif를 실행하고, 봇을 관리하고, glif 메타데이터에 액세스하기 위한 도구를 제공합니다.

이 서버는 add-tool, remove-tool 등의 메타 도구를 통해 사용 가능한 모든 도구를 사용자 지정할 수 있도록 허용하며, 여기에는 도구 세트(및 개성)로 제공되는 전체 GLIF 에이전트도 포함됩니다. 이는 매우 실험적인 작업입니다.

자세한 내용은 https://glif.app 에서 확인하거나 Discord 서버에 가입하세요: https://discord.gg/glif

특징

  • 입력을 사용하여 glifs 실행

  • glif, 실행 및 사용자에 대한 자세한 정보를 얻으세요

  • 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 입니다.

    지엑스피1

지역 체크아웃에서 실행

먼저, 이 코드를 체크아웃하고 종속성을 설치합니다.

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(쉼표로 구분)를 지정할 수도 있습니다. 이는 테스트하거나 미리 만들어진 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

사용 제한

  • 사용자 계정과 동일한 제한이 적용됩니다.

  • https://glif.app/pricing 에서 더 많은 크레딧을 구매하세요

자원

  • glif://{id} - glif 메타데이터 가져오기

  • glifRun://{id} - 실행 세부 정보 가져오기

  • glifUser://{id} - 사용자 프로필 가져오기

도구

일반 Glif 도구

  • run_glif - 지정된 ID와 입력으로 glif를 실행합니다.

  • glif_info - 입력 필드를 포함한 glif에 대한 자세한 정보를 가져옵니다.

  • list_featured_glifs - 추천 glif의 큐레이션된 목록을 받으세요

  • search_glifs - 이름이나 설명으로 glif 검색

봇 도구

  • list_bots - 추천 봇 및 시뮬레이션 템플릿 목록을 가져옵니다.

  • load_bot - 특정 봇에 대한 자세한 정보(기술 포함)를 가져옵니다.

  • save_bot_skills_as_tools - 봇의 모든 스킬을 개별 도구로 저장합니다.

사용자별 도구

  • my_glifs - glif 목록 가져오기

  • 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 도구 나열

글리프를 사용자 정의 도구로 전환하는 방법

일반적인 run_glif 도구가 있지만, (a) 설명이 부족하고 (b) 해당 glif를 호출하는 방법을 배우려면 먼저 glif_info 호출해야 합니다. 게다가 glif가 존재한다는 사실도 알아야 합니다.

우리는 특정 글리프를 새로운 독립형 도구로 바꿔주는 몇 가지 새로운 메타 도구를 실험하고 있습니다.

프롬프트 세션의 예:

  • 새로운 멋진 글리프는 뭐야?

  • [도구 호출: list_featured_glifs ...]

  • 좋아, 1970년대 SF 책 표지 생성기를 좋아해요. 그걸 "scifi_book_image"라는 도구로 만들어 주세요.

  • [도구호출: save_glif_as_tool glifId=... toolName=scifi_book_image ]

  • [이제 사용자는 "Blah의 공상과학 책 이미지 만들기"를 입력하기만 하면 됩니다.]

list_saved_glif_tools 사용하여 이러한 특수 도구를 나열하고 remove_glif_tool 사용하여 원하지 않는 도구를 제거할 수 있습니다.

Claude Desktop은 새 도구 정의를 로드하려면 재시작해야 합니다. Cline과 Cursor는 변경 사항이 있을 때 자동으로 다시 로드되고 사용 가능한 도구를 다시 쿼리하는 것 같습니다.

인증된 사용자의 GLIF에 대한 정보:

  • my_glifs - 현재 사용자가 게시한 glif(불필요한 내용 없음)

  • 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가 설치되어 있다면 main 모드로 전환하고 npm run release 실행하세요. 그러면 새 버전의 git 태그가 생성되고, 해당 태그를 github에 푸시한 후 gh release create 사용하여 자동 생성된 변경 로그와 함께 새 버전을 게시할 수 있습니다. gh 설치되어 있지 않다면 GitHub 웹 UI에서 위의 작업을 수동으로 수행할 수 있습니다.

  5. GitHub Action은 NPM_TOKEN 비밀을 사용하여 NPM에 게시합니다.

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

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