entry-offline-mcp

Overview Schema Source Related Servers Discussions Admin

entry_project

Create, open, save, or rename Entry project files, and export or import raw project JSON for advanced editing.

Instructions

작품 단위 작업. action='new': 새 작품(기본 엔트리봇 포함, empty=true면 오브젝트 모두 제거). 현재 작품은 저장하지 않으면 사라짐. action='open': .ent 파일 열기(path; 상대경로는 작업폴더/projects 기준). action='save': .ent 파일로 저장. path 생략 시 작업폴더/projects/<작품이름>.ent. 상대경로는 작업폴더/projects 기준. name을 주면 작품 이름도 변경. action='rename': 작품 이름 변경(name). action='export_json': 엔트리 원본 project JSON 전체를 반환(고급 편집용, path를 주면 파일로 저장). action='import_json': project JSON(json 문자열 또는 json_path 파일)을 그대로 불러오기.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "entry_project"
  }
}

Input Schema

Name	Required	Description	Default
`json`	No
`name`	No
`path`	No
`empty`	No
`action`	Yes
`json_path`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 13, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations supplied, the description must carry the full behavioral burden, and it does disclose key destructive semantics: action='new' discards the current unsaved project, and empty=true wipes all objects. It also reveals that export_json can write to a file when path is given. However, it says nothing about error conditions, permissions, or what open/save/rename return, so the safety profile is only partially covered.

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?

One header line plus six action bullets, front-loaded with the action keyword so the agent can jump straight to the mode it needs. Every line carries information; the parentheticals add defaults and side effects rather than filler. Slightly dense punctuation-heavy formatting keeps it from a 5.

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?

For a 6-parameter project-lifecycle tool with no output schema, the description covers all parameters, the destructive edge case, and the return nature of export_json. Save/open return values and error behavior are unstated, which is the main residual gap given the absence of annotations and output schema.

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 description coverage is 0%, so the description must compensate and it largely does: path is defined as relative to 작업폴더/projects, empty is explained as removing all objects on new, name is tied to rename and to save-time renaming, json is a project JSON string, and json_path is the file alternative for import. Only action-independent nuances (e.g., path readability scope, json vs json_path precedence) remain implicit.

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 opens with a scope statement ("작품 단위 작업" = project-level operations) and then enumerates all six action values with a concrete verb+resource for each (new/open/save/rename/export_json/import_json). An agent can tell this tool deals with whole-project files rather than scene objects or scripts. It does not explicitly contrast itself with siblings such as entry_get_project or entry_launch, so it stops short of a 5.

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 action-by-action breakdown effectively tells the agent when to pick each mode (create a fresh project vs. open an .ent file vs. dump raw JSON for advanced edits). It also states the default behavior for save (omit path → 작업폴더/projects/<작품이름>.ent) and warns the current project is lost if unsaved before action='new'. There are no explicit "use tool X instead" exclusions, which keeps it at 4.

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