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 well. It discloses that only one active scene exists world-wide, that the previous scene is deactivated and reported back, and that activating an already-active scene is a no-op. It also notes the GM-only permission requirement.

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: it front-loads the core action, explains global consequences, reports the no-op behavior, and routes to alternatives. 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?

For a tool with a single parameter and no output schema, the description is complete. It covers the effect on connected clients, the deactivation behavior, the no-op case, the GM-only restriction, and the sibling tools to use instead.

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 schema already documents the single parameter. The description adds value by explaining that matching is strict with no fuzzy matching, and that the value can be a scene id or exact name, which helps the agent use the parameter 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 states a specific verb and resource: activating a scene to make it the single active scene where clients land and users log in. It explicitly differentiates itself from update-scene and pull-users-to-scene, so an agent can distinguish it 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 gives explicit when-to-use guidance and names alternatives: use update-scene for document-only changes, and pull-users-to-scene for moving only some players. It also states the GM-only restriction, leaving little 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?

With no annotations, the description details additive behavior for each mode, includes caveats about unresolvedScale tokens in compendium imports and sourcing restrictions, though it could mention permanent data modification more explicitly.

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?

Well-structured with bullet points for modes, front-loads core purpose, but is somewhat lengthy due to complexity; could be slightly more concise without losing essential 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 the complexity (three modes, many parameters, no output schema), the description covers all necessary aspects including mode selection, parameter usage, sourcing rules, and caveats like unresolvedScale, making it comprehensive.

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

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

Schema coverage is 100% with detailed property descriptions; the description adds high-level organization and usage context but does not significantly enhance parameter meaning beyond the schema.

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

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

The description clearly states the tool adds features/spells/abilities to actors, outlines three distinct modes with clear explanations, and differentiates from sibling tools like add-item and import-item by explicitly recommending their use for gear.

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 guidance on when to use each mode (compendium-features preferred for official content, feature for custom authoring, items only for free-form data) and references sibling tools for gear, along with instructions to find actorIdentifier using list-actors/get-actor.

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 disclosure burden and excels: it details all permanent effects (spell becomes ALWAYS-PREPARED, cast activity lands on the granting feature, Additional Spells entry is created), the MIGRATION of the old shape off the spell, deduping of cached copies, and idempotency. The explicit 'NEVER' warning further clarifies what the tool will not do, leaving no behavioral surprises for the 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 dense with high-value information and the purpose is front-loaded before the mechanism details. Every sentence earns its place, including the migration, dedupe, and idempotency notes. However, it is a single punctuation-heavy wall of text with multiple emphasized phrases, which reduces scannability relative to a structured multi-sentence layout.

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 5-parameter tool with no annotations and no output schema, this description covers an exceptional amount: the full dual-entry mechanism, defaults, migration, dedupe, idempotency, and anti-patterns. It falls slightly short of a 5 because it does not describe what the agent will receive back after invocation (no return-value note compensates for the missing output schema), nor does it cover failure cases like a missing granting feature.

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 adds genuine value on top by explaining the end-state interplay between parameters — how spellIdentifier can be imported from the compendium and become always prepared, how grantedBy hosts the activity and names the Additional Spells entry, and how uses/recoveryPeriod default to 1/long rest. This connective tissue helps the agent reason about the parameters as a system rather than isolated fields.

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 — 'Grant cast without a spell slot, N per rest' on a D&D 5e actor via the 'native 2024 way' — with concrete examples (Magic Initiate, Favored Enemy, lineage grants). It specifies the resulting two sheet entries in detail, making it unmistakable what the tool accomplishes and clearly distinct from siblings like add-feature or manage-activity.

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 when the tool applies: granting free-cast abilities through native 2024 features and migrating the legacy shape. It includes an explicit never-do-this instruction that prevents the obvious wrong implementation. However, it never names an alternative sibling for comparison, so an agent comparing it to add-feature or manage-activity must infer the boundary from the mechanism described.

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

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

With no annotations provided, the description carries the full burden. It discloses key behaviors: 'This authors documents — it does NOT roll, equip-in-combat, or spend charges.' It notes the duplicate-name non-rejection, the lootCopy default for magic items, the wireAc effect on AC, and how magicalBonus is stored. No contradictions with (absent) 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?

Though long, the description is tightly structured with bullet-point item types, a cross-cutting section, and a target section. Every sentence carries unique information; there is no filler. The front-loading of purpose and immediate item-type breakdown makes it navigable despite 49 parameters.

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 49 parameters, nested objects, and many enums, and no output schema, the description covers every item type, parameter interaction, default, and limitation. It explains target selection, folder creation, and the distinction between world items and actor items. An agent can invoke it correctly without external reference.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning beyond field names. It explains cross-cutting interactions (e.g., 'Setting magicalBonus/magical adds the mgc flag', 'wondrous items have no +N field'), per-item-type defaults, and conditional behaviors like wireAc applying only to body armor. This is far more than 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 precise verb-resource pair: 'Create a structured physical item (loot/gear) on an actor or in the world Items sidebar.' It enumerates all item types and explicitly differentiates from siblings like add-feature, create-item, and import-item by naming them and stating the distinctions.

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: 'For features/attacks-as-abilities use add-feature; for free-form system data use create-item / add-feature. To COPY a real item from a compendium (keeps art + stats), prefer import-item.' It also explains the duplicate-name behavior difference from add-feature, and clarifies the actor vs world-item target choice.

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 burden. It discloses the default GM-only visibility and how to make it a handout, but does not explain error handling, return value, or side effects like image validation.

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

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

The description is two sentences, front-loaded with the action, and contains no fluff. Every sentence adds value.

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

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

Without an output schema, the description should ideally mention return value or success confirmation. It does not. Given moderate complexity and good schema descriptions, the description is minimally complete but lacks closure on what the agent can expect back.

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%, baseline 3. The description adds context like 'Data-relative path' and 'defaults to file name' but largely duplicates schema descriptions. It does not significantly enhance parameter understanding beyond the schema.

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

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

