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

No annotations are provided, so the description carries the full burden. It discloses that the tool forces a specific pipeline (backup→modify→validate→level.apply→level.save.file), performs auto-rollback on failure, and converts 4-space groups to tabs. However, it does not mention any side effects or authorization requirements.

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?

Two sentences, front-loaded with purpose, and every sentence adds value. No wasted words.

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?

Given the tool has 4 parameters, no output schema, and no nested objects, the description covers the core action, pipeline behavior, and indentation recommendation. It could hint at return values or error handling, but overall it is fairly complete.

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 coverage is 100% with clear descriptions for all 4 parameters. The description adds no additional semantic value beyond what the schema already provides, so baseline score of 3 is appropriate.

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 description clearly states the action: adding a Script/LocalScript/ModuleScript under a parent instance. It uses a specific verb ('추가한다') and resource, distinguishing it from sibling tools like studio_create_part (adds parts) or studio_import_model.

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 description mentions the forced write pipeline and auto-rollback, which provides context, but it does not explicitly state when to use this tool versus alternatives (e.g., studio_apply) or when not to use it.

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

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

The description lacks behavioral details beyond being a write operation. It does not state whether it is destructive, requires specific permissions, or what happens on failure. With no annotations provided, the description should more fully disclose the safety profile and side effects.

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?

The description is two sentences, front-loaded with the core action, and followed by contextual usage. Every sentence is informative without redundancy.

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?

Given the tool's simplicity (no parameters, no output schema), the description adequately conveys purpose, usage context, and behavior when no pending changes. It could mention the return type or error scenarios, but it is largely complete for an action without complex inputs or outputs.

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?

The tool has zero parameters, and schema coverage is 100%, so the baseline is 4. The description does not need to add parameter semantics since there are none.

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 description clearly states the tool applies pending .ovdrjm changes to the live scene, using a specific verb (apply) and resource (pending level changes). It distinguishes from sibling tools like studio_save (which saves) and studio_create_part (which creates parts) by indicating it's part of the write pipeline after editing .ovdrjm files.

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 description provides usage context: typically called right after editing .ovdrjm as part of the write pipeline. It also notes that if there are no pending changes, the tool is a no-op. However, it does not explicitly mention when to use alternatives among sibling tools.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It reveals path validation, auto-rollback on failure, and capability errors for unsupported operations. However, it does not mention the effect on the existing instance (e.g., overwrite or merge) or the success response format, which slightly reduces transparency.

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?

The description is three concise sentences with no fluff. It front-loads the primary action and follows with necessary constraints and edge-case behavior. Every sentence adds value, making it efficient for an agent to parse.

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 simple two-parameter tool without output schema, the description covers purpose, constraints, and failure behavior. However, it omits details about what the tool returns (e.g., success indicator) and does not reference sibling tools, leaving some context gaps.

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?

The input schema already provides 100% description coverage for both parameters. The description adds only a minor repetition of the path constraint and failure context, offering no additional semantic value beyond what the schema states. Thus, baseline score of 3 is appropriate.

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 description clearly states the tool applies a sequencer JSON file to an existing ActionSequencer instance, specifying the required parameters and constraints like path validation. It effectively distinguishes the tool from siblings like 'studio_apply' by detailing the specific operation and failure behaviors.

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 description does not provide guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. While it mentions failure behavior, it lacks comparative context with sibling tools, leaving the agent without usage boundaries.

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

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

No annotations provided, so description carries full burden. It discloses output structure (nodes with guid/name/class/children) and implies read-only behavior via '조회' (query). Could be more explicit about read-only nature, but sufficient.

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?

Single, well-structured sentence with no fluff. Every element earns its place: purpose, parameters, and output structure.

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?

No output schema; description explains node structure adequately. Lacks details on pagination, error conditions, or prerequisites. With no annotations, could be more complete for a tool returning tree data.

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 coverage is 100%, and description adds context: clarifies maxDepth limit, classType filtering, and startGuid usage. Adds value beyond schema definitions.

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 description clearly states the tool browses the OVERDARE Studio level instance tree, a specific resource. It distinguishes itself from siblings like studio_add_script, studio_delete, etc., which are clearly different actions.

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?

Provides some guidance (e.g., maxDepth=1 for top-level only), but does not explicitly state when to use or not use this tool versus alternatives. Since no sibling is similar, this is acceptable but not fully explicit.

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

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

The description discloses caching after initial probe, the refresh parameter to force re-probe, and error handling for unsupported calls. It lacks an explicit statement that the tool is read-only, but this is strongly implied. No annotations are present, so the description carries full burden.

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?

