Skip to main content
Glama

entry_launch

Launches Entry offline app with remote debugging port, connecting if possible; requires restart option if running without debug port (warns of forced close). Handles recovery dialog.

Instructions

Entry 오프라인 앱을 원격 디버깅 포트로 실행하고 연결합니다. 이미 연결 가능하면 그대로 연결합니다. Entry가 디버그 포트 없이 실행 중이면 restart=true가 필요합니다(앱 강제 종료 → 저장 안 된 작업 손실 가능, 사용자 확인 후 사용). 시작 시 "작품 복구" 대화상자가 뜨면 recovery 옵션으로 처리합니다.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "entry_launch"
  }
}

Input Schema

NameRequiredDescriptionDefault
restartNo실행 중인 Entry를 강제 종료 후 디버그 모드로 재실행
recoveryNo시작 시 '작품 복구' 대화상자 처리: ask(그대로 두고 보고), restore(복구=확인), discard(취소). 기본 ask
open_fileNo실행하면서 열 .ent 파일 경로

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the load and does well: it warns that restart force-quits the app, can lose unsaved work, and should only be used after user confirmation. It also explains the recovery dialog states. It does not say what happens on failure or whether the call is idempotent.

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?

Four short sentences, front-loaded with the primary action and then the restart and recovery conditions. No filler; each sentence carries a distinct condition.

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?

Covers the launch path, the already-connected path, the restart prerequisite with its risk, and the recovery dialog. Missing only the outcome of the call (connection success/failure reporting), which matters since there is no output schema.

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 coverage is 100%, so the schema already documents restart, recovery, and open_file in detail. The description reinforces when restart is required and how recovery interacts with the startup dialog, but adds no format or default information beyond the schema.

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?

States a specific verb and resource: launching the Entry offline app with a remote debugging port and connecting to it. The scope is clear enough to separate it from siblings like entry_status or entry_run, though no sibling is named explicitly.

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?

Gives concrete selection logic: if a connection is already available, just connect; if Entry is running without a debug port, set restart=true. It does not point at alternative tools (e.g. entry_status to check state first), which keeps it just short of a 5.

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