The description clearly states the tool appends an image page to a journal entry, specifies the input (Data-relative image path) and optional caption, and distinguishes from siblings like create-journal or update-journal.

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 (append image to existing journal) and mentions GM-only vs. player-visible as a key consideration. However, it does not explicitly state when to prefer this over alternatives or what prerequisites exist (e.g., journal must 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 provided, the description carries the full burden. It discloses that the tool creates a real embedded document (write operation), performs validation against registered behavior types, resolves destination UUIDs for teleporters, and warns about off-grid landing pads (silent teleport no-op). It also states GM-only access. It does not mention return values or error conditions, but the provided behavioral traits are substantive and beyond what schema implies.

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 four sentences and each one earns its place: purpose and distinction, creation validation, teleporter behavior, access restriction. It is front-loaded with the core purpose. While slightly dense, it avoids fluff and remains efficient for a tool with this complexity.

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 complexity (14 params, nested objects, type-specific behaviors) and the rich schema, the description provides the essential high-level context: existing-region scope, sibling distinctions, validation, teleporter convenience and warning, GM-only. It does not explain outputs, but no output schema exists and it is a create operation. The schema covers parameter details, making this description adequately 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 100%, so the schema already documents all 14 parameters thoroughly. The description adds minimal extra parameter semantics beyond what the schema provides (e.g., the teleporter workflow is also explained in the teleportTo property description). Baseline 3 is appropriate; the description does not need to compensate.

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 begins with 'Add ONE behavior to an EXISTING region', clearly stating the action, resource, and scope. It distinguishes this tool from create-region and update-region by explaining what they do not do, and specifies it creates a 'RegionBehavior embedded document' validated against registered types. This allows an agent to identify the tool's purpose 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?

The description explicitly states when to use this tool vs. alternatives: create-region only offers behaviors at creation time and update-region deliberately never touches them. It also gives a specific usage pattern for teleporters and notes the GM-only restriction, providing clear context and exclusion 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 burden and does well: it discloses D&D 5e-only scope, active=false toggling removal, leveled exhaustion, token-instance behavior, and that this authors state rather than automating combat. Missing permission/reversibility details, but strong overall.

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?

Compact and well-structured: purpose first, then key modifiers, then an explicit non-goal, then a lookup hint. Every sentence adds value without 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?

Covers operation, removal behavior, exhaustion special case, token-id nuance, and how to find the required identifier. No output schema exists, but for a state-mutating tool the return value is not essential for correct selection or 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 every parameter is already documented. The description reinforces active=false and exhaustionLevel semantics but does not add meaning beyond what the schema already 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?

States a specific verb and resource: 'Apply or remove one or more conditions on an actor,' with concrete condition examples. It also distinguishes itself by explicitly saying it is NOT a combat-automation loop, helping an agent separate it from related effect/combat 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?

Gives explicit when-not guidance: no duration countdown or save-ends handling, and directs the user to list-actors or get-actor to find the actorIdentifier. It does not name a specific sibling tool for automation, but the exclusion is clear enough for 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 provided, the description is the sole source of behavioral details. It states read-only nature (Plane B, file channel, read-only) and lists returned attributes. However, it does not address error states (e.g., path not found) or behavior for directories beyond 'for files' note, leaving some gaps.

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

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

The description is extremely concise: two short sentences that front-load the core purpose and usage context. Every phrase earns its place with 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?

Given the tool's simplicity (1 parameter, no output schema, basic annotations), the description is largely complete. It explains what the tool returns, when to use it, and the read-only nature. Minor gaps (error handling, directory behavior) prevent a perfect score.

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%, and the input schema already fully describes the parameter including the relative path root. The tool description adds no new meaning beyond the schema, so baseline score of 3 applies.

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: checking existence and retrieving metadata for a single path under Foundry's Data/ root. It distinguishes from siblings like list-assets by emphasizing it's a cheap, single-path check before uploads or linking.

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 includes explicit guidance: 'A cheap existence/metadata check before uploading or linking.' This tells the agent when to use it, but does not explicitly list when not to use it or mention alternative 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?

The description explicitly states 'Pure mapping (no network)', indicating no side effects or network calls. This transparency is crucial as no annotations are provided. The behavior is fully disclosed without 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?

Three concise sentences: introduction, mapping explanation, and use case. No redundant information; every sentence adds value.

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

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

For a simple tool with one parameter, no output schema, and no annotations, the description is fully complete. It covers functionality, behavior, input format, and usage context.

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

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

The schema has 100% coverage for the single parameter 'remotePath', describing its format. The description adds minimal extra value by mentioning the mapping rule, but it largely repeats schema content, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'return' and the resource 'public HTTPS URL for a file under the Foundry Data/ root'. It distinguishes from siblings by specifying it is a pure mapping (no network call) for generating URLs, contrasting with tools like download-asset.

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 converting asset paths to loadable links (e.g., 'Useful for turning an uploaded/known asset path into a link Foundry or a player can load'), but it does not explicitly compare with alternatives or state when not to use. No exclusions are provided.

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 burden. It clearly implies creation of a new actor, lists required and optional parameters, and suggests follow-up actions (add-feature, import-item). It doesn't explicitly state side effects or authorization needs, but the creation context is clear and non-destructive.

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 purpose and usage guidelines, then lists required and optional params. It is somewhat lengthy due to comprehensive parameter coverage, but every sentence adds value. Could be slightly more concise without losing 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?

Given 35 parameters, no output schema, and no annotations, the description addresses the core purpose, usage context, all required params, and many optional ones. It also provides post-creation guidance (add-feature, import-item). Missing return value description, but the creation context makes that less critical.

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 extensively explains each parameter's meaning and usage. It provides examples (e.g., cr as number or fraction), clarifies default behaviors (e.g., disposition default 'hostile'), and links parameters to game concepts (e.g., 'friendly for allies/townsfolk'). This adds significant value beyond the schema.

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

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

The description clearly states the tool authors a custom NPC from a stat block, specifies it's a last-resort path, and distinguishes from compendium-based creation. The verb 'author' and resource 'custom NPC' are precise, and the 'LAST-RESORT' label immediately clarifies its 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?

Explicitly states when to use ('used ONLY when nothing in the premium MM/PHB/DMG books is a workable base'), when not to use (prefer create-actor-from-compendium), and provides explicit guidance to ask the user before authoring. Also recommends 2024 ruleset and lists required fields.

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?

Highlights permanence, irreversibility, strict resolution, and GM-only requirement. Without annotations, the description fully compensates with critical 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?

Three succinct sentences, front-loaded with key information. Every sentence adds value with no 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?

No output schema, but description explains what is deleted, irreversibility, and how to preview. Covers all necessary context for a bulk delete 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?

Schema coverage is 100%. The description adds context beyond schema: 'exact id or name' for identifiers, 'single type' for documentType, and dry-run recommendation. One point above baseline due to helpful extra detail.

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 deletes many world documents by exact ID or name, specifying strict resolution and a single type. It distinguishes from sibling 'delete-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?

Explicitly suggests using dryRun first, directs to delete-folder for folders, and notes GM-only restriction, providing clear when-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 provided, the description carries the full burden and does well: it discloses the read-versus-write nature, the echo of previous→new for changed fields, the no-op behavior for re-applying current values, and the GM-only permission. It does not explicitly state that changes persist to the world config or describe error handling for invalid values, but those are partially covered by the schema and the overall context is 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 three sentences, front-loads the core purpose, and packs essential usage directives (no-arg read, echo, no-op, GM-only) without redundancy. Every sentence earns its place and there is no 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?

Given the nested turnMarker object, three optional parameters, no output schema, and no annotations, the description covers the key context an agent needs: how to read, what fields are configurable, the no-op guarantee, and access restrictions. It does not describe the exact output shape, but it names what the read returns (current config and valid animation ids), which is sufficient for a first call. Slightly more detail on error behavior would push it to a 5, but 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?

Schema coverage is 100%, so the baseline is 3. The description adds a conceptual grouping of the three parameters (turn marker, resource, skip-defeated) and explains the read-mode behavior with no arguments, but it does not significantly deepen parameter-level meaning beyond what the schema already provides. It meets the baseline but does not exceed it.

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 (read or configure), the exact resource (the world's core.combatTrackerConfig setting), and the three configurable areas (turn marker, tracked resource, skip-defeated). It distinguishes this tool from any sibling by naming its unique setting; no other sibling tool covers combat-tracker configuration.

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 with no arguments (to read) and clarifies that re-applying the current value is a no-op, which prevents redundant writes. It also states the GM-only access restriction. It does not mention alternatives, but no sibling tool is a direct alternative, so this is not 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers: it states that changes echo previous → new, re-applying is a no-op, certain switches require a client reload (and names them), the tool is GM-only, and it is allow-listed to automation settings only. This goes well beyond a bare CRUD statement.

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?

Although the description is long, it is dense and front-loaded: it states the verb, scope, and key usage pattern in the first sentence, then enumerates categories, behavior, and constraints. Every sentence adds operational value, and no filler or repetition is present.

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 21-parameter configuration tool with no output schema and no annotations, the description covers everything needed for correct invocation: read vs. set behavior, no-op semantics, reload requirements, GM-only restriction, and the exact allow-listed scope. The schema covers per-parameter defaults and enums, so the combination is 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 100%, so the baseline is 3 even if the description adds no per-parameter details. The description groups the settings into categories and explains global behavior, but it does not add meaning beyond the already-rich schema descriptions for individual parameters. This meets the baseline without exceeding it.

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 pair (read/set), a specific resource (dnd5e 6.0 AUTOMATION settings), and enumerates the exact categories involved. It also distinguishes itself from the broader settings menu by stating 'Allow-listed: nothing else in the settings menu is reachable,' so an agent can separate it from siblings like manage-calendar or configure-combat-tracker.

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 call patterns: call with NO arguments to read every switch, pass any argument to change it, and re-applying the current value is a clean no-op. It does not explicitly name alternative tools or exclusion cases, but the read-vs-write usage is clear enough for correct selection and invocation.

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 present, the description carries the full burden and delivers: out-of-range values are CLAMPED and reported, audio paths are HEAD-checked with 404s kept and warned about, and missing/disabled modules produce a warning instead of a fake success. It also discloses that updates replace whole pools on `files`, that `remove` accepts 'all', and that the tool is GM-only.

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 long but every sentence earns its place; it is front-loaded with the core purpose and module context, then moves compactly through actions and behavioral caveats. For a 20-parameter tool with no annotations, this density is appropriate and well organized.

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 complexity, full schema coverage, and no output schema, the description is complete enough: it covers all five actions, default scene selection, clamping, file verification behavior, module-dependency warning behavior, and key edge cases. An agent has what it needs to invoke the tool correctly and interpret non-2xx outcomes.

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

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

The input schema already documents every parameter at 100% coverage, so the baseline is 3. The description adds real value on top by explaining action-specific behavior ('update' patches named fields only while `files` replaces the whole pool, 'remove' takes one set or 'all'), clarifying template-name ambiguity via `section`, and warning that a duplicate set name is an error. It doesn't materially change parameter meaning beyond that, though the cross-parameter guidance is strong.

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 — 'Author a scene's atmospheric SOUND SETS' — and immediately explains the module's niche: randomized pools of small audio files with silence, or crossfaded beds. It distinguishes itself from AmbientSound placeables and Playlists, so an agent can tell it apart from sibling sounds tools without inspecting 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?

It states exactly when this tool is the right choice: core Foundry cannot do pools with silence or crossfaded beds, and explicitly rules out single-file positional AmbientSound placeables and Playlists as non-covering alternatives. It also gives operational conditions such as defaulting to the ACTIVE scene, strict scene identifiers, and GM-only access.

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 and does so well: it declares read-only behavior, D&D 5e-only scope, the specific rules scanned, and a scope caveat that NPC biographies are not scanned for rule 12. It loses a point because it says 'five strict authoring-quality rules' but lists only four bullets, and it never describes the shape of the violation report.

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 long but tightly structured and front-loaded: purpose and safety first, then a scannable bulleted list of rules, then usage trigger and targeting semantics, then concrete remediation steps. Every sentence earns its place, and the length is justified by the number of distinct rules and options an agent must understand.

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, zero-annotation tool with no output schema, this is unusually complete: it names all scan rules, distinguishes player-visible item descriptions from GM-facing NPC biographies, describes full-sweep behavior, and tells the agent how to fix findings. The main missing piece is the exact return/report structure, which would help an agent consume and act on the results automatically.

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

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

The input schema already describes all three parameters fully, so the baseline is 3. The description adds operational meaning beyond the schema: actorIdentifiers refers to the NPCs just built with their gear/features, itemFolders maps to the loot folder, and omitting all targets triggers a full sweep. This is enough to move above baseline, though the schema already covers the literal parameter meanings.

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-resource pair: 'scan documents for the five strict authoring-quality rules and report violations to fix,' and immediately disambiguates it from mutation tools with '(read-only; never mutates)'. It enumerates the exact rule categories, so an agent can clearly tell this audit tool apart from the many update/fix siblings in the namespace.

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 an explicit trigger: 'RUN THIS before declaring a build done.' It explains the targeting modes — 'Target what you built' with actorIdentifiers, itemFolders, or worldItemIds — and the no-target full-sweep behavior. It also names follow-up fix tools, giving the agent a clear workflow instead of leaving usage 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 provided, so the description carries the burden. It discloses automatic parent folder creation, no effect on references, and path restrictions. It also signals it is a write operation ('Plane B (file channel, write)'). Could be improved by mentioning error handling for overwrite=false.

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 plus a parenthetical and requirement note. It is front-loaded with key context ('Plane B (file channel, write)') and every sentence adds essential 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?

Given no output schema and 3 parameters, the description covers core behavior well. It lacks details on whether folders can be copied (only files are implied). Also does not specify return value. However, it is fairly complete for a file copy 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 coverage is 100%, baseline 3. The description adds value by explaining that missing destination parent folders are created automatically (relevant to toPath). This goes beyond the schema's description. No additional info for fromPath or overwrite, but sufficient.

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 copies a file under Foundry's Data/ root. It specifies the file channel (Plane B write), mentions automatic parent folder creation, and distinguishes from world-DB operations. The verb 'Copy' and resource 'file under Data/ root' are specific and 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 implicitly tells when to use (to copy files within Data/ root) and includes important constraints (refuses live world-DB paths, requires MOLTEN_WEBDAV_PASSWORD). It does not explicitly name alternatives like move-asset, but the context of copying vs moving is clear.

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

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

The description discloses key behavioral traits: it modifies only the copy, never the source entry, and can layer modifications in the same call. It also explains folder creation behavior. Since annotations are absent, the description carries the burden, and it does a good job of revealing the non-obvious aspect of modifying only the world copy.

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 detailed and comprehensive, but it is relatively long. It uses clear formatting with dashes and section headers, which aids navigation. It front-loads the core purpose and main parameters, and then provides secondary context. It earns its length due to the complexity of the tool, but a few sentences could be tightened without losing 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?

Given the tool's complexity (9 params, nested objects, multiple modes), the description is exceptionally complete. It covers the entire workflow: search, copy, and modify. It explains the difference between creating actors and placing tokens, and clarifies the disposition parameter. No output schema exists, but the description implies the result (created actors) without needing to detail return values.

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 100% description coverage, so the baseline is 3. The description adds value by clarifying the relationship and usage of the modifications, folder, and names parameters, especially the PREFAB-AS-BASE bridge requirement and the relationship between placement and addToScene. It explains that quantity is defaulted based on names length, which is not 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?

The description clearly identifies the tool's purpose: copying actors from premium-book compendium packs. It explains the process of finding the entry, passing the packId, itemId, and names, and highlights that it is the default preferred path for official content. It also distinguishes itself from author-npc for hand-authored NPCs.

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: for premium-book compendium content, and explicitly states that it is the preferred path. It references the alternative author-npc as a last resort for fully hand-authored NPCs, and mentions the PREFAB-AS-BASE bridge for custom creatures. This gives a clear decision framework.

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?

Discloses idempotency, requirement for MOLTEN_WEBDAV_PASSWORD, refusal of live world DB paths, and creation of missing parents. Lacks details on return values or error responses, but overall sufficient given no annotations.

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

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

Two concise sentences plus a requirement note, all front-loaded with key identifiers ('Plane B'). No wasted words.

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

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

Covers idempotency, constraints, and requirement. The 'Plane B' term is unexplained, and no output description is given, but for a simple creation tool with no output schema, it is fairly complete.

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

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

The single parameter 'remotePath' is described in schema with an example, and the description adds that missing parents are created. This exceeds the schema alone. No further parameter details needed.

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

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

The description clearly states the tool creates a folder under Foundry's Data/ root over WebDAV, is idempotent, and has specific constraints (refuses live world DB paths). It distinguishes itself from sibling tools like 'create-folder' by specifying the 'Plane B (file channel, write)' 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?

Provides clear context: use for creating folders via WebDAV, idempotent, and warns against live world DB paths. However, no explicit comparison to similar sibling tools (e.g., 'create-folder') is given.

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 burden. It discloses GM-only permission requirement, the optional folder creation, and the structure of cards (face text/img vs plain). This is good behavioral coverage for a creation 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 sentences with key information front-loaded. First sentence covers primary action and scope; second adds card structure; third provides use cases and permission. No wasted words.

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

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

Given 5 parameters, high schema coverage, and no output schema, the description sufficiently covers creation behavior, card structure, and use cases. It lacks error/edge-case details but is adequate for typical 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?

Schema coverage is 100%, baseline 3. The description adds value by explaining `text` as HTML shown on the card, `img` as Data-relative path, `description` as GM/meta note, and `folderName` behavior. This context is beyond the 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?

The description clearly states it creates a Cards stack (deck, hand, or pile) with optional initial cards, specifying the verb and resource. It distinguishes from siblings like list-cards, delete-cards, and import-cards by focusing on creation for custom themed decks.

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 advises use for custom themed decks and notes GM-only, providing clear context. It does not explicitly exclude other scenarios, but the sibling set is large and the purpose is well-defined.

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 fully discloses behavioral traits: it creates drawings, supports per-drawing error isolation, returns created IDs, and is GM-only. It explains default stroke behavior and flags like hidden/interface. 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 moderately concise given the complexity; it front-loads the purpose and covers key parameters efficiently. A minor reduction in verbosity could improve clarity, but it is well-structured.

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

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

The description covers usage, parameter details, behavior (error isolation, GM-only), and return value (created ids). For a tool with many parameters and no output schema, it 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 100%, and the description adds value by explaining the coordinate origin (top-left absolute), shape type specifics, and default styles (e.g., 'default stroke makes a bare shape visible'). This enriches the schema definitions.

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

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

The description clearly states it places DRAWINGS (GM annotation shapes) on a scene, enumerating shape types, coordinate system, styling options, and special flags. It distinguishes itself from siblings like create-tiles or create-lights by specifying the exact use case (secret-area boxes, trap outlines, zone labels).

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 GM-only annotations and mentions per-drawing error isolation, but does not explicitly state when to use this tool over alternatives like create-tiles or create-lights. The context of sibling tools is not directly addressed.

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

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

No annotations provided, so description carries full burden. It discloses GM-only permission, creation of sidebar folders, and nesting constraint. Does not detail error handling or side effects, but for a simple create operation this is 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?

Two concise sentences with no filler. Purpose is front-loaded, critical details (nesting, GM-only) are included. 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?

Simple tool with no output schema. Description covers what it creates, how it can be used (nested, for organizing), and who can use it. Sufficient for an agent to select and invoke 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% with descriptions for all 4 parameters. Description reinforces nesting constraint for parentFolder but adds no new meaning for other parameters like color. Baseline 3 is appropriate.

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

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

Description explicitly states it creates sidebar folders for any world document type, with optional nesting. It distinguishes from create-* siblings (which create documents) and includes usage context ('organize generated content') and visibility ('GM-only').

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?

States 'organize generated content' and 'GM-only', providing clear context. However, it does not explicitly say when not to use or mention alternatives (e.g., deleting folders via delete-folder). Still, the sibling list implies the tool is for folders only.

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, and it delivers: fail-closed member resolution ('one bad name and nothing is created'), default ownership semantics, and the optional global primaryParty side effect. It doesn't mention permissions or return shape, but the most important behavioral traits are disclosed.

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 sentences with no filler: purpose, capabilities, failure mode, and follow-up step. Each sentence earns its place, and the most identifying information 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?

For a 9-parameter creation tool with no output schema and no annotations, the description plus rich schema covers purpose, failure atomicity, side effects, and next steps. It doesn't state return values or auth prerequisites, but an agent has enough to select and invoke 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?

Schema description coverage is 100% and every parameter already has a detailed description, so the baseline is 3. The description reinforces the fail-closed members behavior and the 'owner' default ownership meaning, but doesn't add unique parameter detail 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 opens with a specific verb and resource — 'Create a dnd5e GROUP actor (type:group)' — and immediately clarifies its purpose as the shared party stash / travel group. This clearly distinguishes it from sibling actor-creation tools like create-pc or author-npc.

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 'shared party stash / travel group' phrasing gives a clear use case, and the closing sentence explicitly routes subsequent inventory work to add-item / import-item. It doesn't exhaustively list when-not cases, but the context is strong enough for an agent to select it correctly.

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 discloses key behaviors: world-level creation, GM-only access, preference for 2024 data model, and the role of the 'system' field. Lacks details on failure modes or duplicate handling, but covers essential aspects.

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?

Multi-sentence but efficient; front-loads the core action then provides alternative guidance. Every sentence serves a purpose, though could be slightly more concise.

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 2 parameters and no output schema, the description covers creation scope, target audience, data model preference, and alternatives. No significant 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 100% and the description adds meaningful context: explaining the purpose of the 'system' field, noting valid types, and setting usage scope. Adds value 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?

Clearly states the verb 'Create', the resource 'world-level Item document(s) in the Items sidebar', and enumerates the types of reusable library items. Distinguishes from sibling tools by listing alternatives for actor-level operations.

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?

Explicitly states it is GM-only and provides clear guidance on when not to use it ('To put items on an actor instead...') with named alternatives (import-item, add-item, add-feature).

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

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

No annotations provided, so description carries full burden. It explains behavioral traits like GM-only default, page visibility (playerVisible), folder creation, and page types. However, it does not mention idempotency or error conditions, but overall provides good context beyond 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?

Four sentences, front-loaded with purpose, then details page types, differentiates from sibling, and covers folder and visibility. Every sentence adds value; no redundant 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?

Given no output schema and high schema coverage, description covers key aspects: creation of journal, page types, folder option, and visibility. It misses explicit mention of default page kind (text) and return value, but is complete enough for a creation tool with good parameter documentation.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining the distinction between text and image pages, the requirement of src for images, the optional caption, and the meaning of playerVisible. This goes beyond schema descriptions.

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

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

Description clearly states it creates a multi-page JournalEntry from supplied pages. It distinguishes from sibling 'create-quest-journal' by noting it takes explicit pages and only folders when folderName is given. The verb and resource are specific.

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?

Explicitly contrasts with sibling tool 'create-quest-journal', stating that this tool is for generic journals with explicit pages, while the sibling has styled blocks and auto-folders. This gives clear when-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 provided, the description fully discloses behavioral traits: units for x/y and radii, darkness activation range, walls/vision effects, per-light error isolation, return of created ids, and GM-only restriction. It adds context beyond the schema, such as 'NOT pixels' and 'torch only lights once the scene dims'.

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 paragraph of moderate length (approx. 100 words) that front-loads purpose and then details parameters. It is packed with information but remains readable; however, it could be slightly more structured (e.g., bullet points) for even easier scanning.

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 (nested array, many optional parameters, no output schema), the description covers main behaviors, parameters, and outcomes (returns created ids). It mentions per-light error isolation but could elaborate on what that entails. Overall, it is fairly complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra meaning beyond the schema: clarifies units for dim/bright (grid-distance units, NOT pixels), gives examples for animationType (torch, flame, pulse), and mentions default values (alpha ~0.3, luminosity 0.5, darknessMin ~0.1). This adds significant value.

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 'Place' and the resource 'AMBIENT LIGHTS', with specific examples (torches, braziers, magical glows). It distinguishes from sibling tools like create-drawings or create-tiles by focusing exclusively on light sources, and notes it is GM-only.

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 implicitly indicates usage for placing ambient lights on a scene. However, it does not explicitly state when not to use or provide alternatives, relying on the sibling list for distinction. This is clear but lacks explicit 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 and does it well: scripts run as the clicking user, chat macros post text, owner/hotbar permissions are granted, and the call is GM-only. The only behavioral detail left to the schema rather than the description is the occupied-hotbar-slot replacement warning.

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?

Dense but efficient: it front-loads the core purpose, packs the type behavior and example into one sentence, then covers optional ownership and hotbar pinning. The GM-only constraint closes it with no wasted words.

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

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

For a 7-parameter creation tool with no output schema, the description covers required inputs, defaults, side effects, permissions, and a realistic example. It does not spell out every schema edge case, such as invalid image replacement, but those are in the schema and the high-level flow is fully actionable.

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

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

Schema coverage is 100%, and the schema already explains the owner/hotbarUser relationship, command behavior, defaults, and image fallback. The description gives a helpful overview and an example but adds little parameter-level information beyond what the schema provides, so baseline 3 is appropriate.

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

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

Opens with a specific action and resource: 'Create a world Macro — a hotbar button.' It immediately distinguishes the two macro types and explains what they do, and it sits cleanly apart from siblings like list-macros and delete-macro by focusing on creation plus optional hotbar pinning.

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?

States the intended use ('the way to hand a player a one-click ability') and adds the hard constraint 'GM-only.' It does not explicitly mention alternative tools for inspecting or deleting macros, but the creation context and permission boundary are clear enough.

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 fully discloses behavior: it runs real advancement, does not persist on failure (success:false with errors), returns detailed output fields, and explains the dry-run behavior. It also clarifies that ASI ability-increases are expected final and feats are not added by this tool, ensuring no surprises.

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 long but well-structured, with front-loaded main purpose and progressive details. Every sentence adds value, covering all key aspects. Minor verbosity is justified by the tool's complexity, but it could be slightly more terse without losing 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?

Given the complexity (13 parameters, nested objects, multiclass, dry-run, error handling) and no output schema, the description is fully complete. It explains the return value structure, the multi-step workflow, edge cases like missing class or failed advancements, and provides enough detail for an AI agent to use 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?

Despite 0% schema description coverage, the description explains the purpose and usage of most parameters: name, className, level, abilities (final scores), choices (with structure), multiclass, spells, hpMode, sourceRules, acceptDefaults. It adds critical context like 'abilities must be final' and 'choices map format', compensating fully for the missing 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?

The description clearly states it builds a player character headlessly using premium compendium content, with real dnd5e advancement and native scale feature resolution. It distinguishes itself from NPCs and sibling tools like 'create-pc-from-prefab' and 'level-up-pc' by detailing its specific functionality, such as dry-run mode and multiclass support.

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 extensive usage guidance: it explains the two-step process (dry-run then fill choices), what inputs to provide (final abilities, choices map, multiclass array), and what not to include (gear, ASI-feats). It also specifies constraints like premium books only and error handling. However, it doesn't explicitly compare with sibling tools or say when to choose this over alternatives.

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 fully bears the burden of behavioral disclosure. It reveals that the tool copies the source (never modifies the original), applies modifications to the copy, resolves @scale natively, and does not set ownership (requires a separate step). It also specifies the return shape. This is a complete and honest description of the tool's behavior.

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

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

The description is moderately concise at around 150 words, packing essential information without significant fluff. It is well-structured: purpose first, then method, resolution, overrides, behavioral notes, and returns. However, some sentences are long and dense, which slightly reduces readability. Minor improvements could make it more streamlined.

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 (7 parameters, nested objects, no output schema, no annotations), the description is quite comprehensive. It covers the core workflow, constraints (premium only), resolution options, and return structure. The main gaps are the lack of explanation for the 'folder' parameter and the exact shape of 'modifications'. Still, it provides enough context for correct usage.

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

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

Despite 0% schema description coverage, the description adds substantial meaning to several parameters: it explains how 'prefab' resolves (by name or explicit packId+actorId), what 'abilities' expects (array of final scores), and what 'modifications' are (update-actor-shaped updates applied to copy). 'folder' and other basic parameters are not elaborated, but the critical ones are covered. It compensates well 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?

The description clearly states the tool's purpose: creating a player character by copying a premium-book pregen template. It uses specific verbs ('Create', 'COPYING', 'layering'), identifies the resource (premium-book PREGEN), and distinguishes this approach from building via advancement. It also contrasts with create-actor-from-compendium for NPCs, making the purpose 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 explicitly tells when to use this tool: for creating a PC from a pregen template instead of advancement. It provides guidance on source resolution (by prefab name or packId+actorId), specifies that premium books only are allowed (never SRD), and mentions a follow-up step (set-actor-ownership). It also implies when not to use it (if not using a pregen or using SRD). This is comprehensive.

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

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

No annotations provided, so description carries full burden. Mentions creation and modes, but lacks details on side effects, error handling, or dependencies (e.g., valid paths). Adequate but not comprehensive.

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 concise sentences; first states purpose, second adds modes and restrictions. No redundant information, 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?

No output schema, so expected return value (created playlist) is not described. Lacks error conditions or prerequisites. Adequate for a creation tool but could be 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?

Schema coverage is 100%, baseline 3. Description adds context for soundPaths (data-relative paths) and lists modes, enhancing understanding beyond schema descriptions.

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

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

Clearly states 'Create a Foundry Playlist from a list of Data-relative sound paths' with specific verb and resource. Distinguishes from sibling tools like update-playlist and delete-playlist.

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?

Explicitly states 'GM-only' for authorization and references typical use case with upload-asset. Could be more explicit about when not to use vs update-playlist, but implied by the create verb.

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: it never writes the prose, renders in house style, sets per-page visibility. Without annotations, it provides good transparency, though could include details on error handling or limits.

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 well-structured and front-loaded with key information, but slightly verbose in listing block types; still clear and efficient.

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

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

Given the tool's complexity (multi-page journal with multiple block types), the description covers purpose, usage, block types, visibility, and alternative tool, making it 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 100%, and the description adds value by summarizing the block types, explaining the structuring role, and clarifying visibility vs 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?

The description clearly states the tool creates a multi-page journal from structured typed blocks, and distinguishes it from the sibling tool 'create-journal' which handles plain raw-HTML pages.

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 when to use this tool (for structured blocks) and when not to, providing the alternative 'create-journal' for plain raw-HTML pages.

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 behaviors pass through verbatim, that teleportToken requires pre-existing system.destinations, that shapes are carried whole, and that the tool is GM-only. It also states the return value (created region ids). This is substantial behavioral disclosure beyond 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-structured, front-loading the core purpose and then adding necessary caveats. Every sentence earns its place, though the parenthetical about v14 shapes and the teleportToken explanation make it slightly long. Still, it is efficient for the complexity it covers.

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 key context: prerequisites, alternatives, GM-only restriction, return value, and shape/behavior semantics. It could mention error cases or what happens if the scene is not found, but overall it is complete enough for an agent to invoke 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%, so the baseline is 3. The description adds meaning by explaining that shapes are carried whole in canvas px, that behaviors pass through verbatim, and that teleportToken needs system.destinations already set. It also clarifies the visibility values and the sceneIdentifier format. This goes beyond the schema's field 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?

The description clearly states the tool creates one or more Regions on an existing scene, and explicitly distinguishes it from create-teleporter and add-region-behavior. It names the resource (Regions), the action (create), and the context (existing scene), making it easy for an agent to select correctly.

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 when-to-use guidance: use create-teleporter for the two-new-region convenience, and add-region-behavior to wire a behavior onto an existing region. It also states the prerequisite that a teleportToken must already have system.destinations set, and notes GM-only access. This is strong routing and 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 provided, the description carries the full burden and delivers: it discloses premium-book-only refs, that SRD refs are refused, that ranges are auto-assigned from weights, that the formula defaults to 1d<total weight>, and that results render as clickable @UUID links. Failure/error behavior and the return contract are not covered, but the disclosed behaviors go well beyond a typical create stub.

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 information-dense sentences with the core action front-loaded. The premium/SRD restriction, auto-assignment behavior, defaults, and use case each earn their place; no words are wasted.

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 7-parameter create tool with no annotations and no output schema, the description plus a 100%-covered schema give an agent everything needed to construct valid results (text/uuid rules, weights, ranges, GM-only authorization). The only real gap is the return value, which is not described in either the description or the schema.

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

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

Schema coverage is 100% and the schema already documents the formula default and range auto-assignment, so the baseline is 3. The description adds cross-parameter semantics — how literal text and/or uuid combine per result and how weights drive range mapping — which adds value beyond the individual parameter 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?

Leads with a specific verb+resource ('Create a RollTable from a list of results'), names the input form (a list of results) and the target use (random encounter/loot/rumour/treasure tables). This distinguishes it from siblings like create-cards, import-rolltable, and update-rolltable.

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?

'Use for random encounter/loot/rumour/treasure tables' is explicit when-to-use direction, and the GM-only constraint adds a clear authorization guard. It doesn't name alternatives or negative cases (e.g., when to prefer import-rolltable over this), so it stops one step short of full 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, the description carries full responsibility for behavioral disclosure. It reveals several non-obvious behaviors: width/height auto-detection, folder creation when absent, automatic navigation thumbnail generation, sidecar import normalization from legacy to v14, and the distinction between DM-only and player-visible scenes. This goes well beyond a simple 'creates a scene' and helps the agent anticipate side effects.

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

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

The description is a single dense paragraph, but it is well organized: core action first, then key behaviors, optional settings, and finally the import caveat. Every sentence adds value, though the length borders on overwhelming. Splitting into a few sentences would improve scannability, but it remains appropriately sized for a tool with this many features.

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 large parameter count (30) and the lack of an output schema or annotations, the description covers the critical aspects: what the tool creates, how it behaves by default, how to import supplementary data, and access restrictions. It does not mention what the tool returns after creation, which is a minor gap, but the schema's per-parameter documentation fills in the remaining details. Overall, an agent has enough to decide when and how to 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 already describes all 30 parameters in depth (100% coverage). The description adds high-level semantic context that the per-parameter entries do not: auto-detection of width/height, folder creation, thumbnail auto-generation, and the sidecar import workflow. This supplements the schema rather than repeating it.

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-resource pair ('Create a Foundry Scene from a Data-relative background image path') and goes on to list concrete behaviors (auto-detection, folder placement, thumbnail generation) that distinguish it from sibling tools like update-scene or create-walls. It is immediately clear what the tool does and what it is for.

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 strong usage context: it is for creating a new scene from an image, with optional import of walls/lights from a sidecar, and states 'GM-only' as an access constraint. It does not explicitly name alternative tools (e.g. 'for editing an existing scene use update-scene'), so exclusions are implied rather than stated, but the intended use case is clear.

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

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains deterministic behavior, error isolation per note, that GM-only secrecy is from journal ownership not the pin, and that 'global' only controls fog occlusion. It also states the return value (each created note id). 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 single paragraph that front-loads the main purpose and then provides essential details. Every sentence adds value. It is concise but could be slightly better organized (e.g., separate sections for usage, behavior, return). Still, it is efficient.

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

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

Given no annotations, no output schema, and nested input (notes array), the description covers purpose, parameters, error handling, and return. It is mostly complete, though it lacks details on error behavior for unresolved scene identifiers. Overall, it provides sufficient context for an AI agent.

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 baseline is 3. The description adds meaningful context beyond the schema, such as referencing 'get-scene-dimensions' for padding-aware math and clarifying the 'global' parameter's role. This enhances understanding.

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 ('Place map-note PINS on a scene') and the resource (linked to a JournalEntry), and distinguishes it from siblings by calling it 'the deterministic half of the legend→GM-room-pins feature'. It is specific and informative.

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 on how to use the tool, including guidance on x/y coordinates referencing 'get-scene-dimensions', per-note error isolation, and the meaning of the 'global' parameter. However, it does not explicitly mention when not to use this tool or suggest alternatives.

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 fully discloses behavioral traits: x/y are absolute canvas pixels, radius is in grid-distance units, optional parameters like walls (muffle through walls), easing (fade by distance), darkness activation range (night-only sounds), listener effects (baseEffect/muffledEffect), and that a 404 path warns but keeps. It also states the return behavior ('Returns created ids').

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 paragraph that is both comprehensive and concise. It front-loads the main purpose and example, then covers essential details without unnecessary fluff. Every sentence adds value.

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

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

Given the tool's complexity (many optional parameters, nested array input, no output schema), the description covers all critical aspects: input structure, key unit distinctions, behavior of each option, and return value. It is complete without needing an output schema.

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 significant meaning beyond the schema: clarifies units for radius (grid-distance vs. pixels), explains the purpose of walls, easing, darknessMin/darknessMax, baseEffect/muffledEffect, and default values (volume 0.5, repeat false). This enriches the agent's understanding.

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 'Place one or more positional AMBIENT SOUNDS on a scene' and provides concrete examples (crackling hearth, waterfall). It distinguishes from a sibling tool by noting 'Distinct from a scene playlist: this is a point emitter players walk into.' This leaves no ambiguity about the tool's purpose.

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 marks the tool as 'GM-only' and mentions that a 404 audio path 'keeps the path but warns'. It contrasts with scene playlist implicitly, but does not provide extensive when-to-use/when-not-to-use guidance. Still, the context is clear enough for an agent to decide.

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, and it delivers: trigger placement, grid snapping, teleportToken wiring, creation order, confirmation dialog default, silent mode, and default GM/Regions-layer visibility. It also flags GM-only permissions. Nothing in the description conflicts with the absent 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 text is dense but purposeful: every clause addresses a non-obvious behavior such as endpoint semantics, wiring order, confirmation behavior, and visibility. It is front-loaded with the core purpose and avoids repeating schema field definitions.

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 10-parameter tool with no output schema and no annotations, the description covers the main behavioral surface: endpoint construction, sizing/snapping, one- vs two-way, confirmation behavior, layer visibility, and GM restriction. The schema documents remaining field-level details, so nothing needed to call it correctly 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 100%, so the baseline is 3; the description adds meaning beyond the schema by explaining how from/to map to trigger rectangles, what twoWay:false does, what confirm controls, and the default region visibility. This elevates it above the 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 a specific verb ('Create') and resource ('region TELEPORTER') with explicit scope ('between two points on existing scenes') and distinguishes it from create-scene, which can only do this at import time. The from/to endpoint semantics make the action 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?

Gives clear context: used when a teleporter is needed on existing scenes rather than at scene creation, and notes it is GM-only. It also clarifies mode selection with twoWay:false and when confirm:false is appropriate (traps/plot teleports only). It does not explicitly name related alternatives like remap-teleporters, so it stops just short of full alternative 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, and it excels: it discloses coordinate conversion to v14's center-anchored doc coords, warns against pre-adding width/2, explains per-tile error isolation with 404 behavior, states that created ids are returned, and notes the GM-only restriction. This goes well beyond the schema and title.

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-structured: purpose first, coordinate semantics second, optional capabilities next, then error behavior, return value, and permission. Each sentence adds distinct value, and nothing is wasted or redundant with the schema.

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?

Despite the tool's complexity and lack of an output schema, the description covers placement semantics, coordinate conversion, optional behaviors, error isolation, return value, and GM-only access. It is complete enough for an agent to call the tool correctly, especially with the fully described input schema.

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 all parameters with 100% coverage, so the baseline is 3. The description adds meaningful integrated guidance about how parameters relate: width/height define on-map canvas size, x/y are absolute-canvas top-left, occlusionMode 1/4 makes roofs fade under tokens, and scaleX/scaleY zoom the texture inside the frame rather than resizing the tile. This extra context earns a 4.

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 ('Place') and a specific resource ('TILES') while enumerating tile subtypes (props, roofs/overhead pieces, decals, video overlays), which clearly separates it from sibling tools like place-tokens or create-drawings. It also names the scene as the target and the data-relative path source, so the tool's scope 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 clearly implies this tool is for placing tiles on scenes, and it points to get-scene-dimensions for coordinate math, which is helpful context. However, it does not explicitly state when to prefer this over alternatives such as update-tiles, delete-tiles, or place-tokens, nor does it give any 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 provided, the description carries the full burden of behavioral disclosure. It explicitly states key behaviors: per-wall error isolation (so partial failures are possible), returns created ids, and GM-only restriction. It also discloses default channel values (omitted channels default to 20 blocking) and explains door state semantics. This goes well beyond a bare 'create walls' and covers the main operational expectations.

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 paragraph that front-loads the core purpose and then layers in defaults, channels, and error handling. Every sentence adds new information, and nothing is wasted. It could be split into bullet points for readability, but it remains compact and scannable for an agent.

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 many parameters and no output schema, the description covers the essential operational aspects: what the tool does, coordinate system (absolute canvas pixels), channel defaults, door and threshold semantics, error isolation, return value, and access restriction. It does not explicitly state the walls are added to the scene's walls layer, but that is implied by 'on a scene'. No critical information appears 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?

Although the schema provides 100% coverage with per-parameter descriptions, the description adds a higher-level interpretation: it groups channels (move, light/sight/sound) and explains the meaning of threshold values and the alternative 'c' array syntax. It also gives a concrete example of doorSound ('woodBasic', 'metal'), which is not in the schema. This enriches the schema and helps an agent choose correct values.

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-resource pair ('Create one or more WALL segments') and immediately clarifies scope: 'surgical additions' to walls normally drawn in the app or shipped by a map pack. This distinguishes it from sibling tools like update-walls (modifying) and delete-walls, and the door/secret door examples make the intent 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 states the intended use case ('surgical additions') and contrasts with the normal workflow of drawing walls in the app, implying when to use this tool vs. manual drawing. However, it does not explicitly name alternatives like update-walls or list-walls, and there is no direct 'when not to use' guidance. The context is clear enough for an agent to infer the primary scenario.

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

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

With no annotations, description fully discloses key behaviors: irreversibility, GM-only requirement, strict matching (no fuzzy), and auto-removal of bridge-created empty folders. 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?

Single paragraph with three sentences, front-loaded with main action. Every sentence adds value; no fluff. Efficiently covers critical 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?

For a destructive delete tool with no output schema, description covers all essential aspects: action, resolution, prerequisites, permissions, and side effects (folder removal). Complete given complexity.

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%, baseline 3. Description adds meaning: explains 'identifiers' as exact names/IDs and strict resolution, and clarifies 'removeEmptyFolder' only affects bridge-created empty folders. Adds value beyond 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?

Description clearly states 'Permanently delete one or more world actors (NPCs/characters) by exact name or ID.' It uses specific verb (delete) and resource (actors), and distinguishes from sibling tools that delete other types (e.g., delete-asset).

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?

Description advises looking up precise name/ID with list-actors first and notes GM-only access. It implies caution due to irreversibility, but does not explicitly state when not to use or alternatives like bulk-delete for multiple actors.

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 fully discloses behavior: consults find-asset-references, refuses if references exist, requires recursive for directories, and refuses live world-DB paths. It lacks explicit error handling or success output 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?

Five focused sentences with no fluff, each conveying key information. Slightly dense but efficient; could be reordered for better flow.

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

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

Covers purpose, prerequisites, key behaviors, and parameter usage. Missing details on return value or confirmation of success, but given the tool's simplicity and lack of output schema, it is adequately 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 descriptions are 100% covered, but the tool description adds extra context for `force` (overrides reference check failure) and `recursive` (required for directories), enhancing understanding beyond the schema.

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

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

The description clearly states 'Delete a file under the Foundry `Data/` root over WebDAV,' providing a specific verb and resource. It distinguishes from sibling delete tools (e.g., delete-actor, delete-scene) by targeting file assets.

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?

Explicitly describes when to use (with reference-awareness and directory deletion requirements), when not to use (refuses live world-DB paths), and alternatives (pass force:true to override). Also notes required password.

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?

Without annotations, the description adequately discloses behavioral traits: permanent deletion, strict exact matching, and GM-only permission requirement. It covers the key aspects of how the tool behaves, though it could mention if deletion is reversible or affects related data.

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 conveying all essential information: action, resource, matching constraint, and permission requirement. No redundant or unnecessary words.

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

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

Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers the necessary context: what it does, how to use it (exact match), and who can use it (GM). It could mention if it only deletes stacks, not individual cards, but 'Cards stacks' implies that.

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 covers 100% of the parameter with a description. The description adds 'STRICT resolution' which reinforces the schema's 'exact' qualifier, but provides little additional meaning beyond what the schema already states. Baseline 3 is appropriate.

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

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

The description clearly states the tool permanently deletes Cards stacks by exact id or exact name. It specifies the resource ('Cards stacks') and the action ('permanently delete'), distinguishing it from other delete tools like delete-folder or delete-actor. The mention of 'GM-only' adds an important constraint.

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 guidelines: use exact ids or names, no fuzzy/substring matching, and the tool is GM-only. However, it does not explicitly mention when to use this tool over other deletion tools or alternatives like list-cards to find exact 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 provided, the description carries the full burden. It explicitly states the operation is IRREVERSIBLE and GM-only, and explains the confirm guard for bulk modes. This covers the key behavioral traits beyond what the schema provides.

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—three short sentences covering all modes, constraints, and key warnings. Every sentence adds value, with no fluff or redundancy. The most critical information (IRREVERSIBLE, GM-only) is highlighted.

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 4 parameters, the description provides complete context: all deletion modes, parameter relationships, confirm guard, and usage restrictions. It also includes a real-world performance hint. No gaps remain for an agent to safely invoke the 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?

Schema coverage is 100%, but the description adds significant meaning by explaining how parameters combine into three usage patterns (ids, beforeTimestamp+confirm, clearAll+confirm) and provides a performance-related use case for beforeTimestamp. This enhances understanding beyond the 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?

The description clearly states the verb 'Delete' and resource 'chat messages', and distinguishes three distinct deletion modes (by ids, before timestamp, clear all). This differentiates it from sibling tools like list-chat-messages and export-chat-log.

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 explains when to use each mode, including the requirement for confirm:true in bulk operations. It provides a specific use case ('handy for the known Molten big-log perf drag'). However, it does not explicitly compare with sibling delete tools for other resources, though the name makes it clear.

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

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

No annotations provided, so description carries full burden. It discloses id source, non-fatal error handling for missing ids, and GM-only restriction. This is comprehensive for a delete 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, no redundancy. All information is relevant and front-loaded. 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?

Covers all essential aspects for a simple delete tool: what, how (by id), where (scene), error handling, access restriction. No output schema needed; description is sufficient for an agent to invoke 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%, baseline 3. Description adds little beyond schema: drawingIds already mentions 'from list-drawings' and sceneIdentifier already says 'id or exact name'. The overall behavior note on missing ids is not parameter-specific, so minimal added value.

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

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

Clearly states the verb 'Delete', the resource 'Drawings', and the scope 'from a scene by id'. References list-drawings for ids. Distinguishes from sibling delete tools by explicit resource type and additional notes (missing ids non-fatal, GM-only).

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 context on when to use (for deleting drawings, ids from list-drawings) and behavior (missing ids reported, non-fatal) and access (GM-only). Lacks explicit when-not or alternatives, but context is clear enough for an agent to decide.

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 fully discloses behavior: irreversible deletion, default refusal for non-empty folders, and the option to delete contents. This covers safety and destructive nature comprehensively.

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?

Five sentences, each essential: action, restrictions, default behavior, optional override, param note. No redundancy. Front-loaded with critical warnings.

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?

Despite no output schema, the description covers purpose, usage, parameters, and behavioral nuances completely. No gaps remain for a deletion tool of this complexity.

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?

All three parameters have schema descriptions, and the tool description adds context: defaults to Actor folders, explains 'identifier' can be name or ID, and clarifies the avoidContents flag. The description matches the schema and adds value.

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

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

Clearly states 'Permanently delete a folder by exact name or ID', distinguishing from sibling tools like delete-actor or delete-item. The verb 'delete' and resource 'folder' are precise, and the scope 'GM-only, IRREVERSIBLE' adds specificity.

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 when-to-use: GM-only, safe for cleaning empty folders, and when to pass deleteContents:true for forced deletion. Implies when not to use (when contents should be preserved). Could explicitly mention alternatives like moving items first, but the guidance is strong.

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 full burden. It discloses destructive nature ('permanently delete'), permission requirements ('GM-only'), and matching strictness ('STRICT resolution'). However, it does not mention error handling or side effects if identifiers are not found.

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 purposeful. No redundancy. Front-loads action and resource, then adds constraints and alternatives.

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

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

Covers core action, input format, and when to use alternative. Missing explicit mention of return value or success/failure behavior, but for a deletion tool this is acceptable.

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 describes parameter generically; description adds crucial context: 'exact ids (preferred) or exact names', and reinforces strict matching. This goes beyond the schema's own parameter 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 action ('permanently delete'), the resource ('world-level Item documents from Items sidebar'), and the method ('by exact id or exact name'). It distinguishes itself from the sibling tool 'remove-from-actor' by specifying 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?

Explicitly states 'GM-only' for permission context, specifies when not to use it (for embedded actor items, use 'remove-from-actor'), and emphasizes strict matching to avoid accidental deletion. Provides clear 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?

The description discloses destructive and irreversible operation ('permanently delete') and access restriction ('GM-only'), but with no annotations, it lacks details on effects (e.g., cascading deletes) or error handling. Adequate 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?

Two short sentences with no fluff. Front-loaded with action and resource, followed by constraints. Every sentence adds value.

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

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

Given no output schema, the description does not mention return values (e.g., success/failure count). It covers the operation adequately but lacks completeness on expected output. With simple deletion and no annotations, a score of 3 reflects this gap.

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

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

Schema coverage is 100% with description of identifiers as exact ids or names. The description adds 'STRICT resolution' but does not provide additional meaning beyond schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool deletes JournalEntry documents by exact id or name, distinguishing it from create, update, list, and search siblings. The 'GM-only' and 'permanently' further specify scope and nature.

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 specifies when to use (exact identifiers) and constraints (no fuzzy matching, GM-only), but does not explicitly mention when not to use or compare with alternatives. However, sibling tools cover other operations, making the context 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?

Discloses that it deletes one page and leaves the rest intact, and that it is GM-only. Without annotations, this sufficiently describes behavior. Could mention permanence but it is 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?

Extremely concise: two sentences plus 'GM-only' tag. No redundant information, front-loaded with key action and purpose.

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?

Complete for a simple delete tool with clear schema and no output schema. Addresses what, how, and who.

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 already describes both parameters with clear descriptions (pageId from list-journals, journalId as id or name). The description adds little beyond schema, but reinforces the source of pageId. Baseline 3 due to high schema 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 clearly states it deletes one page from a journal entry, specifying the use case of removing a stray/mistaken page. It distinguishes itself from sibling tools like delete-journal (deletes entire journal) and set-journal-page-visibility (hides page).

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?

Explicitly states when to use this tool ('use to remove a stray/mistaken page instead of deleting and rebuilding the whole journal') and notes it is 'GM-only,' indicating the intended user.

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 that missing ids are not fatal and that the tool is GM-only, but does not detail side effects, irreversibility, or cascading impacts on the scene.

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, no wasted words. Front-loads the core action and follows with important behavioral notes.

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 delete tool with two parameters and no output schema, the description covers the essential behavior, error handling, and access control. It is sufficiently complete for the tool's complexity.

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 schema already describes both parameters. The description adds minimal value by referencing 'list-lights' for id sourcing, but does not elaborate on format or constraints 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?

Description clearly states it deletes AmbientLights from a scene by id, specifying the resource and action. It differentiates from sibling delete tools by explicitly mentioning AmbientLights and scene 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?

Provides useful guidance: missing ids are reported but not fatal, and only GMs can use it. Implicitly suggests using 'list-lights' to get ids. However, it lacks explicit when-not-to-use or alternative 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?

Description discloses a critical side effect: it scrubs hotbar slots that referenced the deleted macros, preventing dead buttons. This goes beyond simple deletion and is not visible in annotations (none provided). It also notes 'GM-only' permission requirement. These are valuable 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?

Single sentence with two pieces of information: deletion method and side effect. Extremely concise and front-loaded with the core action. No filler words.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the essential context: deletion method, side effect, and permission requirement. It doesn't elaborate on error handling or return behavior, but those are likely not critical for a delete operation with no output schema.

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 emphasizes that the 'macros' parameter accepts ids or exact names (case-insensitive), which is additional guidance beyond the schema's generic description. Schema coverage is 100% but the description adds clarity on matching semantics, which is useful.

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

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

Description clearly states the verb 'Delete', the resource 'world macros', and the two identification methods ('by id or exact name'). It also distinguishes itself from siblings like delete-rolltable by focusing on macros. The distinction from list-macros is implicit but clear.

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

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

The description mentions the tool deletes macros, which is a clear context of use, but does not explicitly state when to use it vs alternatives (e.g., delete-item for items). However, the sibling list is diverse, and the tool's purpose is unambiguous enough that an agent would know to use it for macro deletion. No explicit 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?

Without annotations, the disclosure of missing ids being non-fatal is valuable, but it omits details like whether deletion cascades, is reversible, or affects other data. 'GM-only' covers authorization, but more behavioral context would help.

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?

Extremely concise with three sentences, each adding unique value. The action is front-loaded, and no redundant information is present.

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 delete tool, the description covers input, behavior on missing ids, and permission. It is slightly incomplete by not discussing idempotency or side effects on the scene, but this is forgivable given the tool's nature.

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 covers both parameters with descriptions. The description adds contextual meaning by specifying that note ids come from 'create-scene-notes', which clarifies the expected format 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 uses a specific verb 'Remove' and clearly identifies the resource as 'map-note pins' from a scene, distinguishing it from siblings that delete other entity types.

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 states 'GM-only' for permission and notes that missing ids are not fatal, providing context for when to use. However, it lacks explicit guidance on when not to use or alternatives, though the sibling list implies this tool is for notes.

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?

Describes permanent deletion, strict resolution, and GM-only requirement. Does not mention potential side effects like cascading deletes, but for a simple delete operation this is sufficient without 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?

Two sentences, no wasted words, front-loaded with action and target. Every sentence adds value.

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

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

For a simple delete tool, the description covers what it does, how it identifies targets, and its constraints. No output schema needed; behavior is predictable.

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

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

Schema coverage is 100% with a clear description of the 'identifiers' parameter. The description adds the 'STRICT resolution' context, but the parameter is already well-documented in the schema. Meets baseline with minor added value.

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 (permanently delete), target (Playlist documents), and method (by exact id or exact name). It distinguishes itself from siblings like update-playlist and other delete tools for different document types.

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?

Explicitly states 'GM-only' for authorization and 'STRICT resolution — no fuzzy/substring matching' to clarify when not to use. Provides clear constraints for correct invocation.

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