Skip to main content
Glama

entry_eval_js

Executes custom JavaScript inside the Entry renderer as an async function, returning JSON results. Use it only for advanced cases that other tools cannot handle.

Instructions

고급: 엔트리 렌더러에서 JavaScript를 직접 실행합니다(전역 Entry 객체, window.__entryMcp 헬퍼 사용 가능). async 함수 본문으로 실행되며 return 값이 JSON으로 반환됩니다. 다른 도구로 불가능한 경우에만 사용하세요.

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": {
      "code": "<code>"
    },
    "name": "entry_eval_js"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior3/5

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

No annotations exist, so the description carries full burden. It usefully discloses that code runs as an async function body, that a return value comes back as JSON, and that a global Entry object and window.__entryMcp helper are available. However, it omits side-effect/irreversibility warnings, whether it can mutate project state, and error behavior — significant gaps for an arbitrary-code-execution escape hatch.

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?

Three tight sentences, front-loaded with the "고급" (advanced) caution, then execution semantics, then the usage gate. Little waste; ordering is sensible.

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?

Contextual completeness is only fair given complexity: an eval tool with no output schema and no annotations should ideally cover side effects, error handling, and mutation risks, none of which appear. Return format and execution environment are covered, but the safety profile for arbitrary code is missing.

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 0% for the single `code` parameter, so the description must compensate. It does: it explains that `code` is executed as an async function body and that its return value is serialized to JSON, which meaningfully defines how to supply the parameter. Syntax/concrete examples are still absent, keeping it below 5.

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?

States a specific verb (executes JavaScript) and a specific resource/context (the Entry renderer), plus names the escape-hatch nature ("고급", direct execution). An agent can distinguish this from structured siblings like entry_run or entry_object_op without opening the schema.

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?

Explicitly gates usage: "다른 도구로 불가능한 경우에만 사용하세요" (use only when other tools can't do it). This is clear when-to-use guidance and functions as an exclusion, though it names no concrete alternative tool or prerequisite.

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