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

With no annotations, the description carries the full burden, and it delivers: connection semantics, insert value limits, cache refresh via change, lock release on failure, admin visibility of new nodes, tree index rebuilding, and dependent sweeping behavior. It even warns about announcing data changes to the owner and keeping locks short.

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 dense and every sentence carries useful information, but it is a long single block that could be better organized with step categories or formatting. Still, nothing is filler, and the core purpose is front-loaded.

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?

It is remarkably complete for a complex tool: step types, parameter binding, failure behavior, locking, dependent handling, and pool_file are all covered. The main gaps are the exact JSON shape of each step object and the overall success return value, since no output schema exists.

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 schema only defines pool as an array of objects and pool_file as a string. The description adds real meaning: pool is a list of named steps, values are bound via :NAME and @name, pool_file holds the same step list as a JSON file, and it details the step vocabulary with their arguments.

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 names a specific verb and resource: it runs a pool of steps in one database connection. It enumerates the step types and distinguishes the tool from simple DB operations like engine_db_select, making its scope unmistakable.

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?

It gives explicit when-to-use guidance: this is the only way temporary tables or LAST_INSERT_ID survive between steps. It also tells the agent when not to use raw SQL (tree shaping), what to do before deletions (dependent), after deletions (clear_dependent), and how to handle large pools (pool_file).

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 are provided, so the description carries the burden. It goes beyond the tool name by explaining the meaning of MELBIS_SYSTEM lock sources and warning that a held table is actively being modified. It does not explicitly state that the tool is read-only, but the inspection semantics are strongly implied.

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 sentences front-load the purpose, then provide a dense but relevant interpretation of lock source values, and close with actionable guidance. It is longer than a minimal description but every sentence contributes useful meaning.

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 inspection tool with no output schema, the description fully explains what is returned, how to interpret ambiguous values, and when to use the tool. Nothing essential is missing for an agent to call it correctly.

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 zero parameters and 100% coverage, so the baseline of 4 applies. The description does not need to add parameter semantics because there is nothing to parameterize.

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 first sentence identifies the exact resource ('tables currently taken into work') and the output fields (holder, operation, since when). This clearly separates it from sibling tools like engine_db_tables and engine_db_unlocks.

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 explicitly says to check this before working with table data, including reads, and explains why: held tables are being changed. It gives clear usage context but does not name alternative tools or exclusion cases, so it stops short of a 5.

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 the full burden, and it is exceptionally transparent: rows are returned whole with no truncation, steps over 5000 rows are refused unless marked big:true, file steps redirect output to a file, and the mcp/melbis folder is wiped without warning. It also explicitly says the tool only reads, which is critical safety information 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 extremely dense and front-loaded with 'Read data', but it is a single run-on paragraph with semicolons and colons that make it hard to scan. All sentences carry useful information, so it is not padded, but bullet points or shorter sentences would significantly improve readability.

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 tool with two params and no output schema, the description covers nearly everything needed: input format, value binding, row limits, file output behavior, dependent steps, and the pool_file alternative. Exact response shape and the precise required combination of pool vs pool_file are not stated explicitly, but the practical invocation path is well covered.

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 only 50% and the pool parameter has no schema description, but the tool description thoroughly compensates: it defines pool step structure, the `:NAME` placeholder binding convention, table-name conventions, optional big/file flags, and clarifies that pool_file contains the same list of steps. This is far more actionable than the bare 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 opens with 'Read data' and immediately defines pool as a list of `{"do":"select","sql":"..."}` steps, making it clear this is a database read tool. It distinguishes itself from write/execute siblings by stating 'It only reads, so it belongs here as much as a select.' However, it does not crisply state 'select database rows' as the primary purpose, and huge amount of surrounding detail makes the core purpose less immediate.

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 gives clear usage context: dependent-step queries belong in this read-only command, and pool_file should be used when the pool is too large to write inline. It also warns against placing file outputs under mcp/melbis because it is wiped without warning. It does not explicitly name engine_db_execute or other alternatives, but the read-only positioning is enough to route agents reasonably.

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 the full burden. It explains behavior like accepting real or bare names, returning a list when name is omitted, and interpreting 'gen' lines. It does not explicitly state that the tool is read-only or describe side effects, though the context suggests it is a metadata read. Some behavioral detail is provided, but not exhaustive.

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?

Four short sentences, each adding useful information: output content, name optionality, name formats, and output interpretation. No fluff, though the structure is a bit fragmented and the first sentence lacks a verb.

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 output and name semantics, but leaves the reload parameter undefined and does not clarify return structure or error behavior. Since there is no output schema or annotations, this gap makes the description adequate but not 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?

The name parameter is well explained: it accepts real or bare names, and omitting it returns a table list. The reload parameter is completely unexplained despite 0% schema description coverage, so the description only partially compensates for the schema gap.

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 what the tool provides: columns, keys, and storage engine of a table, or the list of tables when no name is given. This distinguishes it from sibling tools like engine_db_select and engine_db_execute, which handle data operations. Lack of an explicit verb ('shows', 'returns') is a minor detraction.

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 scenarios: inspect table metadata before an INSERT (gen line) or list tables when no name is provided. However, it never explicitly names alternatives or states when not to use this tool, so the agent must infer the context from sibling 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?

