entry_define_function

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

With no annotations, the description has to carry the behavioral load, and it does disclose that this is a define/redefine operation (implying an existing same-named function is overwritten) and explains the resulting runtime contract: how params are referenced via {"type":"param"}, how locals are read/written, how value-functions return, and how the function is invoked with {"type":"call"}. It does not state what define returns, what happens to call sites if a signature changes, or any error behavior on invalid body blocks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence and each subsequent line carries distinct information for a genuinely complex six-parameter tool. The telegraphic, parenthesis-heavy syntax and the trailing Python aside make it slightly harder to scan than it needs to be, but little is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations, no output schema, and zero schema descriptions, the definition covers the authoring model thoroughly enough to construct a valid call. Remaining gaps are response/persistence behavior and the consequences of redefining an existing function, which an agent would want to know before overwriting.

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

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

Schema description coverage is 0% across six parameters, so the description must compensate, and it does: it documents the three accepted shapes for params, the compact-block-array format for body, the meaning of kind='value' tied to return_value, and the local_variables contract. Only 'name' is left implicit, and the call example ('function':'함수이름') makes its role clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line gives a specific verb and resource ('함수(나만의 블록) 정의/재정의') plus the operating mode ('블록 모드용'), so an agent knows this creates or overwrites a custom block. It also names the concrete alternative path (defining a function via entry_set_script's python block), which separates it from that sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The closing parenthetical tells the agent that in Entry Python mode a plain 'def' inside entry_set_script auto-generates a function, which is a real when-to-use-this-instead signal. There is no explicit 'do not use when' clause or note about prerequisites such as needing an open project, so it stops short of a full routing guide.

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