The description is three sentences, front-loaded with the main purpose, and each sentence adds essential information (purpose, caching, refresh, error handling). No wasted words.

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?

Given a simple tool with one parameter and no output schema, the description covers purpose, caching, refresh, and error handling. It does not specify the return format beyond 'capability and version,' but this is a minor omission. The sibling tools provide clear context.

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?

The input schema has 100% coverage with a clear description of the 'refresh' parameter. The tool description does not add new parameter-specific meaning beyond the schema; it only restates the refresh behavior in context. Baseline 3 is appropriate.

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 description clearly states the tool reports Studio RPC feature support (capability) and version, which is a specific verb+resource. It is well-distinguished from sibling tools that perform actions like scripts, apply, browse, etc.

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 description implies the tool should be used to check capabilities before calling other tools, mentioning that unsupported features return capability errors. However, it does not explicitly state when to use this versus alternatives, though the context is clear given sibling tool names.

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

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

Since no annotations are provided, the description carries full burden. It discloses the forced write pipeline (backup→modify→validate→level.apply→level.save.file) and automatic rollback on failure, which is highly transparent.

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?

The description is moderately concise with front-loaded action and behavioral info, followed by properties list. It could be more structured but is efficient.

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?

Covers purpose, prerequisites, behavioral pipeline, and properties. Missing return value info (e.g., created part GUID) since there is no output schema. Otherwise fairly complete.

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 coverage is 100%, but the description adds value: it clarifies that Position is specified via CFrame.Position and that Size units are in cm. This provides useful context beyond the schema.

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 description clearly states the tool creates a Part under a parent instance (parentGuid). It lists key properties like Size, CFrame, Color, Material, Anchored, etc., distinguishing it from sibling tools like studio_update_part which modifies existing parts.

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 description provides a prerequisite: use studio_browse to verify parentGuid first. It implies when to use this tool (create) vs updates (studio_update_part). However, it does not explicitly state when not to use it.

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

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

No annotations provided, but description fully discloses: recursive deletion, enforced write pipeline with auto rollback on failure, and restrictions on deletable objects. All behavioral traits beyond schema are covered.

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?

Three concise sentences, each critical. First states core purpose, second details behavioral contract, third adds usage constraint and aid. No redundant words.

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?

Single parameter, no output schema. Description fully addresses all necessary information: scope of deletion, procedural behavior, restrictions, and prerequisite step for obtaining input.

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 coverage is 100% with description for 'guid'. Description adds value by instructing to use studio_browse to acquire guid, which is helpful for agent.

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?

Describes specific action: delete instance including children (subtree). Distinguishes from siblings by stating it's deletion, not adding/browsing. Explicitly lists excluded objects (services). References how to obtain guid via sibling tool.

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?

Provides explicit when-not-to-use: cannot delete service singletons. Implies context for deletion with force and rollback. Does not explicitly list alternatives but guidance is clear.

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

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

No annotations provided, so description must disclose behavior. It covers path restrictions, supported formats, and error conditions but does not mention whether the operation is destructive (e.g., overwrites existing assets), required permissions, or rate limits. For a simple import, this is adequate but lacks depth.

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?

Two sentences, front-loaded with main purpose, followed by constraints. Every sentence adds essential information. No fluff, well-structured.

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 one-parameter tool with no output schema, the description is fairly complete: covers what it does, valid inputs, error behavior. Could mention if it overwrites existing assets or requires specific permissions, but not critical for basic usage.

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 coverage is 100% with a single parameter 'file' described. Description adds value beyond schema by detailing path constraints (OVERDARE_ASSET_ROOTS) and supported extensions, which are not in the schema. Error condition for unsupported formats also aids agent invocation.

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?

Description clearly states it imports a local image file to the asset manager and returns an asset ID. Verb 'import' and resource 'local image asset' are specific. Easily distinguishable from sibling tool 'studio_import_model' which imports models.

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?

Provides explicit constraints on allowed paths (project boundaries or OVERDARE_ASSET_ROOTS) and lists supported image extensions. Also mentions capability error for unsupported formats. Lacks explicit when-not-to-use or alternatives, but contextual guidance is sufficient.

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

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

With no annotations provided, the description carries the full burden. It discloses three important traits: hierarchy preservation, automatic rollback on failure, and capability error reporting. This is strong for a tool without annotations, though it does not address outcomes like overwriting or duplicate handling.

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?

The description is concise, using three clear statements. It front-loads the primary purpose and contains no fluff. Every sentence adds necessary information.

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?

