entry-offline-mcp

Overview Schema Source Related Servers Discussions Admin

entry_input

Sends ordered keyboard, mouse, text, and wait events to a running Entry project for game testing, then returns optional screenshot and state.

Instructions

실행 중인 작품에 사용자 입력을 보냅니다(게임 테스트용). events를 순서대로 실행. {type:'key', key:'space'|'left'|'a'|..., duration_ms?:누르고 있을 시간(기본 100)} {type:'key_down'|'key_up', key} {type:'click', x, y} (무대 좌표, 오브젝트/마우스 클릭 이벤트 발생) {type:'mouse_move', x, y} {type:'mouse_down'|'mouse_up', x, y} {type:'text', text, submit?:true} (묻고 기다리기 대답 입력) {type:'wait', ms} 마지막에 screenshot/state를 돌려줍니다.

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": {
      "events": "<events>"
    },
    "name": "entry_input"
  }
}

Input Schema

Name	Required	Description	Default
`state`	No
`events`	Yes
`screenshot`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 13, 2026

TDQS

A3.9/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 burden, and it does disclose meaningful behavior: this injects real input into a live runtime (a state-mutating action, not a read), events run sequentially, and the call ends by returning screenshot/state. It falls short on error behavior, timing/settling between events, and what happens if no artwork is running.

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?

Purpose is front-loaded in one short line, followed by a compact per-event reference where every line adds distinct, necessary information, and the return behavior closes it. The dense bracketed event grammar is terse to the point of being slightly hard to parse on first read, but there is no filler.

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?

For a tool with no annotations and no output schema, the description covers the input side thoroughly but does not describe the shape of the returned screenshot/state, what the boolean flags toggle, or failure modes. An agent can construct a call but cannot confidently predict the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the events array is fully unconstrained (untyped objects with additionalProperties), so the description does nearly all the work: it enumerates every event type with required fields, the default 100ms hold for key presses, the stage-coordinate convention for click/mouse events, and the dialog-answer semantics of text submit. Only the top-level state/screenshot booleans are left implicit, recoverable from the closing return-value sentence.

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: sends user input to the currently running artwork, explicitly scoped 'for game testing', and adds that events execute in order. An agent can distinguish this from entry_run (launching) or entry_screenshot (passive capture) without opening the schema, though no sibling is named outright.

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 phrase '실행 중인 작품에' implies the prerequisite that a project must already be running, and '게임 테스트용' implies the testing scenario. However, there is no explicit when-not guidance, no mention of using entry_launch first, and no indication of when a plain entry_screenshot would suffice instead.

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