entry-offline-mcp

Overview Schema Source Related Servers Discussions Admin

entry_add_object

Add library sprites or backgrounds, local images, textboxes, or empty objects to an Entry scene, with position, size, name, and properties set during creation.

Instructions

오브젝트 추가. source='library': 라이브러리 스프라이트/배경(asset_id 또는 asset_name; entry_search_assets로 찾기). 배경은 자동으로 맨 뒤+잠금. source='image': 로컬 이미지 파일(image_paths, png/jpg/svg 등; 여러 장이면 모양 여러 개; 상대경로는 작업폴더/images 기준). source='textbox': 글상자(text, props로 fontSize/color/bgColor 등). source='empty': 빈 오브젝트(붓 그리기용 등). props로 위치/크기/이름 등을 바로 지정. scene을 주면 그 장면에 추가(없으면 현재 장면).

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": {
      "source": "<source>"
    },
    "name": "entry_add_object"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`text`	No
`props`	No
`scene`	No
`source`	Yes
`asset_id`	No
`asset_name`	No
`image_paths`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 13, 2026

TDQS

A4/5.0

Behavior4/5

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

No annotations are supplied, so the description carries the full disclosure burden, and it does surface genuinely non-obvious side effects: a background asset is automatically sent to the back and locked, multiple image paths become multiple shapes/costumes, and omitting scene defaults to the current scene. It never says what the call returns (created object id/name) or how failures surface, which matters for a creation tool with no output schema.

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?

One line per source mode, front-loaded with the verb, with no filler sentences. Every clause (auto-background locking, relative path base, default scene) supplies information the agent would otherwise have to guess.

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 four-mode, eight-parameter creation tool with nested props and no output schema, the description covers mode selection, asset lookup routing, default scene resolution and automatic post-creation behavior. The remaining gap is the return contract — an agent does not learn whether the call yields an object identifier it can feed into entry_update_object.

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?

Top-level schema description coverage is 0%, so the description must compensate, and it does explain source, asset_id/asset_name, image_paths (formats, multi-file behavior, relative path base), text, props and scene. However the top-level 'name' parameter is never disambiguated from props.name, and props is only described generically ('위치/크기/이름 등') even though its nested fields carry their own schema descriptions.

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 opening line '오브젝트 추가' plus four explicitly labeled source modes ('library', 'image', 'textbox', 'empty') state a concrete verb and resource, and the mode list makes clear this creates rather than mutates objects (vs. entry_update_object / entry_object_op). It stops short of naming the sibling to use for edits, so the add-vs-update distinction is only implied.

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?

Each source mode is paired with the input it expects and the condition that selects it (e.g. library assets should be located with entry_search_assets first; image mode takes local paths with a defined base directory; textbox mode requires text/props). There are no explicit 'do not use this when...' exclusions or a pointer to entry_update_object for modifying existing objects, which keeps it out of 5 territory.

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