The description covers core function, inputs, and error scenarios, but does not specify the output or result of a successful import (e.g., returns a reference). Given the lack of output schema and annotations, this is a notable gap for an effective invocation.

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 coverage is 67%. The description adds clarity for the `assetid` format (matching the pattern) but does not elaborate on `assetName` or `assetType`, which are already described in the schema. Overall, the description contributes modestly beyond the schema.

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 description clearly states the action (import), the source (Asset Drawer), the target (level), and a key behavioral detail (hierarchy preserved). It differentiates from sibling `studio_import_image` by specifying 'model'.

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 description provides prerequisites (assetid format, assetName) and behavioral context (rollback, capability error), but lacks explicit guidance on when to use this tool versus alternatives such as `studio_create_part` or `studio_import_image`. The agent must infer based on the tool name and sibling context.

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

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

With no annotations, description fully discloses irreversible nature, external disclosure, and the conditional logic (dry-run default, RPC call only under specific conditions).

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?

Two sentences, front-loaded with purpose, uses bold for emphasis. No unnecessary words; every sentence adds value.

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?

Given no output schema, description covers the essential logic and conditions. Lacks details on return values or error states, but those are secondary for a publish action.

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 coverage is high (83%), so baseline is 3. Description adds value by explaining the interplay between dryRun, confirm, and environment variable, which goes beyond schema descriptions.

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?

Clearly states the tool publishes a world to the OVERDARE platform, irreversible and external. Distinct from sibling tools like studio_save or studio_delete.

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?

Provides explicit conditions for actual publish vs dry-run, including environment variable and parameter requirements. Does not explicitly mention when to use alternatives, but context is clear.

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

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

With no annotations, the description is the sole source of behavioral info. It discloses that the tool updates two file types, which is useful. However, it does not mention side effects (e.g., overwriting files), required permissions, or the return behavior.

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?

The description is extremely concise—two short sentences that immediately convey the action and affected file types. No unnecessary words.

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 parameterless save tool, the description covers the essential information: what is saved and what files are updated. It could be more complete by mentioning whether the save is automatic or requires a filename, but given the simplicity, it is largely sufficient.

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?

Since there are no parameters, schema coverage is 100% vacuously. The description adds meaning by explaining the tool's core action, but it does not need to describe parameter semantics. A score of 3 reflects the baseline for high schema coverage with no parameter info needed.

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?

Description clearly states the verb ('saves') and resource ('world being edited'), explicitly mentioning the file types updated (.umap and .ovdrjm). No sibling tool has a similar purpose, so it is easily distinguished.

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?

No guidance on when to use this tool versus alternatives (e.g., studio_publish). The description only explains what the tool does, not the context or prerequisites for using it.

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

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

The description discloses two behavioral traits: only Viewport mode supported and potentially slow response requiring a longer timeout. However, it lacks details on error handling, file storage, or overwrite behavior, which would be expected given no annotations.

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?

The description is concise at two sentences, front-loads the primary action, and adds necessary constraints and performance notes without extraneous information.

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?

The description covers the core functionality and key constraints, but lacks details about output (e.g., file path/name) and error scenarios. Given the tool's simplicity, this is adequate but not fully comprehensive.

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?

The input schema has no parameters, so no additional parameter documentation is needed. The description provides useful context beyond the schema, such as the RPC call and timeout hint, meeting the baseline for zero-parameter tools.

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 description clearly states the tool captures a viewport screenshot and saves it as a file, using a specific RPC and capture type. No sibling tool performs screenshotting, so it effectively distinguishes itself.

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 description implies usage for viewport screenshots and notes a mode limitation, but does not explicitly state when to use this tool versus alternatives or when not to use it.

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

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

No annotations provided; the description fully discloses the write pipeline (backup→modify→validate→level.apply→level.save.file), auto rollback on failure, partial update behavior, and property types. This is highly informative for an agent.

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?

The description is concise with 4-5 sentences, each adding distinct value. It is front-loaded with the core action and efficiently covers purpose, pipeline, partial update, and property examples.

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?

Given no output schema, the description omits what the tool returns (e.g., success/updated object). While it covers pipeline, partial update, and property scope, the missing output information slightly reduces completeness.

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 coverage is 100%, so baseline is 3. The description adds meaning by listing example properties (Size, CFrame, etc.) and clarifying that guid comes from studio_browse, which aids selection beyond the schema.

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 description clearly states it modifies the name/properties of an existing part, with specific verb and resource. It distinguishes from sibling tools like studio_create_part and studio_delete by focusing on updating existing parts.

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 description provides context by linking guid to studio_browse and explaining partial update behavior. However, it does not explicitly contrast with alternatives like studio_create_part or studio_delete for creation/deletion scenarios.

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