No annotations are provided, so the description carries the full burden. It discloses the destructive scope (releases only own locks, not others'), the conditionality (only locks outside an operation), and the parameter-dependent behavior. It also warns about the risk of releasing locks from still-running calls. It doesn't explicitly state whether the operation is reversible or what the response looks like, but the safety-relevant behavior is well 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?

The description is compact and front-loaded with the core action. Every sentence adds value: scope, exclusions, parameter behavior, and a safety warning. The phrasing is slightly informal ('what a tool of the store took and died before letting go') but not wasteful. It earns its length.

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 tool with one optional parameter and no output schema, the description covers the essential context: what it releases, what it doesn't, how the parameter changes behavior, and a safety check. It doesn't describe return values or error cases, but those are less critical given the simple input and the strong behavioral disclosure.

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%, so the description must compensate. It does: it explains the 'tables' parameter's effect (without tables, all stuck rows; with them, only named ones). It doesn't provide exact format or examples, but the meaning is clear. Given the single optional parameter, this is strong compensation.

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 identifies the tool's purpose: releasing locks left behind by the current user's own dead operations. It specifies the resource (oper_block rows), the condition (own login, outside any operation), and explicitly distinguishes what it does NOT release (storefront locks, others' locks, open form locks). This is a specific verb+resource with clear scope.

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 explicit guidance: 'Look at engine_db_locks first' and explains why (a table taken a second ago may belong to a call still running). It also explains the optional 'tables' parameter behavior: without tables, all stuck rows go; with tables, only named ones. This is strong when-to-use and when-not-to-use guidance.

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 the full burden of behavioral disclosure. It states the action but does not describe side effects (e.g., impact on active sessions, performance, or whether clearing is permanent). It mentions scoping but not what happens if 'unit' is omitted for unit_* types. Lacks depth on consequences.

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 with no redundancy. It front-loads the list of cache levels, then provides usage context. Every word earns its place, and the structure is clear and scannable.

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, the description covers the main usage but omits return value/behavior (e.g., success confirmation) and does not clarify if 'unit' is mandatory for unit_* levels. Given no annotations or output schema, these gaps could hinder correct invocation. It is adequate but not fully 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 0%, so the description must compensate. It enumerates all valid values for 'type' and explains that 'unit' scopes unit_* levels, adding meaning beyond the bare schema. However, it does not specify whether 'unit' is required for unit_* types or how it interacts with non-unit types, leaving some ambiguity.

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 verb 'Clear' and the resource 'cache level', listing exact valid levels (cache, trick, smart, static, unit_cache, etc.). It uniquely identifies the tool's function, distinct from sibling load/save tools. Even without explicit sibling comparison, the purpose is unambiguous.

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 explicit guidance on when to use this tool: 'this is for the manual and the wholesale clears', contrasting with automatic cache drops on module/library save. It also explains the role of the 'unit' parameter for scoping unit_* levels, helping the agent decide when to specify 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 are provided, so the description carries the burden. It discloses that secret values return as <hidden>, which is a useful behavioral trait. However, it says nothing about side effects, permissions, or whether the 'reload' parameter triggers an action, leaving much undisclosed.

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 brief at two sentences with no waste, which is good. However, the front-loaded sentence is vague, and the structure does not prioritize the most essential information (tool action) before secondary hints.

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?

With no annotations, no output schema, and a single optional parameter, the description is far too thin. It provides a hint about secrets but fails to explain the tool's core purpose, the reload parameter, or any return behavior, leaving agents guessing.

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 0% and the description does not explain the 'reload' boolean parameter at all. It mentions 'Parameters of config.json' generically but never clarifies what the parameter does or how to use it, so no meaning is added 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 states 'Parameters of config.json' but lacks an explicit verb or action (e.g., get, set, reload). It identifies the resource but not what the tool does with it. Compared to sibling tools with clear verbs like 'load' and 'save', this is ambiguous.

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?

There is no guidance on when to use this tool versus alternatives. No conditions, prerequisites, or exclusions are mentioned. The only note about secrets is a behavioral hint, not usage direction.

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 the full behavioral burden. It discloses useful details: kind_key defaults to kBase and is checked against the key_value registry, and the engine automatically fills id, name, folder, and row. However, it omits side effects, return values, error behavior, and any authorization or validation 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?

The description is compact and front-loaded with the core purpose. The entity list is long but directly relevant. Each sentence adds useful information, and there is minimal fluff.

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 tool with no annotations and no output schema, the description gives enough to construct a basic call, but it does not describe expected return values, error cases, or authentication constraints. The note about MaxFileSize packing is useful but leaves the overall invocation context incomplete.

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 description compensates for the low schema coverage by explaining entity, elem_id, file, and kind_key meanings, including the allowed entity list and the kind_key default. It does not mention real_name, but the schema itself provides a description for that field.

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's function: 'Attach local files to store elements.' It names the resource type and provides a specific verb, and it is distinct from sibling tools like engine_files_load and engine_files_remove, though it does not explicitly name alternatives.

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?

There is no guidance about when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. The description explains what the tool does but not under what circumstances an agent should choose it over similar 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 the behavioral disclosure burden. It discloses the write side effect of downloading into <store>/files, the manifest fields returned, and the meaning of the ok/missing/skipped states including the size-limit skip behavior. It does not mention overwrite behavior or permissions, but the main side effects and response semantics are visible.

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 with no filler; the first front-loads the operation and destination, and the second compacts usage and response details efficiently. Every clause contributes useful 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?

For a tool with no annotations and no output schema, it covers purpose, selection mode, and response manifest. But it omits the required 'entity' field and does not describe the array-of-objects request shape, leaving a critical gap for correct 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?

The description explains id ('one row') and elem_id ('every file of an element'), which is useful because schema coverage is 0%. However, the required 'entity' property is never explained, and the relationship between entity, id, and elem_id within the array items is left unclear, so an agent cannot reliably construct a valid request.

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 opens with a specific verb and resource: 'Download element files into <store>/files, the same layout the program keeps.' This clearly identifies the operation and destination and distinguishes it from engine_files_add/remove. However, it does not explicitly contrast with sibling load tools like engine_static_load or engine_whole_load, so differentiation is left to the reader.

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?

It gives concrete usage guidance inside the tool: 'Give id for one row or elem_id for every file of an element' and tells the caller to retry by id when a pack is skipped. It does not state when to prefer this tool over the sibling load tools, and there are no exclusions or alternatives named.

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 and does so admirably. It discloses the non-obvious behavior that the physical file remains on disk, that there is no undo, and that space is reclaimed via the idle-files audit module. This is exactly the kind of behavioral transparency needed for a destructive operation.

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 adding critical information: the action, the file persistence behavior, and the no-undo warning. No redundancy, and the most important warning is front-loaded. Perfectly structured for quick consumption.

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 behavioral aspects are well covered, but the parameter structure is unexplained. An agent invoking this tool would know the purpose and consequences but not how to construct the 'files' array correctly. Since the tool is simple (one parameter) and has no output schema, the description could have included a brief note on the required fields. This gap 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 description coverage is 0%, so the description must compensate for explaining parameters, but it does not. The schema shows a 'files' array with objects containing 'entity' and 'id', yet the description never explains what these fields mean or how to specify which rows to delete. The agent is left without guidance on how to populate the required parameter.

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 explicitly states the action 'Delete rows of element files' and clarifies it is not deleting the physical file. This clearly distinguishes it from sibling remove tools like engine_files_remove vs engine_static_remove, and the wording is specific to the file row context.

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 clear usage context: it warns about no undo and advises to warn first, implying when to use it (when you intend to remove file references). It also indirectly explains that for deleting actual files, the idle-files audit module is used, so it guides the agent toward the correct alternative for file deletion.

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 are provided, so the description carries the full burden of behavioral disclosure. It only restates the high-level outcome and does not mention return format, error behavior, side effects, or what happens when the id does not exist.

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 one short, front-loaded phrase with no filler or redundant information. It is appropriately sized for a simple one-parameter retrieval tool.

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 one-id getter, the description is minimally workable, but it lacks an output schema and does not explain how to obtain a valid id or what format the content will be in. Mentioning the relationship to engine_history_list would make it substantially more 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?

The schema has 0% description coverage, but the description minimally clarifies that 'id' refers to a saved version id. For a single integer parameter this may be sufficient, yet it adds no detail about the type, source, or expected format beyond the schema and name.

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 identifies the resource (one saved version) and the lookup key (id), so an agent can infer it retrieves content for a specific version. It also implicitly contrasts with sibling engine_history_list, though it lacks an explicit verb like 'retrieves' or 'gets'.

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 gives no guidance on when to use this tool versus alternatives such as engine_history_list, nor does it mention any conditions, exclusions, or related workflow. Usage context is only implied by the phrase 'one saved version by id.'

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 the burden of behavioral disclosure. It adds meaningful detail about the `before` filter and pagination semantics, but does not describe the return format, ordering, or whether any further constraints apply. This is adequate but incomplete.

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 short sentences deliver the core purpose and the most important pagination detail without waste. The most critical usage instruction is front-loaded and the rest is direct.

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 tool has no output schema and no annotations, so the description needs to cover both behavior and return expectations. It provides a clear purpose and pagination guidance, but it does not describe what rows are returned or what fields they contain. For a simple list tool this is close to sufficient, but still leaves 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?

Schema description coverage is 0%, so the description must compensate. It explains the subtle `before` parameter well, including the `version <= before` behavior. However, `path` and `limit` are not explicitly described, and `limit` is left to inference from the pagination context.

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 explicitly identifies the resource as 'saved-version history of a file', which makes the tool's purpose clear. It does not explicitly distinguish itself from sibling `engine_history_content` or other history tools, so it misses the top score.

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 clear context for when to use the tool: to retrieve saved-version history. It also gives actionable pagination guidance by explaining the `before` datetime cursor and how to page down using the last row's value. It does not mention alternatives or exclusions, but the usage context is otherwise 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?

With no annotations, the description must carry the behavioral disclosure burden. It does disclose one side effect—creating the module folder if missing—but does not explain overwrite behavior, error conditions, required permissions, or what happens on success. This is a meaningful but incomplete disclosure.

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 short, but the phrase 'by the same path load and save speak' is awkward and unclear, likely a typo or poor phrasing. It contains useful information in two sentences, but one sentence wastes the agent's attention on confusing wording.

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 one-parameter create operation, the description provides the path format and a key side effect../ But it lacks guidance on conflict/overwrite behavior, return values, and when this tool is appropriate compared to sibling tools. It is minimally usable but has clear 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?

Schema coverage is 0%, so the description must add meaning to the lone 'path' parameter. It does so by specifying the path template 'templates/<t>/units/<module>/<view>.htm', which defines the expected structure and file extension. However, the placeholders <t>, <module>, and <view> are not explicitly defined.

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 states the verb 'Create' and the resource 'template view', and provides a concrete path pattern. It is distinguishable from siblings like engine_html_save and engine_html_load, though the phrase 'by the same path load and save speak' is confusing and weakens clarity.

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 this tool is used to create a new template view and notes that the module folder is auto-created, but it gives no explicit guidance about when to use this tool versus engine_html_save, engine_static_add, or other add tools. No alternatives or exclusions are mentioned.

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 the full behavioral burden. It implies a safe read operation and warns that save overwrites, which is useful context. However, it does not explicitly state side effects, permissions, or 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?

Two short sentences deliver the essential information with no filler. The path pattern is front-loaded, and the warning is a distinct, useful second sentence.

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 one-parameter load tool, the path template and read-before-edit warning are largely sufficient. The main gap is that no output format or return value is described, though 'load' implies returning the file content.

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 schema only defines 'path' as a string, but the description adds a meaningful path template: templates/<t>/units/<module>/main.htm. This helps agents construct valid paths despite 0% schema description coverage.

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 names a specific verb and resource: 'Load a template view .htm' and gives a concrete file pattern. It is clear what the tool operates on, though it does not explicitly contrast with sibling loaders like engine_static_load or engine_whole_load.

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?

'Read before editing - save overwrites.' provides a clear usage context: this tool should be used to read content before making edits. It does not explicitly name alternative tools or exclusion conditions, but the guidance is actionable.

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 of behavioral disclosure. It states the action ('Delete') but does not disclose whether deletion is permanent, whether it cascades to related resources, whether confirmation is required, or what happens if the path does not exist. This is a destructive operation with minimal behavioral context.

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 a single, short sentence that is easy to parse and front-loads the action. It is appropriately concise, though it could add a bit more context without becoming verbose.

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 destructive tool with no annotations, no output schema, and a single undocumented parameter, the description is too thin. An agent would not know the path format, the permanence of deletion, or the success/failure behavior. Sibling tools like engine_static_remove and engine_template_remove suggest a family of similar operations, but the description does not clarify how this one differs.

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%, so the description must compensate for the undocumented 'path' parameter. The description says 'by its path' but does not explain what format the path should take, whether it is a file path, a URL path, or a template identifier, or how it relates to paths used by sibling tools like engine_html_save.

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 states a specific verb ('Delete') and resource ('a template view') identified by path, which clearly distinguishes it from sibling tools like engine_html_save, engine_html_add, and engine_html_rename. It is concise and unambiguous, though it does not explicitly name a sibling alternative.

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 is provided about when to use this tool versus alternatives such as engine_static_remove or engine_template_remove. The description implies deletion by path but does not clarify prerequisites, such as whether the template view must exist or whether deletion is permanent.

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 of behavioral disclosure. It does state a key behavioral trait: the rename is scoped to the same module folder and only changes the file name, which is helpful. However, it does not mention potential side effects such as overwriting an existing file, failure conditions if the source path does not exist, or whether the operation is reversible. For a mutation tool, this is a moderate gap in 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 a single, readable sentence that front-loads the action and parameter meanings. It avoids redundancy and keeps the explanation tight. The dash-based clarification is a bit informal but effective. It earns a 4 rather than a 5 because it could be slightly more structured (e.g., separating the parameter explanations), but it is efficient and to the point.

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 rename tool with two string parameters, the description covers the core action, parameter semantics, and a scope constraint. However, it lacks information about error handling, preconditions (e.g., the source path must exist), return values, or what happens if the target already exists. Given no output schema or annotations, these omissions leave some uncertainty for an agent executing the tool, making the description adequate but not fully 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 description coverage is 0%, so the description must fully explain the parameters. It does so explicitly: 'path is what it is called now, new_path what it becomes.' It also adds the crucial constraint that the new path is within the same module folder, implying new_path is just a file name, not a full path. This goes beyond the bare schema and provides necessary context for correct usage.

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 ('Rename a template view') and specifies the resource type (template view), distinguishing it from other rename tools for static, image, template, or PHP resources. It also clarifies the exact meaning of the two parameters and the scope (same module folder), making the tool's function unambiguous. However, it doesn't explicitly mention the 'html' aspect beyond the tool name, so it could be slightly more explicit about the resource type.

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 explicit guidance on when to use this tool versus alternatives. It mentions the constraint that only the file name changes within the same module folder, which implies it is not for moving across folders or modules, but it does not reference sibling tools like engine_static_rename or engine_template_rename or advise against using them. There is no clear when-to-use or when-not-to-use guidance, leaving the agent to infer based on the tool name.

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 are provided, so the description carries the burden. It discloses that the file travels 'byte for byte' and that the body comes either as content or as a file path, which is useful. However, it doesn't disclose whether the save overwrites existing content, whether it requires specific permissions, or what happens if both content and file are provided. The 'build' parameter behavior is explained, but the core mutation behavior is not fully 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 compact and front-loaded with the core action ('Save an existing template view .htm'). The second sentence efficiently explains the body source alternatives. The 'build' parameter description is embedded in the schema rather than the main description, which is acceptable. No wasted words, though the phrasing 'Say it only when...' is slightly awkward.

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 save/mutation tool with no annotations and no output schema, the description covers the main input modes and the 'build' flag's purpose. However, it lacks details about overwrite behavior, error conditions, whether the template must already exist, and what the return value is. Given the sibling set includes many similar save/add tools, more context about how this differs from engine_static_save or engine_template_add would help.

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 50%: 'file' and 'build' have descriptions, but 'path' and 'content' do not. The description adds meaning by explaining that 'content' and 'file' are alternative body sources and that 'file' is a path on this machine. It also clarifies the 'build' parameter's purpose. However, it doesn't explain the 'path' parameter beyond the schema, and the relationship between 'path' and 'file' could be clearer.

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 states a specific verb ('Save') and resource ('an existing template view .htm'), and clarifies the two ways the body can be supplied (content or file). It distinguishes from siblings like engine_html_add (which likely creates) and engine_html_load (which reads), though it doesn't name them explicitly.

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 context: it saves an existing template view, and the 'build' parameter description explains when to set it (only when the same save should make visitors take fresh styles). However, it doesn't explicitly state when to use this tool versus alternatives like engine_html_add or engine_static_save, nor does it mention prerequisites like the template view needing to exist.

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 supplied, the description carries the full behavioral burden and meets it well: it discloses the file/content body alternatives, the overwrite flag requirement, and the fact that files have no version history. This prevents an agent from assuming overwrite is automatic.

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 focused sentences, each adding distinct information, with the primary purpose front-loaded. There is no filler or repetition of schema details.

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 simple 4-parameter schema and absence of annotations or output schema, this description covers the key behavioral and input-selection facts. An agent can construct a correct add or overwrite call from the text alone.

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%, but the description compensates by explaining every parameter: path (full target), file (path on this machine), content (text for svg), and overwrite (only true overwrites). This gives the agent everything needed to choose the correct body mode.

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 opens with 'Upload a file of the images tree', naming a specific verb and resource. It further clarifies that path is the full target, folder and name at once, which differentiates this file-add tool from sibling directory or tree-load tools.

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?

It clearly conveys when to use the tool: uploading an image file into the images tree, with path specifying the complete target. It does not explicitly list exclusions or point to sibling alternatives such as engine_image_rename or engine_image_remove, so it misses the top bar for explicit routing.

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 behavioral burden. It discloses a key constraint (parent must exist) and implies non-recursive creation. However, it does not mention what happens if the folder already exists, whether the operation is idempotent, or any permission 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 short sentences with no filler. The purpose is front-loaded and the critical precondition immediately follows. Every word earns its place.

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 single-parameter tool with no output schema and no annotations, the description covers purpose and the main precondition. It is minimally viable, but an agent might also need to know success/error behavior and the tool's relationship to sibling directory tools for full confidence.

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 schema has 0% description coverage, so the description must clarify the 'path' parameter. It does add meaning by stating that 'path is the whole new folder' and that its parent must exist. However, it omits format details (absolute vs relative) and lacks examples, so it only partially compensates for the schema gap.

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 states a specific verb ('Create') and resource ('images folder'), which clearly identifies the tool's operation. It is distinguishable from sibling dir tools like engine_static_dir_add by the explicit 'images' qualifier, though it does not name the sibling it differs from.

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 clear precondition ('parent must exist') that guides when and how to use the tool. However, it does not explicitly state when to use this tool over alternatives, such as engine_static_dir_add, nor does it mention any exclusion cases beyond the parent requirement.

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 the full burden and explicitly discloses the critical behaviors: recursive deletion and lack of undo. This goes beyond the minimal schema and appropriately warns the agent about the destructive action.

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 short sentences with the primary action front-loaded and the warning second. No unnecessary words or repetition; every phrase earns its place.

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 one-parameter delete operation with no output schema, the description covers the main behavior and irreversibility. The missing path format detail is a minor gap, but overall the description is sufficient for invoking the tool correctly.

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 description does not explain the path parameter's format, whether it must be absolute/relative, or any constraints beyond 'images folder'. With 0% schema coverage, the description should compensate, but it leaves the agent to infer path semantics.

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?

States a specific verb (Delete), resource (images folder), and scope (recursively), which clearly distinguishes it from sibling tools like engine_image_remove (single image) and engine_image_dir_add. The purpose is immediately obvious.

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 clear usage context by warning about the irreversible nature ('No undo - warn the owner first'), implying careful use. It does not explicitly name alternatives, but the operation is self-evident from the name and description.

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 the burden of behavioral disclosure and does explain the key nuance of rename vs move based on path relationship. However, it omits side effects, conflict/overwrite behavior, prerequisites, permissions, and return information, so transparency is only partial.

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?

A single compact sentence that front-loads the action and then explains the two behavioral cases efficiently. There is no wasted wording, and the structure makes the conditional rule easy 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 rename/move tool, this is serviceable, but it leaves important invocation details unstated, such as whether the source must exist and whether the target parent must already exist. Without annotations or an output schema, more edge-case context would improve agent confidence.

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%, so the description must compensate. It does add meaning by showing how path and new_path interact, implying path is the source folder and new_path is the target. It still does not define path formats, required existence, or handling when both the parent and name change.

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 states a specific operation ('rename or move') applied to a specific resource ('images folder'), and clarifies the distinguishing rename-vs-move behavior based on parent path. This makes it easy to separate from sibling tools like engine_static_dir_rename or engine_image_rename.

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?

It gives explicit guidance for how to achieve each outcome: keep the parent and change the name to rename, or keep the name and change the parent to move. It does not explicitly compare against alternatives, but the conditional rule gives clear, practical usage 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, the description carries full responsibility for behavioral disclosure. It reveals that the tool always saves locally under mcp/melbis/, that png/jpeg/gif/webp are returned inline while svg is text, and that it never reads the local copy—always fetching from the server and overwriting. This is exceptionally transparent about side effects and 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?

Three sentences, each dense with essential information, front-loaded with the core purpose and sibling distinction. No redundant phrases or fluff—every word earns its place. This is an exemplary concise definition.

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 fully covers what an agent needs to know to call this tool correctly: the resource type, path structure, local storage behavior, format-specific return behavior, and server-side fetching semantics. Given the lack of output schema and annotations, this is remarkably 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 only 50% (file has a description, path does not). The description compensates by explaining the path structure ('By its tree path (templates/<t>/images/...)') and clarifying the 'file' parameter's role ('Local target instead of the mirror path') and the local storage location. This adds substantial meaning beyond the sparse 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 verb 'Load' and the specific resource 'a file of the images tree', and immediately distinguishes it from product files ('NOT a file of a product (those live in engine_files_*)'). This makes the tool's purpose unmistakable and differentiates it from siblings like engine_files_load.

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 explicitly states when NOT to use this tool (for product files) and names the alternative namespace (engine_files_*). It also gives the expected path format (templates/<t>/images/...), which tells the agent exactly how to structure the path parameter. This is strong usage guidance.

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 of behavioral disclosure. It goes beyond the verb 'Delete' by explicitly stating 'No undo and no version history' and instructing 'warn the owner first,' which makes the destructive, irreversible nature clear. It does not cover potential side effects or permissions, but for a one-parameter removal tool this is strong disclosure.

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 with no wasted words: the first states the action and operand, the second adds a critical warning. The key scope information is front-loaded, and every clause earns its place.

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 one-parameter destructive tool with no output schema and no annotations, the description covers the operation, the parameter's role, and the irreversibility warning. Minor gaps remain, such as expected response behavior or handling of nonexistent paths, but nothing essential for correct invocation is missing.

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%, so the description must compensate. It explains that 'path' locates a file within the images tree, which adds some meaning beyond the bare string type. However, it does not specify path format, relative/absolute details, or error behavior, so it only partially compensates for the missing schema documentation.

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 states a specific verb ('Delete'), a precise resource ('a file of the images tree'), and a mechanism ('by its path'). This clearly distinguishes it from sibling tools like engine_image_dir_remove (directories) and remove operations on other trees, so an agent can tell what it operates on without opening schemas.

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 gives clear context for use—deleting an image file by path—which implicitly routes away from sibling tools for directories (engine_image_dir_remove) or renaming/adding. It does not explicitly state exclusions or alternative conditions, but the context is unambiguous enough for correct selection.

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 the full burden. It does disclose a key behavioral nuance: the same folder with a new name renames, while another folder with the same name moves. However, it does not address overwrite behavior, permissions, or failure conditions, and the mutation is only implied by the verb rather than explicitly flagged as a write operation.

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 single sentence is tight and front-loaded with the action and resource, and the parameter mapping follows naturally. Every clause adds information; no filler or 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?

For a tool with two string parameters and no output schema, the description covers the core semantics and the surprising rename-vs-move behavior. Minor gaps such as path format, collision handling, and return value keep it from being fully complete, but it is sufficient for basic 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 0%, but the description defines both parameters: path is 'what it is called now' and new_path is 'what it becomes'. The additional rename-vs-move clarification gives meaning beyond the bare string 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 states a specific action 'Rename or move' applied to 'a file of the images tree', clearly distinguishing from sibling directory tools like engine_image_dir_rename. It also explains the role of both parameters immediately, so the tool's intent is unambiguous.

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 when to use the tool – to rename or move an image file – but does not explicitly contrast it with alternatives such as engine_image_dir_rename or engine_image_add. There is no when-not-to-use or exclusionary guidance; the agent must infer the boundary from the word 'file' and the sibling 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?

With no annotations, the description carries the full burden of disclosing behavior. It does not mention that the map is cached for the session (only in the schema), that it is a read-only operation, or any potential cost of loading the full tree. It also does not describe the return format or structure.

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 a single dense sentence that front-loads the core purpose ('Everything the store is made of') and efficiently lists content categories. It's concise with no fluff, though the long list makes it slightly run-on and less scannable.

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 broad scope and lack of output schema or annotations, the description is incomplete. It doesn't explain what the returned tree looks like (nesting, keys, etc.), whether it's a snapshot or live view, or any session behavior. An agent would need to guess at the exact return format.

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 both parameters are documented. The description adds minimal extra meaning—it reiterates the path narrowing effect but doesn't elaborate on value formats or interactions. The reload parameter is entirely absent from the description.

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's purpose: it maps the entire store's structure, listing specific content types (modules, templates, statics, images, fonts, folders, journals). This distinguishes it from resource-specific siblings like engine_static_load or engine_template_add, though it doesn't explicitly name the closest alternative engine_map_units.

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 only hints at path usage ('path narrows it down to one branch') but provides no guidance on when to use this tool versus other map or listing tools, nor any conditions for when it should be avoided. It also omits the reload parameter's purpose, which is only explained in the schema.

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 must disclose behavior, but it only states an output concept ('Function signatures of the unit files') without confirming side effects, read-only status, caching behavior, or the role of the reload and source parameters. It does not contradict any annotations because none are provided.

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 short and avoids filler, which helps readability. However, the fragment 'Function signatures of the unit files - what a module may call' is more of a gloss than a structured definition and sacrifices clarity for brevity.

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?

There is no output schema and no annotation coverage, so the description is the only source of grounding. It fails to explain what the returned signatures look like, how reload changes behavior, whether source is mutually exclusive with all units, or any other operational context the agent would need.

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 50%: source is described in the schema, but reload is not. The description does not compensate for reload or clarify how it affects the returned signatures, so an agent gets little help understanding the optional boolean's meaning or the relationship between source and the overall result.

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 identifies the resource (unit files) and the subject (function signatures), and the phrase 'what a module may call' adds some semantic context. However, it is a noun phrase rather than an explicit verb+resource statement, and it does not clearly differentiate itself from the sibling engine_map_tree or other map-like tools.

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?

There is no guidance about when to use this tool instead of a sibling, and no mention of prerequisites or context such as whether a source file must be provided. The description implies it is for inspecting callable function signatures, but leaves appropriate-use conditions entirely to inference.

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 are provided, so the description carries the full burden. It discloses a significant side effect: for units/<name>.php it also creates a .json and a view folder in every template set. However, it does not mention overwrite behavior, permissions, or other potential side effects, and the first sentence is ambiguous.

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 short and front-loaded with 'Create', but the first sentence is awkward and confusing ('by the same path load and save speak'), which detracts from clarity. The second sentence is clear and structured, but the overall phrasing could be improved.

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 creation tool, it explains the two cases and side effects, which covers the core usage. However, it lacks explicit mention of what happens if the file already exists, error conditions, or return values, and the unclear first sentence leaves some 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?

Schema description coverage is 0%, so the description must compensate. It explains the 'path' parameter thoroughly by describing the two path patterns (units/<name>.php and other) and their consequences, adding meaningful semantics beyond the bare 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 creates a php file and distinguishes two path-based behaviors (module vs. root script), which differentiates it from siblings like engine_php_save or engine_php_remove. However, the phrase 'by the same path load and save speak' is unclear and slightly obscures the core message.

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?

Usage is implied by the verb 'create' and the path semantics are explained, but there is no explicit guidance on when to use this tool over alternatives (e.g., engine_php_save for existing files). The description does not state exclusions or alternative recommendations.

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 are present, so the description carries the full burden of behavioral disclosure. It does not say whether loading executes the PHP file, returns its contents, parses the manifest, or has side effects. The phrase 'with its manifest' hints at behavior but does not clarify the actual operation or output.

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 one short, readable sentence with no filler words. It is appropriately concise, though its brevity comes at the cost of missing behavioral and parameter guidance.

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 annotations and no output schema, an agent does not know what the operation returns, how the manifest is delivered, or what path is expected. The single-sentence description is too thin to be a complete reference for correctly invoking this tool in varied scenarios.

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 schema has one 'path' parameter with 0% description coverage. The description implies that path refers to a PHP file, which is some added meaning, but it does not explain path format, whether it is relative or absolute, or how the manifest is associated. Because schema coverage is 0%, the description needed to compensate more than it does.

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 uses a specific verb, 'Load', with an explicit resource, 'php file (root script or module)', and adds the manifest detail. This clearly distinguishes it from sibling loaders like engine_static_load, engine_html_load, engine_whole_load, and engine_files_load by the file type involved.

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 gives no guidance on when to use this tool versus alternatives such as engine_whole_load, engine_static_load, or engine_html_load. It does not state prerequisites, exclusions, or a selection rule, leaving the agent to infer usage from the name alone.

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 are provided, so the description carries the full burden. It clearly discloses the destructive nature of the operation and goes further by revealing the cascading side effect: for module paths, the .json and view folders in template sets are also deleted. This is valuable behavioral context beyond the parameter schema.

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 short sentences with no filler. The primary action is front-loaded, and the important side-effect condition follows immediately. Every word contributes to the agent's understanding.

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 destructive tool with no output schema, the description is largely sufficient: what is deleted, how the path is used, and which additional files are affected. The only minor gap is that 'the .json' is slightly informal and could be clearer about its exact naming/location.

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 schema provides only a bare 'path' string with 0% description coverage, so the description must add meaning. It explains that path refers to the PHP file to delete and gives the concrete module pattern units/<name>.php that triggers additional cleanup. This meaningfully compensates for the lack of schema documentation.

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 states a specific verb (Delete) and resource (php file by path), making the tool's scope immediately clear. It also distinguishes from sibling remove tools like engine_html_remove or engine_static_remove by being php-specific. The module caveat adds useful specificity rather than confusion.

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 deleting PHP files and identifies the triggering pattern for module cleanup. However, it does not explicitly state when not to use it or point to alternatives among the many sibling remove tools. An agent must infer the boundary from the tool name and description.

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. It discloses the kind-stays-same rule, but omits important behavioral details such as error handling (e.g., if path does not exist), whether new_path overwrites an existing file, or what the success criteria are.

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 with no fluff. The purpose is front-loaded, then parameters are clarified, and the constraint is added last. Every word earns its place.

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 rename operation with no output schema, the description covers the core essentials: what it does, what parameters mean, and a key restriction. It lacks guidance on edge cases like overwrite behavior, but this is a minor gap for an operation of this simplicity.

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%, so the description is the only source of parameter meaning. It explains both parameters precisely: 'path' is the current name and 'new_path' is the target name. This fully compensates for the schema gap.

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?

States a specific verb (rename) and resource (php file), and explains the role of each parameter. The mention of 'php' clearly differentiates it from other rename tools in the sibling list (html, static, 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?

Provides an explicit constraint: the file kind (module vs root script) must stay the same, which guides when this tool is appropriate. It does not explicitly name alternatives, but the tool name itself makes the file type unambiguous.

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 are provided, so the description carries the full burden. It discloses that file mode sends bytes 'byte for byte' without retyping, and that manifest saves preserve only lines that were switched off (e.g., 'log=0'). This goes beyond the obvious save semantics and provides useful behavioral detail. It doesn't mention side effects like build increments, but that parameter is documented in the schema.

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 a single dense sentence but front-loads the core purpose and packs essential details (two body sources, module manifest behavior). It avoids redundancy and stays within ~50 words, making it efficient. The structure is acceptable, though slightly run-on, but information is well-ordered.

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 save tool with 5 params, one required, and a nested manifest object, the description covers the main operational modes (content/file, module manifest) and the byte-for-byte nuance. It does not describe the return value (no output schema), but save tools typically return a simple success indicator. It also doesn't address what happens if both content and file are provided, but that's an edge case. Overall, it's sufficient for correct 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 60% (3 of 5 params described). The description compensates by clarifying that 'content' and 'file' are alternative body sources, and explains the manifest's purpose and behavior. It implicitly clarifies 'path' as the target location. It adds meaning beyond the schema for content and manifest, though it doesn't elaborate on 'build' (schema does) or provide syntax details for file paths.

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 opens with a clear verb+resource: 'Save an existing php file.' It distinguishes from siblings by specifying 'existing' (vs add for new files) and explains the module manifest rewrite case, which is unique to this save operation. The purpose is unambiguous and sets it apart from engine_php_add, rename, remove, and load.

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 when to use it: for existing files, and for modules to rewrite manifests. It doesn't explicitly name alternatives like engine_php_add for new files, but the word 'existing' and the module-specific note give clear context. It lacks an explicit 'when not to use' statement, but the intended usage is inferable.

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 must carry the full behavioral disclosure burden. It states the operation is a substring search but does not mention whether it is read-only, what the return format looks like, or any side effects. It only clarifies scope, not behavior beyond the obvious search semantics.

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 tightly worded sentences with zero fluff. The action and scope are front-loaded, and the exclusion list is given in a compact second sentence. Every word earns its place.

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 search tool with two parameters and no output schema, the description covers the inclusion/exclusion scope well but omits the return format and any note on read-only status. Given the tool's simplicity, it is minimally adequate but leaves the agent to infer typical search behavior.

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 50% — only 'sensitive' has a description, while 'keyword' is undocumented. The description adds meaning by calling it a 'substring search', implying keyword is the search string, but it does not elaborate on format or constraints. It provides marginal value beyond the schema, partially compensating for the missing keyword documentation.

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 verb (substring search), the resource (server files), and precisely enumerates what is included (unit code and views, root scripts, .htaccess, css/js of template sets) and excluded (manifests, core, images). This specificity distinguishes it from sibling file-loading tools without ambiguity.

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 gives explicit scope boundaries, which implicitly tells the agent what this tool covers and what it does not, but it does not explicitly state when to prefer it over an alternative or mention any sibling tools. It lacks direct 'use this for X, not for Y' guidance, though the scope listing partially serves that purpose.

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 are provided, so the description carries the full behavioral burden. It discloses that the tool creates an empty static file, but it does not say whether an existing path is overwritten, whether parent directories are created, what permissions are required, or what error/response behavior to expect.

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 short and front-loads the main action, which is good. However, the trailing clause 'by the same path load and save speak' is confusing and does not earn its place, so the structure is acceptable but not clean.

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 creation tool the core action is simple, but with no annotations and no output schema the description still leaves key call-time questions open: what the path must be, what happens on conflict, and whether there are side effects beyond creating the file.

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 schema provides no description for the path parameter, and the description's 'same path load and save speak' is too ungrammatical to count as clear parameter guidance. It hints at a shared path convention, but does not clarify path format, relative/absolute use, or what the path should point to.

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 phrase clearly identifies the action and resource: create an empty static file. The trailing phrase is garbled, which keeps it from being a 5, but the core purpose is still distinguishable from the static-file load/save/rename/remove sibling tools.

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?

There is no explicit guidance about when to use this tool versus engine_static_save, engine_static_load, engine_static_remove, or the directory-add variants. The sibling names imply a file-lifecycle family, but the description never states prerequisites, timing, or exclusions.

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 the behavioral burden. It discloses that the operation creates a folder and that the parent must already exist, which is meaningful. However, it does not state what happens if the folder already exists, whether creation is recursive, or any error behavior, leaving gaps for a write operation.

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 short sentences with no filler. The action is stated first and the essential path constraint follows immediately; every word earns its place.

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 one-parameter folder-creation tool, the description provides the core information needed to call it: what it does and what the path must satisfy. It lacks conflict/error behavior and explicit sibling routing, but the low complexity means these are minor rather than blocking 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 schema provides only a string type with no description, so the description must compensate. It explains that 'path' is the whole new folder and that its parent must exist, which directly clarifies the required input 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 states a clear action ('Create') and resource ('a statics folder'), so an agent knows this tool creates a directory rather than a file. It is distinguishable from sibling rename/remove tools by the verb and from static_add by the word 'folder', though it does not explicitly name alternatives.

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 verb 'Create' implies when to use this tool: when a new statics folder is needed. It also provides a useful prerequisite, that the parent directory must exist, but it gives no explicit guidance on alternatives or exclusions relative to sibling directory 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 the full burden of behavioral disclosure. It explicitly states the destructive nature ('No undo') and the recursive scope, and advises warning the owner, which covers the key risks. It does not mention side effects like permission requirements or error behavior, but for a simple delete operation this is largely 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?

The description is two concise sentences that front-load the primary action and key caveat. Every word earns its place, with no redundant or vague phrasing.

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 one-parameter delete tool, the description covers the core behavior and warns about irreversibility. However, it omits any guidance on the 'path' parameter, which is the sole input, and does not clarify what happens if the path is invalid or points to a file. These gaps prevent full operational 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?

The schema has a single 'path' parameter with no description, and schema coverage is 0%. The description does not explain what 'path' refers to (e.g., relative vs. absolute, whether it must be a directory, or the path format), leaving the agent without critical information for correct invocation. Since coverage is zero, the description must compensate but fails to do so.

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 ('Delete a statics folder WITH everything inside it, recursively, bundle descriptors included'), specifying the resource and scope. It distinguishes itself from sibling tools like engine_static_remove (which likely targets a single file) by emphasizing recursive deletion of the entire folder.

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 recursive directory deletion but does not explicitly name alternatives or state when not to use it. It mentions 'warn the owner first' as a precondition but provides no comparison to engine_static_remove or other static tools, leaving the agent to infer the appropriate context from the name and scope.

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 the full burden, and it discloses critical behavioral traits: bundle descriptors follow files, built statics/bundle.* are NOT rebuilt, the response counts affected files, and the owner must re-save bundles. This goes well beyond a generic 'rename' and prevents the agent from assuming stale output is safe.

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 dense sentences, each earning its place, with the core action front-loaded and side effects stated in a dependent clause. No filler or repetition.

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 two-parameter mutation tool with no annotations and no output schema, the description provides the essential inputs, the two valid operation modes, a critical non-rebuild warning, and the outcome semantics. Minor gaps remain around error handling and the ambiguous combined operation, but the agent has enough to invoke correctly in the common cases.

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 0%, so the description must explain the two string parameters. It does so implicitly through the parent/name distinction: path is the current location and new_path is the target, with different combinations yielding rename vs move. However, it leaves the combined case (different parent AND different name) ambiguous and doesn't specify path format or existence expectations.

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 uses a specific verb+resource pair ('Rename or move a statics folder') and immediately disambiguates the two variants via parent/name relationships. It clearly distinguishes from sibling tools like engine_static_rename (which targets a static file) and engine_static_dir_add/remove.

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 gives concrete conditions for when to use rename vs move ('same parent with a new name renames, another parent with the same name moves'), which tells an agent how to pick the right operation. It does not explicitly name alternative tools or state when not to use this tool, but the sibling set makes the domain obvious.

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 are provided, so the description must carry the behavioral burden. It discloses that this is a read-only operation ('load', 'read before editing') and warns about the save overwrite behavior. However, it does not mention error handling, return format, or side effects beyond reading. This is a moderate level of transparency for a simple load tool.

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 short sentences, front-loaded with the primary purpose and immediately followed by a crucial usage note. There is zero fluff; every word earns its place.

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 one-parameter load tool with no output schema, the description covers the essentials: what it loads, where, and when to use it. It omits explicit return format (likely file content), but that is reasonably inferred. It lacks mention of error cases, but these are minor for a basic read operation.

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%, so the description must compensate. It provides a concrete path pattern ('templates/<t>/statics/...') that gives the agent a clear template for the 'path' parameter, adding significant meaning beyond the bare schema. It doesn't specify relative vs. absolute or file extensions, but the convention is enough for correct usage.

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 states a specific verb ('load') and a well-defined resource ('static file, css or js') with a path convention ('templates/<t>/statics/...'). This clearly distinguishes it from sibling load tools like engine_image_load (images), engine_html_load (HTML), and engine_files_load (other files). The 'Read before editing' note further clarifies its role as a read operation.

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 gives clear context: it is for reading css/js static files, and the instruction 'Read before editing - save overwrites' signals when to use it (before a save operation) and implies the counterpart save tool exists. It doesn't explicitly list alternatives or exclusions, but the specificity of the resource type and the naming of siblings make the intended use unambiguous.

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 are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Delete') but does not mention whether the operation is permanent, whether it requires specific permissions, what happens if the path does not exist, or what the return value is. For a destructive operation with zero annotation support, this is a significant gap.

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 a single, efficient sentence with no filler words. The verb and object are front-loaded, making it immediately scannable and easy 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 single-parameter delete operation with no output schema, the description covers the basic action and parameter meaning. However, it omits any caveats about reversibility, error behavior, or prerequisites, which an agent might need to call it correctly, especially given the absence of annotations.

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 schema description coverage is 0%, meaning the 'path' parameter has no description in the schema. The description explicitly says 'by its path', which clarifies that the parameter is the file path, adding meaning that the schema lacks. It does not specify format or constraints, but the core meaning is conveyed.

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 states a specific verb (Delete), a clear resource (a static file), and the mechanism (by its path). This clearly distinguishes it from siblings that add, rename, load, or otherwise manipulate static files, so an agent can identify the intended operation 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.

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

No guidance is provided on when to use this tool versus alternatives such as engine_files_remove or engine_image_remove. The description only states what it does, not the context in which it should be selected, leaving the agent to infer from naming conventions alone.

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 the behavioral disclosure burden incl. exact path interpretation and the rule that a same-folder change renames while a different-folder change moves. It also discloses the side effect that 'bundle descriptors follow it.' It does not cover permissions, failure modes, or reversibility, but the core behavior is unusually well articulated.

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 the main operationcher and no filler. Each clause adds meaning: the path/new_path mapping, the rename-vs-move rule, and the bundle descriptor side effect.

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 2-parameter tool with no output schema or annotations, the description covers what the operation doesaint and how parameters interact. The only notable gap is that 'bundle descriptors' is unexplained, and there is no mention of error conditions or whether the source path is invalidated on a move.

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 0%, so the description must define both parameters. It does so explicitly: 'path is what it is called now, new_path what it becomes', and further explains folder-based rename/move semantics. This fully compensates for the empty 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?

States a specific operation ('Rename or move a static file') with the resource and the path semantics ('path is what it is called now, new_path what it becomes'). It also distinguishes rename from move based on folder behavior, which differentiates it from sibling tools like engine_static_add/remove and engine_static_dir_rename.

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 when to use the tool: when renaming or moving a static file, and it clarifies the move-vs-rename distinction. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent.

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?

There are no annotations, so the description carries the burden. It adds useful concrete behavior: the payload may be inline content or a local file path, copied byte-for-byte. However, it does not disclose overwrite semantics, whether the path must already exist, the one-of content/file requirement, or the operation's result.

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 short sentences, front-loaded with the operation and resource before the source options. Every phrase earns its place.

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 tool has 5 parameters including a nested bundle object and no output schema; the description omits critical routing cues, a mandatory 'one of content/file' note, and expected behavior after save. The schema fills in some details, but the tool description alone is not enough for confident 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?

At 60% schema coverage, path and content are undocumented, and the description partially compensates by explaining the content/file alternative. It adds meaning to content and file but leaves path's role and build/bundle effects to the schema; no extra semantics are provided for path.

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?

States a concrete operation ('Save') with a specific resource ('existing static file (css/js)'), and the phrase 'existing' separates it from creation-oriented siblings. It doesn't explicitly name engine_static_add or other alternatives, so the differentiation is implied rather than spelled out.

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 gives no 'when to use' guidance, no exclusions, and no named alternatives. An agent must infer from sibling names that engine_static_add/rename/remove serve other lifecycle operations.

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 of behavioral disclosure. It states that a template group is created, which implies a mutating operation, but it does not disclose whether the operation overwrites an existing group, requires specific permissions, fails on duplicates, or what side effects occur.

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?

A single sentence with no filler; every word carries meaning and the core action is front-loaded. This is an appropriately sized description for a simple create operation.

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 tool has one required parameter, no annotations, and no output schema, so the description must provide enough context to call it correctly. 'Create a template group' explains the high-level purpose but omits essential details about what the 'template' parameter should contain and the behavior on existing groups, making it insufficient for safe 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?

The input schema provides no description for the required 'template' string (0% schema coverage), and the description only weakly implies that this parameter identifies the template group. It does not clarify whether 'template' is a name, path, or content payload, leaving an agent to guess the correct value format.

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 uses a specific verb ('Create') and resource ('a template group'), which identifies the operation clearly and distinguishes it from sibling tools like engine_template_rename and engine_template_remove. It does not name alternate siblings, but the resource is specific enough to avoid confusion.

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 verb 'Create' implies this tool is for adding a new template group rather than renaming or removing existing ones, but the description does not explicitly state when to use it or mention alternatives. Usage guidance is only implied, not articulated.

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 are provided, so the description carries the full burden. It only states that a template group is deleted, with no disclosure of irreversibility, side effects, permissions, or what happens to templates within the group.

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 a single, direct sentence with no filler. It is front-loaded and easy to parse, which is appropriate for such a simple tool.

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 destructive operation with no annotations, output schema, or parameter documentation, the description is too sparse. It leaves out safety-relevant context and does not clarify the template parameter, making it barely sufficient for correct 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 description coverage is 0%, and the description does not compensate by explaining what the 'template' parameter should contain. An agent cannot infer the expected value format or identifier semantics from the description.

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 states a specific verb ('Delete') and resource ('a template group'), matching the tool name precisely. It clearly distinguishes this from sibling tools like engine_template_add and engine_template_rename.

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 is given on when to use this tool versus alternatives, such as engine_template_rename or the various other *_remove tools. The intended use is only implied by the name and description.

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 are provided, so the description carries the full burden of disclosing behavior. It only states the obvious rename action, without mentioning side effects, reversibility, permissions, or what happens to associated data. For a mutation tool with no annotation support, this is insufficient.

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 and front-loaded with the core purpose in a single sentence. However, it is arguably under-specified, but for a simple tool, the brevity is acceptable. The structure is clean, though it could benefit from a brief parameter note.

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 tool with two required parameters, no output schema, and no annotations, the description is incomplete. It does not explain parameter semantics, potential side effects, or how it fits into the broader toolset. An agent would struggle to invoke it correctly without additional inference.

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%, so the description must explain the two parameters (was_template and new_template). It does not. The parameter names are somewhat self-explanatory, but the description adds no meaning beyond what the schema provides, failing to compensate for the coverage gap.

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 states a clear action (rename) and resource (template group), which is specific and easily understood. However, it does not differentiate from the many sibling rename tools (e.g., engine_html_rename, engine_static_rename), though the name itself provides some distinction. Without explicit sibling differentiation, it's a solid 4.

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?

There is no guidance on when to use this tool versus the other rename tools or any alternatives. It does not mention prerequisites, typical use cases, or conditions that would select this tool over siblings. With many similar tools available, this is a significant gap.

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 key behaviors: writes to a local file, never returns content in the answer, and does a byte-for-byte copy. However, with no annotations, it carries the full burden and omits details like whether existing files are overwritten, if parent directories are created, or any permission requirements. The core behavior is disclosed but not exhaustively.

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 first sentence is concise and front-loaded with the essential behavior. The second sentence, while providing context, is cryptic ('the plain load answers with its last megabyte') and could be misinterpreted. Overall it's not overly long but contains unnecessary ambiguity, so it's adequate but not exemplary.

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?

With no annotations and an incomplete schema, the description must carry the full burden. It explains the core behavior and hints at usage, but fails to clarify the parameters, error handling, or file-overwrite semantics. For a tool with only two parameters and no output schema, this leaves significant gaps for an agent to correctly invoke it.

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 schema has only 50% description coverage (file is described, path is not). The tool description does not clarify the meaning of 'path' or 'file' or their relationship (e.g., which is the store path and which is the local destination). It adds no value beyond the existing schema, failing to compensate for the undocumented 'path' parameter.

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 ('Download ONE file of the store') and the resource ('any tree, byte for byte') with a specific outcome ('written to file on this machine, never entering the answer'). It differentiates from siblings by contrasting with 'the plain load answers with its last megabyte', implying this tool provides the whole file, though it doesn't name a specific 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 description provides usage context: use this when you need the entire file (e.g., 'a journal of core/log whole') because 'the plain load answers with its last megabyte', and for anything 'too big or too exact for an answer'. This gives clear conditions for when to prefer this tool over the standard load, though it doesn't explicitly say 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?

With no annotations, the description carries the burden. It discloses ordering (everyone, groups, own, first two marked) and the 100-note warning, but does not explicitly state read-only behavior or how the 'find' parameter affects the listing. This is adequate but lacks some explicit behavioral details.

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 a series of four sentences that mix purpose, usage, and behavioral notes. It is not tightly structured and could be more concise, but each sentence carries useful information 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?

For a simple listing tool with one optional parameter, the description covers purpose, usage, ordering, and the 100-note warning. The output format is implied by the listed attributes, and the 'find' parameter is handled by the schema. Minor omissions (e.g., whether the warning applies when filtering) do not significantly impede correct use.

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 schema already provides a full description of the 'find' parameter (filters by name, category, description, or text), and the tool description adds no extra meaning beyond that. With 100% schema coverage, the baseline 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 lists memory notes with their metadata (number, category, kind, description, size, time), and distinguishes itself from memory_load by noting texts are asked for separately. It is a specific verb-resource description that differentiates from siblings.

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?

It explicitly instructs to read it at the start of a session and explains when kCritical notes are loaded versus the rest. It also advises warning the user past 100 notes, providing clear context for when to use this tool. It does not name alternative tools explicitly, but the 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, the description carries the full burden and does well. It discloses session-start behavior (kCritical notes loaded), the refusal of other commands until all are loaded, ownership markings on notes, and the 'missed' response for inaccessible numbers. These are significant behavioral traits beyond basic read functionality.

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 and front-loads the core purpose. It packs essential behavioral details without excessive verbosity. It is somewhat dense but remains readable and effective.

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 complexity (session gating, ownership, missed notes), the description covers the key behavioral aspects and hints at return semantics. It lacks explicit return format details, but the absence of an output schema means the description should compensate; it partially does by mentioning markings and 'missed', though not fully detailing the response structure.

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% and the description does not clarify the distinction between 'id' and 'ids'. It says 'by their numbers, several at once' but does not explain whether 'id' is for a single note, whether 'ids' is an array, or if both can be used together. This leaves the agent guessing about how to populate parameters correctly.

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 reads notes by numbers and can read several at once. It references memory_list for numbering, distinguishing it from memory_save and memory_remove. The purpose is specific and unambiguous, though it could be more explicit about the singular vs plural parameter usage.

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?

It implies usage by referencing memory_list for numbers and explains session constraints: every kCritical note must be loaded first, and other commands are refused until then. This provides clear guidance on when to use the tool, though it does not explicitly name 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?

With no annotations, the description carries the full burden. It states the action is to 'forget' (implying deletion) and scopes it to 'your own' notes, but does not disclose irreversibility, potential side effects, or any permission requirements. It adds some context but could be more explicit about destructive consequences.

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 a single sentence with no fluff. The core action and resource are front-loaded, followed by useful elaboration on use cases. Every part earns its place.

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 one-parameter tool with no output schema, the description covers what, when, and how to identify the target. It could mention irreversibility explicitly, but the word 'forget' reasonably implies deletion. Overall, an agent has enough to call it correctly.

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 0%, so the description must compensate. It explains that the id is the one used by memory_list, giving semantic meaning beyond the bare integer type. This clarifies exactly what id to pass, which is essential for correct 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?

The description clearly states the verb 'forget' (i.e., remove), the resource (a note of your own), and the identifier (id as memory_list numbers it). It also gives concrete use cases (wrong note or agreed to drop at review), distinguishing it from siblings like memory_save and memory_load.

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?

It provides clear context for when to use the tool (when a note is wrong or agreed to be dropped) and implies the id comes from memory_list, guiding the agent on prerequisite steps. It doesn't explicitly exclude alternatives, but the context is sufficient given the sibling set.

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 the full burden and excels: it discloses user-consent requirement, refusal when memory is in window, the ordering of notes, the fact that group/everyone notes are admin-owned, and that host memory is invisible to the owner. No contradictions.

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 a long, dense paragraph. While all content is relevant, it is not appropriately sized; it could be trimmed and structured with bullets or sections. The core action is front-loaded, but the volume overwhelms the reader.

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 write tool with no output schema, the description is exhaustive: it covers consent, content guidelines, update rules, kind semantics, ordering, refusal behavior, and storage location. An agent has everything needed to invoke it correctly.

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 deep meaning: id semantics (update vs new), kind_key semantics with detailed binding order, body format constraints (plain HTML, no markdown), and default behaviors. It goes far 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 states a specific verb and resource ('Write a note of your own') and clarifies the update behavior via id, distinguishing it from memory_list, memory_load, and memory_remove. It is clear that this tool creates or modifies personal notes.

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-to-use guidance: only after user agreement, and what content is appropriate (learned about THIS store, not code facts). It also names an alternative (scheduler) and explains where notes belong vs host memory. This fully routes an agent.

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 of disclosing behavior. It reveals the authentication mechanism (signs in as the person at the keyboard, with the program providing credentials or stored settings), explicitly states it cannot take a password, and mentions the possible NO_SETTINGS response with remediation steps. This goes beyond a generic 'sign in' and gives an agent actionable knowledge, though it does not describe the success output or side effects in detail.

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 front-loaded with the core purpose, which is good, but it becomes somewhat wordy with the repeated mention of passwords and the NO_SETTINGS explanation. It could be tightened to two concise sentences without losing meaning, but it is not excessively long.

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 sign-in tool with no parameters and no output schema, the description covers the essential context: what it does, how authentication works, and how to handle the NO_SETTINGS failure case. It references session_init as a prerequisite, which is helpful. It does not describe the success return value, but that is likely minimal for a session-establishment tool.

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, so the baseline is 4. The description reinforces this by explicitly stating 'Takes no arguments' and explains why (cannot take a password), adding meaning beyond the empty schema. This is sufficient for a no-parameter tool.

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 signs in to the active store (the one session_init marked), uses a specific verb and resource, and distinguishes itself from siblings by referencing session_init. It is not a tautology and leaves no doubt about the tool's role.

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?

It explains when to use the tool (to sign in to the active store) and gives context on how it works, including that it takes no arguments and cannot take a password. It also instructs on handling the NO_SETTINGS response, which is practical usage guidance. It doesn't explicitly compare to alternatives, but the reference to session_init and the emphasis on passwordless sign-in implicitly differentiate it from any password-based sign-in 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 provided, the description carries the full burden and explicitly states 'Writes nothing, asks the shop nothing, costs nothing.' This fully discloses the read-only, side-effect-free nature of the tool, which is critical for safe agent use.

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-loads the core purpose, and uses an effective 'what it does' + 'when to call' structure. Every word adds value; no 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?

For a simple read-only informational tool with no parameters and no output schema, the description covers all essential aspects: what information is gathered and the safe call behavior. It could specify the exact return structure, but given the conceptual nature, it is adequate.

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, so the empty schema requires no explanation. The description naturally handles this by not referencing any parameters. Baseline 4 is appropriate for a parameterless tool.

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 what the tool does: it provides an overview of available stores, the active store, whether Melbis Shop is running, and where documentation starts. It uses specific verbs and distinguishes itself from session_connect by positioning itself as a pre-sign-in reconnaissance 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?

The description gives explicit guidance on when to call it ('Look around before signing in') and when to re-call ('call it again whenever the person may have switched store'). It does not name specific sibling alternatives, but the context makes the intended use 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 carries the full burden and does well: it explains that modules, profiles, and a database dump are copied, that the dump can be large, and that the result is unpacked into a local folder. It stops short of detailing overwrite behavior or permissions, but for a download/copy tool the disclosed behavior is substantive.

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 purpose is front-loaded in the first phrase, and the three-sentence structure efficiently covers scope, payload types, and output format. Some phrasing such as 'the way the program copies it' is slightly redundant, but it does not add meaningful noise.

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 tool with no output schema and no annotations, the description covers the main inputs, the unpacked-to-folder outcome, and the key caveat about large database dumps. It does not explicitly state prerequisites such as which store 'this store' refers to, but the core calling context is sufficiently clear.

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 schema already documents both parameters with 100% coverage, and the description adds further meaning by unpacking the action values: modules are units/templates/root scripts, profiles are picture profiles, and database is a dump. The folder parameter is only lightly addressed in prose ('into a folder here'), but the schema supplies the default location, so nothing is missing.

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 opens with 'Copy the code of THIS store onto this machine', giving a specific verb and resource, then enumerates the payload types: modules, profiles, and database. It also distinguishes itself from load-style siblings by saying the result 'arrives unpacked into a folder here' rather than loading items one by one.

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 makes the use case clear: read a store as files instead of loading it piece by piece, and it calls out that a large store's database dump is large and travels whole. It does not explicitly name alternative tools or exclusion conditions, but the context is clear enough for an agent to decide when this tool fits.

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 the whole disclosure burden and does so thoroughly: it reveals file saving, module-cache invalidation, the markup-not-picture caveat, POST side effects on database and email, session-cookie persistence for POST sequences, fresh-visit behavior for plain reads, and the debug parser report. This is exceptionally candid about effects an agent cannot infer from the schema.

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 dense but well-ordered: action, save location, output shape, then caveats. It avoids repeating schema text, though phrases like 'the rest is cleared by hand' and the run-on sentence structure make it slightly harder to parse than necessary.

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 annotations and no output schema, the description is remarkably complete: it explains return content, file persistence, side effects, session behavior, debug output, and the practical meaning of markup versus visual appearance. An agent has enough context to invoke the tool safely and interpret its results.

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 schema already documents find, path, and post, so the description doesn't need to restate them. It adds crucial semantics by explaining that post changes a read into a visitor-submitted form with real store side effects and cookie persistence, and it provides the only explanation of the otherwise undocumented debug parameter. This meaningfully exceeds the schema baseline.

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?

States the operation precisely: fetch a store page as a visitor sees it, save the HTML under mcp/melbis/pages/, and answer with status, size, title, and either matching fragments or the page head. This clearly separates it from sibling engine_* and shop_download tools by emphasizing the rendered visitor view, file save, and summary output.

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 gives clear contextual guidance: use it for visitor-visible storefront pages, and use POSTs to drive storefront flows like filling a basket or writing a review. It also warns when to avoid POST without owner consent, though it never names an alternative tool or gives an explicit 'when not to use this' condition.

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 exist, so the description carries the full burden of behavioral disclosure, and it does so richly: it discloses execution equivalence ('same parser, same cache, same access to the data'), auth context ('nothing but the session key'), output destination (mcp/melbis/runs/), and truncation behavior ('comes back here whole unless it is long'). A minor gap: what actually happens when output is long (error? truncated? saved to file only?) is left unstated.

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?

Long but efficiently packed with zero filler. Purpose is front-loaded, followed by the sibling differentiation, execution-equivalence note, three conditions, and output location. Each clause earns its place; the only knock is that the three conditions could be slightly tightened, but nothing 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 tool that runs arbitrary code with a nested params object and no output schema or annotations, the description covers purpose, alternative routing, execution semantics, preconditions, and output handling. The only notable gap is the unspecified behavior for long output, which is an edge case an agent would want to know.

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 100% (baseline 3), and the schema already documents both params in detail - mod with an example, and params with serialization behavior, manifest param_info, $mVars[post], and $_POST stripping. The description adds value beyond the schema by imposing the agent_ prefix constraint on mod and the entry-point requirement, which are semantic restrictions not present in 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?

States a specific verb and resource ('Run a module of YOUR OWN on this store and read what it printed') with clear scope - it is for the agent's own code, not the owner's. It explicitly distinguishes itself from the sibling tool_run ('For work the owner of the shop already provided for, use tool_run instead'), making differentiation immediate.

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?

Gives explicit when-to-use guidance for the agent's own code and names the alternative (tool_run) with the exact condition that selects it ('that one has a registry row and a grant behind it, this one has nothing but the session key'). It also lists three concrete preconditions for valid use: name starts with agent_, module exists (created via engine_php_add, written via engine_php_save), and is saved as an entry point (ajax_load=1).

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 available, the description carries the behavioral burden and does so well: it states that grants are not included, that the output is a zip on the local machine, and that the index.json checksums make differential comparison possible. It does not detail overwrite behavior or return values, but these are minor for a backup/export tool.

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 dense but every sentence earns its place: the first defines action and scope, the second records an important exclusion, and the third explains the comparison workflow with index.json. It is not as minimal as possible, but the extra detail is genuinely useful rather than filler.

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 tool with one optional parameter, no annotations, and no output schema, this is complete enough for an agent to select and invoke it correctly. It covers what is backed up, what is excluded, where the output goes by default, and how the backup can be used later to identify only changed files.

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 100%, so the schema already fully documents the single optional `file` parameter, including its default. The description itself repeats the destination concept ('into one zip on this machine') but adds no new parameter-level semantics beyond what the schema provides.

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 opens with a specific verb and resource: 'Back up the AI tools of this store into one zip on this machine.' It enumerates exactly what is included (registry tree, commands, fields, modules, manifests, libraries) and what is excluded (grants), making the tool's purpose unambiguous even among many sibling tools.

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?

It provides clear context: the tool is for creating a backup and later comparing it after tool updates, with index.json checksums enabling selective reading of differences. It does not explicitly name alternatives, but no sibling tool is obviously an export/backup tool, so explicit exclusions are less necessary.

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 the burden of behavioral disclosure. It does explain the two output modes and says a named unit returns 'every command with every field it takes.' However, it does not explicitly state that the operation is read-only, describe the output structure, or clarify the unexplained reference to session_connect.

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 reasonably compact at two sentences, but the prose is dense and somewhat oblique. The illustrative examples and the session_connect reference add color but also clutter. It is not poorly structured, but it is not a model of clarity.

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 tool with one optional parameter and no output schema, the description covers both usage modes and gives enough information about the returned content for an agent to invoke it correctly. It is not a 5 because the awkward phrasing leaves some room for misinterpretation about what 'answers that one tool in full' means structurally.

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 the baseline is 3. The description reinforces the optional unit semantics by saying 'Without a unit' and 'name a unit,' but it does not add material meaning beyond what the schema already states about the parameter.

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 communicates that the tool lists store-specific custom tools and can return either all of them or one full tool definition. It differentiates these from engine tools by saying 'beyond the engine.' It is not a 5 because the wording is indirect and leans on examples rather than a direct statement like 'List custom tools available in this store.'

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 explicitly explains the two invocation modes: omit the unit to list all tools, or name a unit to get that tool's full definition. This gives an agent clear guidance on when to pass the optional parameter. It does not explicitly discuss alternatives, but for this tool the mode-based 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?

There are no annotations, so the description carries the disclosure burden. It does add useful behavioral context: the store checks a registry before running, and it explains how this differs from shop_run. However, it does not disclose return semantics, side effects, failure behavior, or permission requirements, which are important for an execution-style tool with 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 definition is compact and front-loaded: the first sentence states the core purpose, and the second immediately distinguishes it from shop_run. The phrase 'the working way to do a job the owner already provided for' is slightly vague, but there is no meaningful waste.

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 complex 6-parameter executable with no output schema and no annotations, the description explains how to name units, commands, and parameters and points to tool_list. But it omits the tool's return format, failure behavior, and any session or ordering prerequisites, leaving an agent with gaps for a fully confident 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 description coverage is 100%, so the baseline is 3 and the description is not required to compensate. The prose mainly restates what the schema already says: units come from tool_list, commands must be declared, and parameters may be passed as filenames. It adds little 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?

Opens with a specific verb and object—'Run one command of a tool of this store'—and names the exact inputs: unit, command, and parameters. It is clearly differentiated from the sibling shop_run, which runs user-written modules instead, so an agent can tell the two apart without opening schemas.

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?

Gives clear context: this is the way to invoke a tool the store owner already provided, and it explicitly contrasts with shop_run. It also directs the agent to tool_list for valid units, commands, and parameters. It does not state broader exclusions or alternative conditions beyond the shop_run distinction.

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