fvtt-mcp-molten5e

by Txpple

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.3.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with descriptions that explicitly differentiate them. For example, multiple actor creation tools (author-npc, create-actor-from-compendium, create-pc, etc.) are each scoped to specific use cases, minimizing ambiguity even among 95 tools.
Naming Consistency4/5
The vast majority follow a verb_noun pattern (e.g., add-feature, create-scene, delete-actor). A few tools like parse-ddb-character and create-pc-from-prefab use slightly different structures but remain readable. Overall very consistent.
Tool Count2/5
With 95 tools, the server is severely over-scoped for typical MCP server norms. While the complexity of Foundry VTT and D&D 5e might justify many tools, this count feels excessive and could be streamlined by combining related functions (e.g., multiple search-compendium variants).
Completeness5/5
The tool surface is remarkably complete, covering nearly every aspect of the domain: actor lifecycle, item management, scenes, journals, compendiums, assets, chat, roll tables, and even auditing and reference integrity. No obvious gaps are present.
Average 4.3/5 across 95 of 95 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 248 commits in the last 12 weeks
- Last stable release on July 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'list all available characters' without indicating read-only nature, pagination, response size, or what 'basic information' entails. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is front-loaded with the verb and resource, but could be more efficient by including key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description does not specify return fields (e.g., name, id, type) or any limits. It is incomplete for a listing operation, leaving the agent uncertain about the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'type', and its description is present in the schema. The tool description adds no extra 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all available characters with basic information', clearly indicating the action (list) and resource (characters/actors). It implicitly differentiates from sibling tools like 'get-actor' (singular) and other list-* tools by naming the entity, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives such as 'get-actor' for specific actors or 'search-actor-contents' for filtered searches. The agent must infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as required permissions, whether the operation is read-only, or any side effects. It merely restates the listing purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (13 words) with no wasted words. It is front-loaded with the core action. Slightly more structure (e.g., separate param notes) could improve, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two optional parameters, the description fails to specify the output format, how 'all' works for actorIdentifier, or how permissions are returned. This leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage for both parameters is 100%, so the schema already documents their meaning. The description adds no additional context beyond the schema, achieving the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('list') and resource ('ownership permissions for actors'), and explicitly mentions the output ('showing which players have what access levels'). It distinguishes from sibling tools like 'list-actors' and 'set-actor-ownership'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., get-actor or set-actor-ownership). It lacks explicit 'when to use' or 'when not to use' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, side effects, or permissions required. With no annotations, the description carries full burden for safety info but fails to deliver.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the essential action and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides the key return fields. However, the term 'cards stacks' is not explained, and there is no mention of ordering or filtering. Still, it is reasonably complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds value by specifying the returned fields (id, name, type, card count), which is useful for understanding the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists cards stacks with specific fields (id, name, type, card count). The verb 'list' and resource 'cards stacks' are specific. However, it does not define what a 'cards stack' is, which could be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives (e.g., list-actors, list-items). There is no context about when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks detail on what 'basic information' includes, such as system rules, world settings, or module data. No annotations exist, so the description must convey safety and behavior—it does not. It only says 'get', implying read-only, but no confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose. It is concise but could be slightly more informative without being wordy. It earns its place but is on the lean side.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what 'basic information' includes. It is vague. For a tool with zero parameters and a generic purpose, this is minimally adequate but not complete—leaves agent guessing about return content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%, so the description need not add parameter details. The baseline for 0 parameters is 4; the description adds no further info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'basic information about the Foundry world and system'. It distinguishes from sibling tools like get-actor or get-scene-dimensions by targeting world/system info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no explicit mention of scenarios, prerequisites, or when not to use it. With many sibling getter tools, this omission hinders agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full burden. It only states what fields are returned but does not disclose any behavioral traits like read-only nature, pagination, or side effects. For a list operation, basic transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that quickly conveys the purpose and output fields. It is front-loaded and concise, though it could be slightly more structured (e.g., bullet points) but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description gives the minimum viable information: it lists what fields are returned. However, it omits any details on scope (e.g., all rolltables? filtered?), ordering, or whether it's read-only. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is 100% by default. Description does not need to add parameter meaning beyond schema, which is empty. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'list' and the resource 'RollTable documents', and specifies the fields returned (id, name, formula, result count, description). It effectively distinguishes from sibling tools like create-rolltable, delete-rolltable, and roll-on-table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance provided; description does not indicate when to use this tool versus alternatives like search-rolltables or roll-on-table. Lacks context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description implicitly suggests a read-only operation but does not explicitly state it is non-destructive or require permissions. The behavioral traits are somewhat transparent for a getter, but could be more explicit about side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant words. It is concise and front-loaded with the core purpose. However, it could be slightly more structured by separating the main purpose from the included elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with two optional boolean parameters and no output schema, the description is fairly complete. It covers what the tool does and what is included, though it omits specifics about the returned format or potential limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description does not add extra meaning beyond the schema; it mentions 'tokens' and 'layout' which align with includeTokens but does not elaborate on includeHidden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves information about the currently active scene, specifying it includes tokens and layout. It distinguishes from sibling tools like 'list-scenes' (lists all) and 'update-scene' (modifies), providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention that to get a specific scene by ID, one might use another tool, or that this tool is only for the active scene. The description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states it lists items but does not disclose any behavioral traits such as pagination, ordering, read-only nature, or potential limits. The description is minimal and does not sufficiently inform the agent about the tool's behavior beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 12 words, front-loading the core function ('List world-level Item documents') and immediately following with the optional filters. There is no redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 specify the return format (e.g., full item details, IDs) or any constraints like pagination or maximum results. For a listing tool among many siblings, it is adequate but lacks completeness in setting expectations for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so each parameter is already documented within the schema. The tool description adds no additional meaning or usage context beyond what is in the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'world-level Item documents', and specifies optional filters (type, name substring, folder). It distinguishes from sibling tools like 'list-actors' or 'list-assets' by explicitly naming the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. While it is clear from context that this is for listing items, there is no mention of when not to use it or which sibling tool might be more appropriate for similar but different queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'read-only' and downloads via WebDAV, which adds transparency. However, it does not disclose whether files are overwritten, error handling for missing files, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with key information. The 'Plane B (file channel, read-only)' prefix is somewhat obscure but still concise. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple download tool with two parameters and no output schema, the description provides adequate context: source, destination, and use case. Missing error handling or auth details, but acceptable for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 context that remotePath is relative to 'Data/ root', which clarifies the schema. No additional parameter semantics beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a file from the Foundry Data/ root to a local path, specifying direction and resource. It distinguishes from upload, copy, delete, and list siblings by focusing on remote-to-local transfer for inspection or reprocessing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at usage ('for grabbing an existing asset to inspect or re-process') but does not explicitly state when not to use it or compare to alternatives like copy-asset or asset-url. Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the tool lists scenes and specifies returned fields, implying a read operation. However, it does not explicitly declare it as read-only or disclose any other behavior (e.g., pagination, ordering, default scope).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and key features. It is front-loaded with the primary action and resources. Minor improvement could be breaking into two sentences for readability, but current structure is concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema, the description adequately covers the returned fields and filtering options. It does not mention ordering, pagination, or default behavior (e.g., returns all scenes by default), but those are not critical given the tool's simplicity. Overall, it provides sufficient context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions both parameters ('filter by name substring', 'show only the active scene') but adds no new semantics beyond what the schema already provides (e.g., case-insensitivity, default values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'List' and resource 'Scene documents', and enumerates the returned fields (id, name, active flag, etc.). This clearly distinguishes it from sibling tools like create-scene or get-current-scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering (by name substring or active scene only), implying when you might use these options, but provides no explicit guidance on when to use this tool versus other scene-related tools. It lacks 'when to use' and 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It explicitly states the tool is read-only and touches no actor, disclosing key behavioral traits. Constraints like premium-only are also included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with 'Read-only'. It is efficient with no wasted words, though the second sentence could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers what it does, key constraints, and how to use parameters. However, it lacks details on output structure, error handling, and default behavior when no identifier is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains that className and classUuid are resolution keys and that exactly one should be used. The level parameter is mentioned but its default and behavior if omitted are not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a read-only tool that reports player choice points for a premium class up to a level, specifying the information returned. It does not explicitly differentiate from sibling tools but the unique function is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that resolution is by className OR classUuid (exactly one) and that it works only for premium books, not SRD. This provides clear usage context, though alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the exclusion of SRD packs, but lacks details about whether the operation is read-only, permissions needed, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, directly conveys purpose and key constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description references an external document (design.md §2.3) that the agent cannot access, and fails to describe the return value shape, which is critical given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning to the optional 'type' parameter beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'compendium packs', and specifies the exclusion of SRD packs (dnd5e.*), distinguishing it from siblings like 'read-pack' and search-compendium tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (listing premium/non-SRD packs) but does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Read-only,' which is a clear safety signal. However, it does not elaborate on side effects, rate limits, or return format beyond the implicit finding of documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences that front-load the purpose and usage. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, usage guidance, document types, and safety. It is adequately complete for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'paths' fully described in the schema. The description does not add extra semantics beyond what is already in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds references to an asset path across multiple document types, using a specific verb ('Find') and resource ('world documents'). It distinguishes itself from siblings like delete-asset or move-asset by specifying it should be used before destructive actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this BEFORE deleting or moving a file to see what would break,' providing clear when-to-use guidance. It does not explicitly mention alternatives, but the context implies this tool is for pre-deletion/move checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states retrieval of 'full details and all system data' implying read-only behavior, but does not disclose permissions, rate limits, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. First sentence states purpose, second provides usage guidance. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 required parameters, no output schema, and high schema coverage, description provides adequate guidance. It could be more specific about return format or potential ambiguity in entityIdentifier, but overall complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. Description adds no additional meaning beyond what schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (Retrieve) and specific resource ('entity from a character'), enumerates entity types (items, actions, effects), and mentions returning full details. It distinguishes itself from siblings like get-actor by specifying this tool is for detailed entity retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance to use after get-actor when needing details about a specific entity. Provides context but does not list alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It notes that cards have no premium-book compendium and that the tool is GM-only, which adds behavioral context. However, it does not disclose side effects, permissions beyond GM, or whether the operation is destructive or read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the action and key details. Every sentence adds value: purpose, example, alternative, and GM restriction. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description adequately covers purpose, usage, and constraints. It could briefly mention that the deck is imported as a stack, but overall it is sufficiently complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 examples for 'preset' ('pokerDark'/'pokerLight') but does not significantly enhance understanding beyond the schema. The optional parameters 'name' and 'folderName' are not elaborated upon.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports a Foundry PRESET deck with examples ('pokerDark'/'pokerLight'). It distinguishes itself from 'create-cards' for themed D&D decks, providing a clear verb+resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool for ready-made decks and directs to 'create-cards' for themed D&D decks. It implies GM-only usage, which serves as a usage constraint, though it does not explicitly state when not to use it beyond the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides some behavioral info: it lists returned fields and notes that contentMode:none is cheap. However, it does not disclose ordering (which is in schema but not in description) or scope (all messages or only current user's). No side effects or read-only indication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, immediately stating the tool's purpose and then providing use cases and a tip. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 parameters, no output schema), the description covers purpose, use cases, fields returned, and a performance tip. Missing details like ordering and scope, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described. The description adds minimal value beyond the schema, only repeating the cheapness tip for contentMode:none. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent chat messages with specific fields (id, author, time, whisper/blind, content preview), and it provides explicit use cases (find ids for delete, verify a post, preview before export) that help differentiate it from siblings like delete-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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (to find ids for delete, verify, preview) and provides a usage tip (contentMode:none for cheap operation). However, it does not mention when not to use it or mention alternatives like export-chat-log for full export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the full burden. It states the output fields but does not disclose any behavioral traits such as being read-only, performance implications, or any ordering. The lack of annotations is partially mitigated by the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action, resource, and returned fields. Every word adds value; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description adequately tells the agent what fields will be returned. It could mention that 'all' playlists are listed, but that is implied by the tool name and absence of filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters. According to the rubric, 0 parameters warrants a baseline of 4. No further parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' and specifies the resource 'Playlist documents'. It enumerates specific fields returned (id, name, mode, track count, playing status), clearly distinguishing this from other playlist-related tools like create, delete, or update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The purpose is implied by the name and description (list all playlists), but there is no mention of when not to use it or even a hint about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses it posts a card using dnd5e inline roll enricher, that players click to roll their own check. Does not detail what happens after clicking, error handling, or the resulting message format. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no extraneous information. Every sentence earns its place. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers the core functionality (posting a request card). Lacks details on return value or error cases, but the tool's simplicity and clear use case compensate. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is already well-described in the schema (e.g., ability, skill, kind, dc). Description adds context about dnd5e enricher and GM-only but does not provide additional meaning beyond schema for parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it posts a click-to-roll request card for saving throws, ability checks, or skills. Distinguishes from siblings like 'roll-on-table' (table rolling) and 'send-chat-message' (generic message) by specifying it's a table-facing prompt for players to roll their own checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says GM-only, indicating it's for GMs to prompt players. Implicitly for group challenges where each player rolls individually, but does not explicitly state when not to use or mention alternatives like 'send-chat-message' for custom messages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it sets page ownership default and does not modify content, which is key behavioral trait. With no annotations, description carries full burden; it is adequate but does not cover permissions or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two sentences that front-load the key action. Could be slightly tighter, but no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple toggle tool with no output schema. Explains the core behavior and usage scenario. Lacks details on error cases or return value, but that's acceptable given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes all parameters (100% coverage), but description adds context: 'flip' implies toggling, and explains playerVisible as 'a handout players can OBSERVE' and GM-only. Enhances understanding beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it flips a journal page between player-visible and GM-only, specifying the verb 'flip' and resource 'journal PAGE'. Distinguishes from updating the whole journal by explicitly noting it does not rewrite content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: to reveal/hide an existing page instead of rebuilding the whole journal. Includes a concrete example (page from an append). Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain behavioral traits. It covers mutation behavior, patching semantics, and the constraint that shape KIND cannot change. It does not detail safety, reversibility, or auth beyond GM-only. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured paragraph with clear categories and front-loaded action. No superfluous words. Efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers major operations, patching behavior, GM-only restriction, and the inability to change shape kind. It lacks return value details (no output schema) and error cases, but for a modification tool with many parameters, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 value by explaining the shape KIND constraint not in schema, but does not elaborate on parameter details beyond what schema provides. Meets minimum expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits existing DRAWINGS by ID, listing specific operations (move, resize, restyle, change text, toggle hidden/locked/interface). It distinguishes from siblings like create-drawings, delete-drawings, and list-drawings by specifying modification of existing entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Patches only the fields you pass' and 'GM-only', indicating when to use. It references list-drawings for IDs. However, it lacks explicit 'when not to use' or comparison to alternatives, but the purpose is distinct enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It discloses per-tile error isolation, 404 warnings, return of created IDs, and GM-only restriction. It also explains occlusion mode semantics, adding useful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense single paragraph that front-loads the main purpose and then details parameters. It is efficient, though it could be slightly more structured for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (many optional parameters, nested objects, no output schema), the description covers essential behavior, return value, and error handling. It is sufficient for an agent to understand usage without additional info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context beyond parameter descriptions, e.g., clarifying that width/height are canvas pixels and referencing get-scene-dimensions for coordinate math. It explains occlusionMode values and video behavior, enhancing schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool places TILES (props, roof pieces, decals, video overlays) on a scene from Data-relative image paths, clearly distinguishing it from siblings like create-drawings or create-lights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It correctly indicates GM-only usage and lists tile types, but does not explicitly state when to avoid this tool or mention alternatives. The context of sibling tools implies its specific role, but guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool performs a write operation ('rewrite every reference') and offers a dry-run preview. However, it does not explain the scope of changes (e.g., all documents in the world), irreversibility, or what happens if oldPath is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that cover purpose, usage tip, and authorization. Every sentence adds value with no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 explain what the tool returns (e.g., count of changed documents or list of affected files). It adequately covers core functionality and a key parameter tip, but lacks details on expected output and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all three parameters described). The description adds value by explaining the dryRun parameter's use ('preview without writing'), which goes beyond the schema's default description. For oldPath and newPath, the schema already provides adequate descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool rewrites every reference from one asset path to another after moving/renaming a file, using specific action-oriented language. It distinguishes from siblings like move-asset (which moves the file itself) and copy-asset (which copies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Pass dryRun:true to preview the documents that would change without writing' and 'GM-only' for authorization. It implies use after asset relocation, but does not explicitly mention when not to use it or compare to alternatives like find-asset-references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses authorization requirement (GM-only) and a special rename behavior for dnd5e. With no annotations, the description partially carries the behavioral burden but does not mention side effects, destructiveness, or what happens on error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste: purpose, constraint, and a critical special case all 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects (purpose, authorization, special case) but lacks information about return values (no output schema) and does not explain what 'world-level' means in contrast to actor-owned items. For a mutation tool with no annotations, some gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful extra context beyond the schema: it explains the rename behavior for unidentified dnd5e items, which is not in the schema. The description also reiterates the 'world-level' scope, reinforcing the parameter's context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (update) and resource (world-level Items by id), lists changable fields (name, img, system data, folder), and specifies GM-only. Distinguishes from sibling tools like create-item and update-actor-item by explicitly saying 'world-level'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states GM-only constraint and provides specific guidance for renaming unidentified dnd5e items. However, lacks explicit guidance on when to use this versus alternatives like update-actor-item, though the world-level scope is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details behavioral traits: SRD refs are refused, premium items render as @UUID links, ranges auto-assign, formula defaults to 1d<total weight>. It also notes GM-only. However, it misses potential side effects like permission requirements or overwrite behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that packs essential information concisely. It is front-loaded but could benefit from more structured formatting like bullet points. It is effective without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and key behavior, but lacks information about the return value (e.g., what is returned after creation). Given no output schema, this is a gap. Otherwise, it is reasonably complete for the 7 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining how results combine text and uuid, the auto-assignment of ranges, and the default formula. This goes beyond the schema descriptions, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a RollTable from a list of results, specifies the types of results (text/UUID), mentions auto-assignment of ranges and formula, and distinguishes it from siblings like import-rolltable and roll-on-table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use for random encounter/loot/rumour/treasure tables. GM-only.' It provides clear use cases and access restrictions, but does not explicitly mention when not to use or alternatives beyond the implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides important behavioral details: trigger rectangles are placed, grid-snapped by default, regions default to GM-only visibility, and the order of operations. It does not mention permissions or potential side effects, but covers most key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but each sentence adds useful information. It is structured logically: purpose, then mechanics, then details. No wasted words, though it could be slightly more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, nested objects, no output schema), the description covers purpose and behavior well but does not mention what the tool returns (e.g., region IDs or status). For a tool with no output schema, this is a notable gap, leaving the agent unsure of the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so baseline is 3. The description adds value by explaining the overall concept of two-way vs one-way and the triggering mechanism, which goes beyond the parameter descriptions. It also mentions grid-snapping and GM visibility, which are behavioral but supplement parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a region teleporter between two points on existing scenes, distinguishing it from create-scene which only does this at import time. It specifies the verb 'create' and resource 'teleporter' with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: for creating teleporters on existing scenes, and mentions that it handles the chicken-and-egg problem by creating both regions before linking. It doesn't explicitly state when not to use or compare to sibling tools like remap-teleporters, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses non-fatal missing id handling, orphan teleporter warnings, and GM-only restriction—valuable behavioral details beyond the basic delete action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each providing essential information: the core action in the first, edge cases and access restriction in the second. No redundant text, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main behavior and important edge cases (missing ids, orphan warnings) and access control. It does not mention return values, but for a deletion tool, the provided information is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The tool description adds minimal extra meaning beyond the schema, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes one or more regions by id, specifying the action, target, and method. It distinguishes from sibling delete tools by targeting regions and adds unique details like reporting missing ids and orphan teleporter warnings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting regions and indicates GM-only access, but it does not explicitly explain when to use this over alternatives like updating a region or when not to use it. No direct comparison to siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that missing IDs are reported but never fatal, and that the tool is GM-only. It does not mention permanence or side effects, but for a delete tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource. No unnecessary words; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with 2 parameters and no output schema, the description covers auth (GM-only) and error handling (missing IDs non-fatal). Could mention return value, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 minimal value by referencing 'from list-sounds', which the schema parameters already include. No additional syntax or format details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes one or more AmbientSounds by id, sourced from list-sounds, which distinguishes it from sibling tools like create-sounds, update-sounds, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions GM-only, indicating restricted usage. It does not explicitly state when not to use or alternatives, but given it's a delete tool, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that missing IDs are reported but not fatal, and that the tool is GM-only. It does not detail all side effects, but the destructive nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence plus 'GM-only'—with no wasted words. It front-loads the action and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action, input source, behavior on missing IDs, and authorization. Without an output schema, it would benefit from mentioning return behavior, but it is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value beyond the schema. It references 'from list-tiles' for tileIds, but that is also in the schema description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes tiles from a scene by ID, specifies the source of IDs ('from list-tiles'), and explains behavior for missing IDs. It distinguishes the resource (tiles) from siblings like delete-drawings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when needing to delete tiles) and provides context via 'from list-tiles' and 'GM-only'. It lacks explicit when-not-to-use or alternatives, but the tool is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: GM-only authorization, non-fatal missing IDs, and the destructive nature (deleting walls). It could add details about irreversibility or response, but for a simple tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with three clear clauses covering purpose, example, error handling, and authorization. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description covers operation, error handling, and authorization. It lacks mention of prerequisites (scene/wall existence) or permanence, but the example and GM-only note provide reasonable completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the example context but no new semantic details beyond reinforcing the IDs source and scene identifier purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes walls by ID from a scene, provides a concrete example ('open up a sealed passage'), and references the source tool ('list-walls'). This distinguishes it from other deletion tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates when to use (delete walls), who can use it ('GM-only'), and error handling ('missing ids reported, never fatal'). Though it does not explicitly list alternatives, the context of 'by id from list-walls' implies a prerequisite, and the sibling list shows other delete tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 implies a read operation via the verb 'retrieve' and mentions that SRD packs are refused. However, it does not explicitly state that the operation is read-only, nor does it disclose any potential side effects or authentication requirements. This is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose and output, then adding two key usage guidelines. No redundant information, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and no nested objects, the description adequately covers the purpose, parameter constraints, and return type (full stat block). It references external documentation for further detail. Slightly more detail on the return format could improve completeness, but it is sufficient for an agent to decide when to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a baseline of 3. The description adds value by explaining the compact parameter's purpose (condensed stat block) and the restriction on pack IDs (only premium books, not SRD). This goes beyond the schema's basic parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a specific compendium entry by pack and entry ID, listing examples (monster, item, spell) and explicitly mentions the full stat block returned. This differentiates it from sibling tools like search-compendium or list-compendium-packs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use the compact parameter and explicitly states that SRD pack IDs are refused, referencing design documentation. However, it does not explicitly state when not to use this tool versus other retrieval or search tools, though context implies it for specific entry retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It discloses that embedded results with @UUID links come intact, that the tool is GM-only, and that it only works with premium-book packs. It doesn't mention if the import is additive or overwrites, but 'Copy' implies duplication. The description provides reasonable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences that front-load the core action, then add context and constraints. Every sentence adds value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains why the tool is needed (world-only roll tables), what is copied (embedded results with UUIDs), and user restrictions (GM, premium packs). It lacks details on error handling or exact outcome, but for a simple import tool without output schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 each parameter. The tool description does not add meaningful detail beyond what is in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Copy a whole RollTable from a compendium pack into the world') and provides a concrete example (DMG treasure/magic-item table). It distinguishes from siblings like create-rolltable and roll-on-table by explaining the import necessity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (before roll-on-table) and why (roll tables are world-only at roll time). It also specifies constraints: premium-book packs only (SRD refused) and GM-only. However, it does not explicitly compare to alternative tools like import-item or list-rolltables.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Read-only' which is critical behavioral information. Lists all returned fields in the description. No annotations provided, so the description carries the burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Front-loaded with key action and scope. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is sufficiently complete: it lists return fields, states read-only, and provides usage context. Minor omissions like handling of null positions are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is adequate. The tool description adds context by specifying the operation scope ('on a scene') but doesn't add meaning beyond the schema for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists AmbientLight objects on a scene and enumerates all returned fields. Distinguishes itself from siblings by specifying 'AmbientLight' and the inspect step before update/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the tool as a read-only inspect step before update-lights or delete-lights, providing clear context for when to use it. Could be slightly more explicit about when not to use, but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares the tool is 'Read-only', a key behavioral trait. It also lists the fields returned. With no annotations, the description carries full burden, and while it doesn't detail error conditions or performance, it sufficiently covers the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action and fields, followed by behavioral and usage context. No wasted words, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description is fairly complete. It covers what is returned and the read-only nature. It could be slightly improved by specifying the output format (e.g., array of objects), but the listed fields provide sufficient detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter 'sceneIdentifier' is already documented. The description adds marginal value by implying it refers to the scene containing the sounds, but does not provide additional format or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'AmbientSound on a scene', enumerating the fields returned. It also distinguishes itself from siblings by stating it's the 'inspect step before update-sounds / delete-sounds'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (before modification) and references sibling tools update-sounds/delete-sounds. However, it does not explicitly state when not to use it or provide alternatives for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 access, folder creation if absent, and root movement. However, it omits details like error handling, what happens to duplicates, or confirmation of success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose, conditions, and parameter behavior are front-loaded and efficiently conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, the description adequately covers core functionality. It could mention what happens on failure or the return value, but it is sufficient for selection and basic invocation given the sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining that identifiers are 'exact ids (preferred) or exact names', and that targetFolder empty equals root and missing creates a folder. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'move' for 'world documents of a single type' into a folder, with specific details on folder resolution and creation. It distinguishes from sibling tools like 'move-asset' which handles asset files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (moving documents to a folder, including root) and includes a restriction (GM-only). It does not explicitly mention when not to use or provide alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the search scope (all pages of all journals) and return value (page matched). It implies a read-only operation, but does not explicitly state safety or performance considerations. However, the behavior is adequately described for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two clear, front-loaded sentences with no superfluous information. It efficiently conveys the action and output usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (search journals), and the description covers its main behavior and output. It links to list-journals for reading. No output schema exists, but the description explains the return format. It does not specify details like case sensitivity or result limits, but is reasonably complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters (searchQuery, searchType) with descriptions. The description does not add new parameter meanings beyond what is in the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches journal entries for specific content/keywords and returns the matched page. It distinguishes itself from sibling search tools (e.g., search-actor-contents, search-compendium) by specifically targeting journals and linking to list-journals for reading results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to search journals) and how to use the result (via list-journals with journalId+pageId). It does not explicitly mention when not to use it or compare to other search tools, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: updates document fields, does not add/remove tracks, and is GM-only. With no annotations, description carries full burden and covers essential traits. Could mention idempotency or error conditions, but sufficient for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and scope. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers tool purpose and constraints for a low-complexity tool (4 params, no nested objects, no output schema). Could mention return value or confirm action, but not essential given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. Description adds context by naming the fields (rename, playback mode, crossfade) but does not provide additional semantic detail beyond what schema already offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool updates playlist fields (rename, change playback mode, set crossfade) and explicitly excludes adding/removing tracks. Also notes GM-only restriction. Distinguishes from sibling tools like create-playlist or delete-playlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on what the tool does and what it does not do (add/remove tracks). Implies it's for modifying existing playlists. No explicit alternative sibling mentioned, but the exclusion helps guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 'Patches only the fields you pass; an off-enum value skips that patch with a warning' and mentions GM-only, but omits return format, rate limits, or authentication details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with examples and parenthetical codes. Every sentence is informative, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex parameter array and lack of output schema, the description covers nearly all input details and patch behavior. Missing only a brief mention of what the tool returns (if anything).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 schema descriptions (e.g., 'door:2' for secret, 'ds: 0/1/2', 'a wall never half-moves'), making parameter usage much clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Edit one or more WALLS by id' and lists specific properties like door, ds, move/light/sight/sound, clearly distinguishing from create-walls, delete-walls, and list-walls among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context like 'GM-only' and explains patch behavior, but does not explicitly state when not to use it or compare to siblings beyond the initial verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool authors documents, does not roll/equip/spend charges, and intentionally allows duplicate names for stacks. It also mentions auto-replacement of invalid icon paths. However, it does not explicitly state required permissions or side effects like triggering updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized with bullet points for item types and front-loaded purpose. Every sentence adds value, and the structure aids readability. Minor length justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (49 params, nested objects, many item types), the description is thorough. It explains each item type's fields, cross-cutting details, and distinguishes from siblings. However, it does not describe the return value (e.g., created item id), which is a minor gap since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds high-level context about item types and cross-cutting fields but does not significantly augment individual parameter meanings beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a structured physical item (loot/gear) on an actor or in the world Items sidebar, specifies it's for D&D 5e only, and distinguishes from siblings like add-feature and import-item by noting specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 versus alternatives (add-feature for features/attacks-as-abilities, import-item for copying from compendium), and states what the tool does not do (no rolling, equipping, or spending charges). It also gives context for each itemType and cross-cutting behaviors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: per-wall error isolation, returns created ids, GM-only access. Also details default channel blocking behavior ('omitted channels default to 20 blocking'). No mention of rate limits or auth beyond GM-only, but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but well-structured: starts with purpose, then coordinate/segment spec, then channels with defaults, then per-wall isolation and return. No wasted words, but could benefit from bullet points for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, one being an array of objects with many properties, no output schema), the description covers coordinate alternatives, channel defaults, door types, per-wall error isolation, and return value. It lacks output schema details but none is provided. Adequate for a complex mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaning beyond the schema: explains coordinate system ('absolute canvas pixels'), summarizes channel type options and defaults, clarifies door state values, and notes that 'omitted channels default to blocking'. This aids understanding beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates WALL segments on a scene, specifying 'surgical additions' to existing walls. It distinguishes from walls 'normally drawn in the app or shipped by a map pack', and contrasts with sibling tools like 'update-walls' and 'delete-walls'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'surgical additions (block a corridor, add a door/secret door)' to existing walls. Sibling tools don't create walls, so usage is implied. No explicit when-not-to-use or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description itself discloses permanent deletion, exact matching requirement, and GM-only restriction. This adequately informs the agent of behavioral traits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no waste. The key information is front-loaded: action, target, method, constraints. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple parameter and no output schema, the description covers all necessary context: what it does, how to specify documents, who can use it, and important caveats (permanent, strict matching). It is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'identifiers' parameter as 'Exact ids (preferred) or exact names'. The tool description reinforces 'STRICT resolution', but adds minimal new meaning. Baseline 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (permanently delete), the target (RollTable documents), and the method (exact id or name). It also specifies strict resolution and GM-only access, distinguishing it from sibling tools like create-rolltable or update-rolltable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool (delete RollTables by exact id/name) and constraints (strict resolution, GM-only). It does not explicitly mention alternatives or when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details return content (every entry, roll range, weight, drawn flag, result text with enrichers, linked items) and sorting order (low-to-high). It implies read-only behavior ('Read', 'inspect or audit') without side effects. Sufficient for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loaded with the primary action and data details. Every clause serves a purpose: describes content, sorting, determinism, sibling contrast, and resolution method. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no annotations, the description thoroughly covers what the tool returns, its sorting, and its deterministic nature. An agent can fully understand the tool's behavior and output without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'identifier', which already states 'Table id or exact name.' The description adds the phrase 'Resolves by id or exact name', slightly reinforcing but not adding substantial new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('RollTable's FULL contents'), lists the exact data returned, and distinguishes from siblings 'list-rolltables' (summary only) and 'roll-on-table' (random draw). It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions the tool as 'the deterministic way to inspect or audit' and contrasts with alternative tools ('list-rolltables' gives summary, 'roll-on-table' draws random). It also specifies resolution by 'id or exact name'. Lacks explicit 'when not to use', but the contrast is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of disclosing behavior. It explains that without parameters it lists journals with pages, with journalId it reads first page content and shows pages, and with both reads full content. This is sufficient for a read-only operation. It doesn't mention side effects (none) or other traits, but the description is transparent about what happens in each mode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and conveys the necessary information efficiently. The key behavior is front-loaded ('List all journal entries, or read a specific journal/page'). It could be slightly more structured (e.g., bullet points) but is concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters, no required fields, no output schema, and the sibling tools include many similar list/read operations, the description adequately covers the different usage modes. It explains what the agent can expect for each parameter combination, which is sufficient for effective use. Could mention pagination or limits, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all 4 parameters (100% coverage), setting a baseline of 3. The description adds value by explaining the combined effect of parameters (e.g., how journalId and pageId interact) and clarifying what each mode returns. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies exactly what the tool does: list all journal entries or read a specific journal or page. It distinguishes three modes based on parameter presence, using verbs like 'list' and 'read' with the resource 'journal entries/pages'. This clearly differentiates it from sibling tools like 'search-journals' and other document listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each parameter combination (without params, with journalId, with both). It implicitly tells the agent what to expect in each case. However, it does not explicitly exclude use cases or compare with alternatives like 'search-journals', so it misses some guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Declares read-only behavior, specifies it works on any scene (not just active), lists all returned fields, and explains token-actor relationship. Does not mention pagination or rate limits, but for a list tool 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
First sentence clearly states purpose. Second sentence is dense but packs multiple pieces of useful information concisely. Slightly could be more structured, but no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains all returned fields. It also explains integration with other tools. Missing mention of pagination or limits, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. Description adds context that sceneIdentifier can be id or exact name and applies to any scene. This adds meaning beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists every placed token on a scene (by id or exact name) and enumerates returned fields. It distinguishes from siblings like place-tokens, update-token, delete-tokens by specifying it is the read-only inspect step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is the read-only inspect step that feeds update-token/delete-tokens, and explains token ids work as actorIdentifier for actor tools. Provides clear context for when to use but does not explicitly list 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.
Behavior4/5
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 only sets effect data and does not affect combat, and explains transfer behavior for item effects. It could additionally mention permission requirements or side effects like overwriting changes on edit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently covers all key points: purpose, CRUD actions, targeting, effect structure, and limitations. It is not excessively long, but could be slightly restructured (e.g., bullet points) for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, nested objects) and lack of output schema, the description provides sufficient context for an agent to understand CRUD operations, targeting, and the effect model. It mentions a limitation ('authoring only') but could elaborate on what happens with the created effect (e.g., no automated application).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the effect structure (key, value, type), targeting rules (actor vs item), and that the changes list is replaced on edit. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages ActiveEffects on actors or items with CRUD operations, providing specific examples like '+1 AC' and targeting options. It distinguishes from sibling tools like 'add-item' or 'apply-condition' by focusing solely on effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool for effect creation/editing/deletion/listing, and advises using action='list' to find effect IDs. It notes that the tool is for authoring only and does not run combat. However, it does not explicitly exclude alternatives like 'apply-condition' for condition management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: no marking results drawn, no posting to chat, surfaces UUID item links as importable. Notes world table limitation. With no annotations, description carries burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loading purpose, no extraneous words. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, description covers purpose, behavior, return value hints, and usage prerequisite. Complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description already states 'Table id or exact name', so description adds no new meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Roll', the resource 'world RollTable', and the outcome 'drawn result(s)'. It distinguishes from siblings like 'list-rolltables' and 'update-rolltable' by specifying rolling action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that rolling evaluates without marking results drawn or posting to chat, and notes world tables only with a prerequisite to copy compendium tables. Lacks explicit alternatives but offers clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: excludes SRD packs, uses real item data (not heuristics), returns minimal fields (id,name,type,uuid,pack,packLabel,img,facets), and ranks premium-first. No destructive or auth details needed for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences fit all essential information. It front-loads the action and scope, then adds backend and result details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 optional params, no output schema, no annotations), the description covers scope, behavior, result format, and next-step tool. It even references design documentation. All necessary context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all 7 parameters. The description adds minor context (e.g., 'use documentType to narrow the item family') but mostly restates schema info. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'find equipment, weapons, armor, consumables, and treasure matching faceted criteria'. It specifies the resource (items/gear) and distinguishes it from sibling search-compendium-* tools (spells, creatures) by emphasizing items and premium packs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to 'use documentType to narrow the item family' and to 'identify candidates here, then pull full detail with get-compendium-entry'. It also notes that SRD packs are excluded, providing clear context. It lacks explicit 'when not to use' but is otherwise helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals key behaviors: premium-only scope, real data checks (not heuristics), premium-first ranking, and the two-stage damageType process. It stops short of mentioning authentication or rate limits but is thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but logically ordered: purpose, scope, backend, return format, usage tip, special note. It's concise yet informative, with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description covers the essential context: return fields, ranking, scope, and follow-up tool. It could list more example values but is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The free-text adds value by explaining the two-stage refinement for damageType and the scope restriction (premium packs only) not in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's for discovering D&D 5e spells with faceted criteria, limited to premium book packs, and explicitly excludes SRD. This distinguishes it from sibling search tools like search-compendium-creatures and search-compendium-items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage guidance: use this to find candidates and then get-compendium-entry for full details. It explains the two-stage refine for damageType. While not explicitly excluding alternatives, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: partial updates (patches only fields passed), at least one required field, GM-only execution, and strict scene+note-id resolution. It does not mention error handling or response format, but the disclosed traits are sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, packed with information. The first sentence front-loads the primary action and key capabilities. It is efficient, but the first sentence is slightly long. Overall, it earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 10 parameters, no output schema, and no annotations, the description provides substantial context: the patch behavior, required fields, scene/note resolution, and GM-only restriction. It lacks details on return values or error conditions, but these are partially mitigated by the schema's parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline is 3. The description adds semantic value beyond the schema by grouping actions (nudge, relabel, resize, etc.) and explaining the 'global' field's purpose (fog occlusion, not permission control). This helps an agent understand parameter intent better than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing map-note pin by id and lists all modifiable attributes (position, label, icon, etc.). It distinguishes from create/delete siblings by specifying 'Nudge ONE existing map-note pin' and refers to the 'legend→pins review loop', making its purpose highly specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (GM-only, part of review loop, strict resolution) but does not explicitly state when not to use this tool or suggest alternatives. However, the context strongly implies it is for modifying existing notes, and sibling tool names like create-scene-notes and delete-note cover the other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool 'styles + appends' the blocks, is 'append-only,' and mentions visibility inheritance for new pages. These are behavioral traits beyond basic schema details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. Every sentence adds value without redundancy. It efficiently covers purpose, usage, and key parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and absence of output schema, the description provides sufficient context: block types, page targeting, visibility options, and a note about requiring a heading block. An agent can correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 minimal extra meaning (e.g., 'you supply the words as blocks; the tool styles + appends them'), but the schema already thoroughly describes each block type and parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Append a new styled section to a quest/journal page from typed blocks'. It specifies the verb 'append', the resource 'quest/journal page', and the mechanism 'typed blocks'. It also mentions the specific context '§8 session-log/progress path', distinguishing it from general journal update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'By default appends to the first text page; use pageId to target a page, or newPageName to start a new page.' It also notes 'Structuring only,' implying the tool handles structure rather than raw content. However, it does not explicitly state when not to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: creating parent folders, skipping existing files unless overwrite, optional includeExt filter, reporting counts, and privacy implications. It does not mention rate limits or performance but covers essential traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with bullet points. Every sentence provides important information. The opening label 'Plane B (file channel, write)' is jargon but still informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is fairly complete. It covers privacy, required environment variable, behavior on existing files, and error reporting. Could explicitly mention the return format, but the report counts are implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context beyond the schema: explains localRoot as absolute path, remoteRoot relative to Data/, the resulting file layout, and clarifies includeExt filtering. This adds value for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: recursively uploading a local directory tree of assets to Foundry data area, preserving subtree layout. It distinguishes from siblings (e.g., upload-asset) by emphasizing bulk imports and recursive upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (bulk imports, scene pack images, tiles folder) and a warning against world-DB paths. However, it lacks explicit when-not-to-use guidance and direct comparison to alternatives beyond 'instead of one upload-asset per file'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool authors condition state, is not an automation loop, and is D&D 5e only. It could mention permission requirements or reversibility, but overall transparency is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a brief note. It is front-loaded with the core purpose and then adds specifics in a logical order. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, no annotations, no output schema), the description covers purpose, usage, parameters, and system specificity. It could mention return behavior or effects on existing conditions, but remains fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value: lists example conditions, explains exhaustionLevel semantics, and notes that actorIdentifier can accept a token ID for instance-specific application. This goes beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies or removes conditions on an actor, listing specific condition examples. It distinguishes itself from siblings by explicitly noting it is not a combat-automation loop, which sets it apart from potential automation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on how to use: system-specific (D&D 5e), toggling with active boolean, exhaustion level handling, and how to find the actor identifier. While it doesn't explicitly list alternatives for similar tasks, the context is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: auto-detection of dimensions, auto-generation of thumbnail, folder creation, navigation setting, and import capabilities. It also notes limitations like Foundry regenerating thumbnails and MCP response cap for placeablesPath.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and structured logically. However, it is somewhat verbose with multiple clauses and parentheticals, which could be tightened. Every sentence adds value, but conciseness could be improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 30 parameters, the description covers most aspects: main use, options, edge cases (auto-detect, auto-thumb), best practices, and limitations. It lacks a clear statement about what the tool returns (e.g., the created scene object), but overall is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% description coverage, so baseline is 3, but the description adds significant extra meaning: context on auto-detection, auto-generation, preferring config objects for lights, deep-merging of flags/environment, and server-side reading of placeablesPath. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb and resource: 'Create a Foundry Scene from a Data-relative background image path'. It specifies the unique input method and distinguishes itself from sibling creation tools by covering all scene creation aspects in one call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool, including options like auto-detect, auto-generated thumbnails, importing walls/lights, and setting navigation. It implies comprehensive scene setup but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the safe read-only nature (no mention of deletion), overwrite refusal, remote password requirement, and formats. It could mention that it only exports the current chat log but the parameters allow filtering. Good overall transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences that front-load the main purpose and key behaviors. No unnecessary words or repetition. Every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's primary functions and constraints well. However, it does not specify the return value for local exports (only mentions public URL for WebDAV) and omits that parent directories are created for localPath (though schema mentions it). Given the complexity (6 params, no output schema), the description is nearly complete but has a minor gap in return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by summarizing the overall workflow (local and/or remote, overwrite policy, format kinds) and implying that at least one destination is needed (despite none being required in schema). This clarifies parameter relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a chat transcript to a local file and/or WebDAV path, specifying formats and overwrite behavior. It distinguishes itself from sibling tools like list-chat-messages or delete-chat-messages by focusing on export to persistent storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (exporting chat logs), including prerequisites like MOLTEN_WEBDAV_PASSWORD for remote destinations and overwrite behavior. However, it does not explicitly compare to alternatives or state when NOT to use it (e.g., for simply reading messages instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it labels itself 'read-only', states it lists only immediate (non-recursive) contents, and specifies return details (size/type/public URL). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first defines the tool's function, the second provides usage guidance. No unnecessary words; information is front-loaded and efficiently presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description covers what the tool returns (folders + files with size/type/public URL) and the default behavior. Could mention limits or authentication but is adequate for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already provides a detailed description for the remotePath parameter. The description adds the default behavior (empty/omitted lists root) but does not add significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'contents of a directory under Foundry Data/ root'. It specifies return items (folders + files with size/type/public URL) and gives an example path. This differentiates it from sibling tools like asset-info (single asset) and upload-asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use to browse uploaded assets' with an example, clearly indicating when to use this tool. It does not explicitly mention when not to use or compare to alternatives, but the context of sibling tools makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description reveals key behaviors: spell linking for cast activity, dot-path patching for edits, and the constraint that off-book spells are refused. It does not cover error handling or potential overwrites, but overall provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized, starting with purpose and action overview, then diving into specifics like cast linking and patch editing. It is detailed but not overly verbose; however, some redundancy with schema descriptions could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers main behaviors and constraints, it lacks a clear specification of the output format for the 'list' action. Since no output schema exists, describing the returned data structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond schema, e.g., explaining that actorIdentifier can accept token IDs for instance-specific edits, and that spellUuid is required and links to compendium spells with automatic templates. This enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds, edits, removes, and lists activities on items, specifying it's for D&D 5e. It distinguishes from sibling tools by focusing on activities (attack, damage, etc.) and clarifying it does not run combat, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: target an actor item with actorIdentifier or a world item without. Details each action (add, edit, remove, list) and when to use them, including alternatives like get-actor-entity. Warns against using for combat and specifies required premium-book spells for cast type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses key behaviors: messages posted as GM bridge user, HTML content, image uploads are public, visibility modes explained, and speakerActor capability. Good transparency for a messaging tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single paragraph, front-loads primary action. Could be more structured but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a message posting tool with 9 parameters. Covers main use cases, privacy warning, and GM restriction. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds value beyond schema: explains public nature of uploads, 'public as a character' usage, enrich default, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool posts a message to Foundry chat as GM bridge user with HTML content, visibility modes, and optional speaker. Distinguishes from sibling tools like post-item-card or request-roll by focusing on general chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states GM-only usage and describes when to use visibility modes and speakerActor. Lacks explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 setting token art is default (applyToToken true), the portrait must be still, and token can accept video. It also mentions GM-only permission. No contradictions or hidden side effects are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a clear purpose: core action, nuance about animation, and permission. No redundant words; it is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (2 required), 100% schema coverage, and no output schema or annotations, the description covers the key behavioral aspects, use case, and permission. It could mention the effect on actor.img and token.texture explicitly, but the schema covers parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining the still vs animated distinction and the pattern (JB2A-effect), which goes beyond the schema descriptions. It ties the parameters together meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets an actor's portrait and, by default, the prototype token art. It specifies the verb 'set', the resource 'actor's portrait image' and 'prototype token art', and the constraint of using a Data-relative path. It also distinguishes between still portrait and animated token, providing unique purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'GM-only', indicating who can use it. It explains when to use tokenImagePath (for animated token while keeping still portrait), implying when not to use it. However, it does not directly compare to sibling tools like 'update-actor' which might also modify images, but the specialized nature is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the permission levels (OWNER/OBSERVER/LIMITED/NONE) and bulk operation confirmation. It covers key behavioral details like partial matching and the 'party characters' keyword, though it omits side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the core action and permission levels; the second provides illustrative examples. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description adequately covers usage: permission levels, bulk operations, and confirmation. It could mention error conditions or who can perform the action, but the core functionality is well described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value beyond the schema by clarifying valid values for bulk operations ('all friendly NPCs', 'party characters') and noting partial matching for playerIdentifier. This extra context aids correct parameter use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Set ownership permissions for actors,' a specific verb+resource. It distinguishes from siblings like 'list-actor-ownership' by focusing on modification. Examples of individual and bulk operations further clarify the tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage scenarios ('Make John the owner of Aragorn', 'Give the party observer access'). It implies context but does not explicitly state when to avoid this tool or mention alternatives (e.g., reading ownership via list-actor-ownership).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that fields marked with * are NPC-only (skipped with warning on PCs), explains token field behaviors (tokenName, tokenRing, tokenAutoRotate, tokenRotation), and notes that actorIdentifier can accept token IDs. However, it does not state whether the operation is safe (no destructive hint) or what the return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bullet points and clear categories. It front-loads the purpose and then organizes groups. While informative, it could be slightly more concise (e.g., some details are repeated in schema descriptions).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers most aspects of the tool's behavior and parameters, but it does not mention the return value (no output schema exists). Given the complexity (37 params), the description is fairly complete, but the missing output info is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 84%, so the schema already documents many parameters. The description adds value by grouping parameters into logical categories (identity, details, abilities, etc.) and explaining merge/replace behavior for skills, savingThrows, defenses, and currency. It also clarifies nuances like tokenName decoupling and tokenRotation auto-unlock.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits an existing actor's stat-block fields for D&D 5e, listing specific groups. It distinguishes from sibling tools like update-token, update-actor-item, and manage-activity by explicitly stating what it does NOT do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 (to edit stat-block fields) and when to use alternatives (update-token for placement, update-actor-item for items, etc.). It also advises using list-actors or get-actor to find the actorIdentifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that it's a partial update (patches only passed parameters), leaves behaviors untouched, and is GM-only. While it doesn't detail return values or error handling, it provides essential behavioral context for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and capabilities. Every word serves a purpose—no redundancy. It efficiently conveys all key details without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 7 parameters and nested objects, the description covers core functionality: partial update, GM restriction, and rect convenience. It omits the interaction between rect and shapes (schema covers it), but overall provides sufficient context for correct tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so baseline is 3. The description adds value by explaining the rect convenience as a 'move/resize' action and clarifying shapes replacement. It reinforces the patch semantics, enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a single region by ID and lists specific attributes: rename, recolor, change visibility, replace shapes, or reshape via rect. It distinguishes from sibling tools like create-region and delete-region, and notes it's GM-only, providing a specific verb and resource focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing regions, mentioning 'GM-only' as a constraint and explaining the rect convenience. It does not explicitly state when not to use or compare to alternatives, but the context of sibling tools makes usage clear. The patch behavior is highlighted, aiding decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behaviors: deep-merges for environment/fog objects, clearing links with empty string, re-stamping flags, and crucially states it never touches placeables or activates the scene, with 'GM-only' permission. Since no annotations exist, the description fully informs the agent of constraints and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but efficiently front-loads the main purpose. It uses a semicolon-separated list and clear sectioning. While every sentence adds value, some parameter details could be more terse. It's not the most concise but justifies its length given complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers many aspects: parameter behaviors, usage constraints, and what it does not do. However, it lacks information about return values (since no output schema is provided) and does not mention possible errors or side effects beyond the constraints. For a tool with 26 parameters and nested objects, the description is mostly complete but falls short on return expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the tool description adds significant extra context beyond the schema—e.g., explaining deep-merge behavior for environment and fog objects, giving usage advice ('prefer this over the flat darkness/globalLight knobs when importing'), and providing examples for flags. This elevates the value well above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing Scene document and enumerates specific capabilities (rename, swap background, toggle navigation, etc.). It also explicitly limits scope ('Scene-document only: never touches placeables...') and distinguishes from create-scene by mentioning parity and deep-merge behaviors. This provides a specific verb+resource+scope, fulfilling the highest clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'GM-only' as a constraint but does not explicitly guide when to use this tool over alternatives like create-scene or for non-document operations. It mentions what it does not do (placeables, activation) but lacks 'when-to-use' vs 'when-not-to-use' guidance for sibling tools. The guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: partial updates (patches only passed fields), error handling (unresolved ids reported not fatal), and permission (GM-only). Could add details on concurrency or reversibility but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One well-structured sentence that fronts the core purpose and lists key capabilities without fluff. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with many fields and no output schema, the description explains what can be edited and the patching pattern. It misses details on return values (e.g., confirmation or updated objects), but overall is complete enough for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds context beyond schema by explaining how fields are used (e.g., 'MOVE via x/y') and the patching behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it edits placed ambient sounds by id, lists specific editable fields (x/y, radius, path, volume, etc.), and distinguishes from sibling tools like create-sounds and delete-sounds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies using ids from list-sounds, mentions unresolved ids are non-fatal, and that it's GM-only. However, it could be more explicit about when to use this vs other editing tools like update-tiles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: updates are applied to matched tokens, lockRotation auto-unlock, per-token HP delta, and return values (counts + unresolved ids). It could mention error handling for missing scenes, but overall it's transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long paragraph covering many details. While it front-loads the key distinction, it could be better organized with bullet points or sections for readability. It is not overly verbose given 18 parameters, but structure could improve.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 18 parameters, the description covers return values (matched/updated counts, unresolved ids), lockRotation gotcha, and per-token vs shared state. It lacks some edge cases (e.g., empty token/actor lists) but is largely complete for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra context beyond schema, like explaining bar1/bar2 health bar path, hp per-token delta, and lockRotation interaction. This adds meaningful value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool edits placed tokens, not prototype tokens, explicitly distinguishing from update-actor. It lists editable fields and targeting methods, making the purpose very specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly says when to use (placed tokens) and when not (prototype tokens -> update-actor). It provides guidance on scene resolution, targeting by ids/names, and batch updates. It also includes a 'GOTCHA' about lockRotation, helping the agent use the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'read-only; never mutates', which is essential for behavioral transparency. However, it does not mention potential side effects like processing time or network usage, though the tool is relatively simple.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with numbered rules and clear sections. It is front-loaded with the core purpose and read-only assurance. While somewhat lengthy, the details are necessary for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does and what to do after, but it does not specify the format of the output report (e.g., list of violations). Given the complexity and absence of an output schema, more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described with context beyond the schema, explaining how they are used in the audit (e.g., actorIdentifiers scan actors and their embedded items). The default behavior when no parameters are given is also clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a finishing check for D&D 5e content, scanning for four specific authoring-quality rules. It distinguishes itself from sibling tools by being read-only and audit-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to run (before declaring a build done), how to target specific entities (actorIdentifiers, itemFolders, worldItemIds), and what to do after (fix and re-run). This provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses permanent deletion, GM-only requirement, and strict matching. No behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Purpose, method, restrictions all covered efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter deletion tool with no output schema, description covers all necessary aspects: action, identifiers, strictness, access.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter 'identifiers' is well-described in the schema. Description repeats but adds 'preferred' for ids. With 100% schema coverage, baseline is 3, no significant extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it deletes Scene documents by exact id or name, with strict resolution. Distinguishes from siblings like bulk-delete by specifying exact matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States GM-only and strict resolution, implying use when exact identifiers are known. Does not explicitly mention alternatives but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses resolution by id, exact name, or case-insensitive name, and the special behavior for unidentified items (trueName). No annotations exist, so description carries burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. Front-loaded with core purpose, then resolution methods, then edge case. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes returned data comprehensively (system data, effects, flags, description) and covers the unidentified item case. No output schema, so description fills the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds case-insensitivity and reliability details to the schema's identifier description. With 100% schema coverage, this provides meaningful extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a single world-level Item document with full data, distinguishing it from sibling list-items. The verb 'Retrieve' and resource 'Item' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using list-items first to find ids, providing clear context. Does not cover when not to use or all alternatives, but sufficient for a retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral disclosure. It explains the padding inset and its implication for placeable pixel calculations ('NOT just gridCell×size'), provides the exact returned fields, and notes that no scene activation is needed. No contradictions present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a clear purpose: stating the main function and return values, explaining the padding nuance, and noting the usage context. It is front-loaded with the key action and is free of extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description comprehensively explains what the tool returns and the behavioral nuance about padding. It fully informs an agent about the tool's purpose and output without needing additional schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'sceneIdentifier' described as 'Scene id or exact name.' The description adds minimal extra meaning by reiterating 'by id or exact name' and adding 'works on any scene,' but does not significantly deepen understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a scene's live padded-canvas geometry, specifying exact properties like total width/height, background rect, grid size/rows/columns. This distinguishes it from siblings like 'get-current-scene' which returns general scene data, and 'list-scenes' which lists scenes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for coordinate math ('feeds the legend→pins cell→px math') and notes that it works on any scene without activation. While it doesn't explicitly contrast with alternatives, the context implies use for geometry calculations, and sibling tools like 'get-current-scene' serve different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It explains that the tool copies artwork, full system data, and activities, and it details optional on-copy tweaks. It also describes the different behaviors when targeting an actor versus the world, including the lootCopy mechanism and token instance treatment. However, it omits potential side effects like duplicate handling or error behavior on invalid inputs, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured well: it starts with the main purpose and preference, then provides a workflow, and finally details optional parameters. It is somewhat lengthy but each sentence adds value—no fluff. While it could be more concise, the structure is logical and front-loaded, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema), the description covers the essential context: the tool's core behavior, when to use it, the target distinction (actor vs world), loot handling, and SRD restrictions. It does not explain return values, but that is acceptable without an output schema. Some minor edge cases (e.g., error handling) are missing, but overall it is sufficiently complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for all 11 parameters, so the baseline is 3. The description adds meaningful context beyond the schema, such as explaining the lootCopy default for magic items, the SRD restriction for packId, and the token instance nuance for actorIdentifier. It also provides a workflow that ties parameters together, which enhances understanding. Thus, a score of 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: COPY an existing item from a compendium pack onto an actor or world Items sidebar. It uses a specific verb ('COPY') and resource ('existing item'), and explicitly distinguishes itself from the sibling add-item by stating a preference for real gear. This leaves no ambiguity about what the tool does and how it differs from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: it advises to prefer import-item over add-item for any real piece of gear, provides a three-step workflow (search-compendium, import-item, refine), and specifies when to use add-item (genuine homebrew). It also warns against using SRD packs. This level of detail gives the agent clear when-to-use and when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for behavioral disclosure. It explicitly declares the tool as read-only, implying no side effects. It also lists the returned attributes, giving the agent a clear expectation of the output. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action and key information. Every word adds value: the action, what is returned, data types, and usage context. No unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, no output schema, no nested objects), the description is complete. It explains what the tool does, what it returns, and how it fits into a workflow (inspect → update/delete). No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage (single 'sceneIdentifier' parameter with a description). The tool description adds value by specifying that the parameter refers to the scene holding 'placeables' and by explaining the return fields, which helps contextualize the parameter's role. This goes slightly beyond the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('MAP-NOTE PIN on a scene'), and enumerates the exact fields returned (id, position, label, etc.), making the tool's purpose unambiguous. It clearly differentiates from sibling tools like create-scene-notes, update-note, and delete-note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Read-only' and positions the tool as 'the inspect step that feeds update-note / delete-note', providing clear context on when to use it. While it does not list alternatives or when not to use it, the context is sufficient for an AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden and discloses it is read-only and returns specific data. No mention of authorization or limits, but for a list tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and output, then use-case. Every sentence is essential and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completeness is high: describes input parameter fully, explains return fields, and provides context for usage. No output schema needed as description covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for sceneIdentifier. The tool description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists regions on a scene with specific fields (id, name, bounds, teleporter destinations). It distinguishes itself from siblings like update-region and delete-region by indicating its use for finding region IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is read-only and should be used to find region IDs before using update-region or delete-region, providing clear guidance on when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares the tool is read-only and explains its purpose as a precursor to editing. With no annotations, this covers essential behavioral traits, though it omits details like potential error handling or performance limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with high information density, front-loaded with purpose and return details. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no nested objects, no output schema), the description fully covers purpose, usage, and behavior. No gaps for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed description of sceneIdentifier. The tool description reiterates 'on a scene' but adds no new semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'List', the resource 'Tiles', and the scope 'every Tile on a scene'. It also enumerates the returned fields (id, position, size, etc.), distinguishing it from sibling tools like update-tiles and delete-tiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states this is read-only and the inspect step before update-tiles/delete-tiles, providing clear when-to-use guidance and signaling it should not be used for modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the destructive nature ('Delete'), authorization ('GM-only'), and a behavioral nuance about token IDs affecting the instance's delta. Minor gaps include lack of return value or error handling information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose, identification methods, and an important additional context (token usage). No extraneous words, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's function, authorization, and identification methods. It does not explain return values (e.g., success/failure), which would be helpful, but overall it is sufficient for a simple deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant extra meaning: actorIdentifier can be a token ID affecting only that instance, itemIds are 'most reliable' and suggested from get-actor, itemNames are case-insensitive and can be combined with type. This enriches the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete items'), the target ('already on an actor'), and the identification methods (itemIds and/or itemNames, optionally constrained by type). It also distinguishes from sibling tools that add items or delete other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes 'GM-only' for authorization and advises using 'get-actor' to find item IDs, providing clear context for when and how to use the tool. However, it does not explicitly compare with alternatives like 'delete-item' or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes headless operation, WebGL wait, viewport fitting, marker overlay (view-only), and output, but could mention error handling or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with core purpose, every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately covers all parameters, behavior, and output for a screenshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds context beyond schema (e.g., fit:true/false, mark:true for QA, outputPath default), enhancing understanding despite full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a scene and captures a PNG for visual QA, distinguishing it from sibling scene tools that perform CRUD or get info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains usage for visual QA, imports/maps, and notes GM-only restriction, but doesn't explicitly exclude alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: WebDAV channel, automatic folder creation, public serving of uploaded files, and the risk of LevelDB corruption for disallowed paths. Also mentions required password.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise but packed with essential information. Front-loaded with channel and purpose. Every sentence adds value, though could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a tool with no annotations and no output schema. Covers purpose, usage, behavioral traits, and parameter details. Could mention failure handling, but return value is stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by clarifying remotePath is relative to Data/ root, providing an example, and warning against world data/ directories. Overwrite default is noted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (Upload), resource (ASSET), and channel (WebDAV). Explicitly states it returns public HTTPS URL. Distinguishes itself from siblings like upload-asset-tree and download-asset by specifying it's for single asset uploads and not for world-DB files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context (Plane B, file channel, write), conditions (ASSETS ONLY, not world-DB), privacy warning, and password requirement. Does not explicitly name alternative tools but implies alternatives for non-asset files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: it resolves the actor name, appends a specific UUID link to a GM note, labels with the relationship, and refuses unknown NPCs to prevent dead links. Since no annotations are provided, the description carries the full burden and does so comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundant words. The first sentence front-loads the main action and mechanism; the second provides a key constraint. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, behavior, and a precondition (NPC must exist). However, it does not mention the return value or confirm what happens on success (e.g., modified journal). Without an output schema, this information would help completeness, but the tool is relatively simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining that 'npcName' is resolved to an existing actor and 'relationship' becomes the label on the link. It also clarifies the optional 'pageId' parameter implicitly via the 'GM note' context. Schema coverage is 100%, so the baseline is 3, but the description adds valuable behavioral context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Append a link from a quest journal to a REAL world NPC', and details the mechanism (resolving actor, inserting UUID enricher link in GM note). It uniquely distinguishes itself from sibling tools like update-quest-journal or create-note by its specific purpose of linking to an NPC.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context: it's for linking a quest journal to an existing NPC. It explicitly warns that the NPC must exist ('create the actor first'). However, it does not compare to alternatives or explicitly state when not to use it, missing a clear when-not clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 explicitly declares the tool is 'Read-only' and lists all output fields (id, depth, path, color, parent, document counts, subfolder count). This gives full behavioral transparency with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely packed with information but remains readable. It front-loads the core purpose ('Read the sidebar folder TREE') and uses clear punctuation. Slightly verbose with enumeration of use cases, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description fully compensates by detailing the return fields (id, depth, path, color, parent, document counts) and explicit use cases. For a read-only list tool with one optional parameter, this is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter 'type' has a comprehensive description in the schema itself. The description's mention of the parameter ('Filter to one document type... Omit for the whole sidebar') essentially repeats the schema description without adding new semantic meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads the sidebar folder tree, providing tree order, ids, nesting depth, path, color, parent, document counts. It distinguishes itself from sibling tools by positioning itself as the 'inspect step' missing from other folder tools, explicitly naming update-folder, delete-folder, move-documents, and create tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: to find ids/names for folder operations without guessing. It contrasts with other folder tools that need ids, and implies not to use when simply listing documents. The last sentence 'without guessing what exists' provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: pure and deterministic, deduping ability scores, resolving choices, no compendium lookup, never invents content, and returns an unresolved list. This comprehensively informs the agent 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, front-loading the purpose. Each sentence contributes meaningful information. It is slightly long but remains focused and informative, earning a 4 for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 optional parameters, no output schema, and no annotations, the description covers all necessary aspects: input modes, processing details, return shape ({success, plan, message}), and what the plan contains (abilities, classes, spells, etc.). It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that url/characterId fetch public characters via v5 endpoint, and json is for private characters (common case), including acceptable formats (full envelope or inner data, parsed object or string). This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Parse a D&D Beyond character into a normalized, name-bearing plan for the ddb-import skill,' specifying the verb 'parse' and the resource 'D&D Beyond character'. It distinguishes from sibling tools by focusing on external data parsing and plan generation, not direct PC creation or advancement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two usage modes: fetching a public character via url/characterId or accepting pasted json for private characters. It explicitly states what the tool NEVER does (handle a cookie) and gives context on subsequent steps (skill canonicalizes names). While it doesn't name specific alternatives, the context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It describes the search features (text search, type filtering), return behavior (full details, targeting info for spells), and non-destructive nature. It lacks details on pagination or error handling, but for a search tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concisely written in four sentences, each serving a purpose: purpose, efficiency comparison, features, and usage recommendation. No redundancy or filler. It is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description adequately covers the essential aspects: input behavior, output details (full details with targeting info), and use case differentiation. It could mention the output format more thoroughly, but it is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions are provided. The description adds value by explaining the 'query' parameter searches name/description (case-insensitive), and the 'category' parameter for spells and items. It also clarifies that leaving 'query' empty returns all items of the specified type. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Search within a character's items, spells, actions, and effects.' It distinguishes itself from the sibling tool 'get-actor' by noting it is more token-efficient and avoids loading the entire character. The verb 'Search' and resource 'character contents' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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: 'Use this to find specific spells, equipment, feats, or abilities without loading the entire character.' It also implies when not to use by contrasting with 'get-actor'. The phrase 'More token-efficient than get-actor' provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses mutation (set avatar), default behavior (bridge user), permission requirement (GM-only), and accepted input types. It lacks details on side effects or success indicators, but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences covering purpose, default behavior, input format, and prerequisite. No redundant information, front-loaded with key action, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 params and no output schema, the description covers purpose, defaults, input types, prerequisite, and permissions. It does not mention what the tool returns on success, but overall it is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage), so baseline is 3. The description adds value by clarifying the default for 'user', providing example paths for 'avatar', and referencing upload-asset. This extra context enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set a Foundry user's avatar', specifying the exact verb and resource. It distinguishes this tool from siblings like set-actor-art by focusing on user avatars, and mentions the default behavior for the bridge user, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use (setting user avatar, especially for MCP-Claude), notes the prerequisite of using upload-asset for local files, and states 'GM-only' to indicate access restrictions. This provides clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses resolution by id or name+type, reparenting behavior, and GM-only restriction. However, it does not detail error handling or confirmation of updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The first sentence introduces the action and capabilities, the second provides resolution and usage guidance. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the core functionality (update, rename, recolor, reparent), resolution method, and restrictive audience (GM-only). Missing specifics on success/failure responses but sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining identifier resolution ('exact id or exact name+type') and the special case for moving to root (passing an empty string). It also provides a use-case hint for renaming.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'sidebar Folder', listing specific actions (rename, recolor, reparent). It distinguishes this from sibling tools like 'create-folder' and 'delete-folder' by its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to rename a folder without the 'move-documents + delete-folder dance', providing an alternative. It also notes 'GM-only', setting clear usage constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully bears the behavioral transparency burden. It discloses that updates are partial ('patches only the fields you pass'), unresolved ids are reported, and the tool is GM-only. It also explains internal nesting of emission fields and provides examples like torch flicker.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient paragraph that front-loads the main purpose. Every sentence adds value, covering scope, partial update behavior, error handling, and permissions without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many parameters) and no output schema, the description is thorough. It lists all editable aspects and explains behavior. It lacks explicit return value info, but the partial update and error reporting context suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds semantic value beyond the schema by providing real-world examples ('warm torch', 'add torch flicker'), explaining default values (alpha ~0.3), and clarifying the behavior of partial updates and darkness ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edit one or more placed AMBIENT LIGHTS by id' with specific editable fields like x/y, dim, bright, color, etc. It distinguishes from sibling tools like create-lights and delete-lights by mentioning 'update' and referencing 'list-lights'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after listing lights and for updating existing lights. It provides context on partial updates and GM-only access, but does not explicitly state when not to use it or mention alternatives like create or delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully carries burden. It details partial update behavior (patching only passed fields), error handling (unresolved ids reported, not fatal), permissions (GM-only), and clarifies ambiguous terms like width/height vs scaleX/Y. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph, front-loaded with purpose. Efficient listing of parameters with inline clarifications. While thorough, it could be slightly more structured (e.g., bullet points) for easier parsing, but remains clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description comprehensively covers all relevant aspects: partial updates, error handling, permissions, and parameter groups. For a complex tool with many properties, it provides sufficient context for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by grouping parameters (RESIZE, MOVE) and explaining that scaleX/Y is image zoom within frame, not tile size. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it edits placed tiles by id, explicitly mentions the source (list-tiles), and distinguishes from siblings like create-tiles or delete-tiles. Verb 'edit' and resource 'placed TILES' with specific examples provide high clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage: to update existing tile properties. It mentions partial updates and GM-only restriction, giving clear context. However, it does not explicitly state when not to use it or compare with sibling tools for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description discloses key behaviors: edits apply only to the world copy, not the source; modifications affect all copies when quantity > 1; placement and disposition defaults are explained. However, it could mention potential rate limits or permission requirements, but covers essential mutation behavior thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that front-loads the core purpose. It uses bold for key terms but could benefit from bullet points or section breaks for readability. Despite length, every sentence adds necessary detail; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with nested objects, no output schema, and multiple use cases (simple copy vs. prefab-as-base), the description fully covers both paths and references sibling tools (search-compendium, update-actor, author-npc). Provides enough context for an agent to correctly decide usage and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds substantial meaning: packId restricted to premium books, names shown with examples, modifications detailed with the update-actor shape, disposition with authoring policy, placement with coordinates requirement. This significantly aids parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as copying actors from premium-book compendium packs, distinguishing it as the default path for official content and contrasting with author-npc for hand-authored NPCs. It specifies the action (copy), source (compendium), and key variant (prefab-as-base with modifications).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to first find the entry via search-compendium/get-compendium-entry and then pass packId, itemId, and names. Provides clear alternatives: use author-npc for no compendium base, and explains the modifications parameter for the prefab-as-base bridge. Also gives disposition default rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that behaviors pass through verbatim, teleportToken requirements, and returns created region ids. Lacks mention of error behavior or idempotency, but overall strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact single paragraph, front-loaded with key info (verb, constraint, sibling relationship). Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with no output schema, description covers input requirements (scene must exist), shapes format, behaviors caution, and return value. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value: clarifies shapes are in canvas px with type examples, explains visibility values, and adds behavior constraints beyond schema. Not perfect, but adds meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Create', resource 'Regions', and context 'on an EXISTING scene'. Distinguishes from sibling 'create-teleporter' by noting it is the general primitive behind it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'GM-only' and recommends using 'create-teleporter' for the two-new-region convenience, providing 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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns minimal metadata without descriptions and is optimized for token usage. It also notes that identifier can accept a token ID for live state. However, it does not explicitly state that the operation is read-only or safe, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences and a clear structure: purpose, what is returned, when to use, and alternative. It front-loads the core purpose. While efficient, it could be slightly more compact by merging the last two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the return data comprehensively: stats, actions, effects, items with minimal metadata. It also addresses the token ID use case. The description is complete enough for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the identifier parameter with a brief description. The tool description adds significant value by explaining that the identifier can be a character name/ID or a token ID, and elaborates on how token IDs work (live state, unlinked NPC can differ), which is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves D&D 5e character info optimized for minimal token usage, listing specific returned data (full stats, action names, active effects/conditions, items with minimal metadata). It distinguishes itself from the sibling tool get-actor-entity by directing users to that tool for full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 ('Perfect for checking equipment or identifying what to investigate further') and when not to use it ('Use get-actor-entity to fetch full details for specific items, spells, or effects'), providing clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly states 'Read-only', which is a key behavioral trait for a listing tool. It also implies no filtering by saying 'List every Drawing on a scene', which informs the agent about data volume and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource, then efficiently lists all returned fields. No unnecessary words or redundancy. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is comprehensive. It explains what the tool lists, the fields returned, its read-only nature, and its role in a sequence with update/delete. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add any additional meaning beyond the schema's description of sceneIdentifier. The parameter's purpose is already clear from the tool name and schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'List' and the resource 'Drawings on a scene'. It enumerates the exact fields returned (id, origin, shape type, dimensions, etc.), distinguishing it from sibling tools like update-drawings and delete-drawings by noting its role as the 'inspect step' before those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'the inspect step before update-drawings / delete-drawings', giving clear guidance on when to use this tool and pointing to alternative tools for subsequent mutations. Also declares it is 'Read-only', which helps the agent decide safety.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses that the tool is read-only and serves as an inspection step before modification. It also warns about the large number of walls in populated scenes and recommends the doorsOnly filter. No behavioral traits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: what the tool returns, guidance on filtering, and behavioral context. It is front-loaded with the most critical information (purpose and field list) and contains no redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema, no annotations), the description provides sufficient context: return fields, filtering advice, read-only nature, and relation to sibling tools. An AI agent can confidently decide when and how to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (100% coverage). The description reinforces the doorsOnly parameter by contextualizing its use ('the usual edit loop'), but does not add new semantic information beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List walls on a scene' and enumerates the fields returned (id, segment, channels, etc.). It distinguishes this from sibling tools like create-walls, update-walls, and delete-walls by positioning it as the 'inspect step before update-walls / delete-walls.' This provides a specific verb+resource combination with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides usage: 'A populated scene carries HUNDREDS of walls: pass doorsOnly:true to get just the doors (the usual edit loop).' It also labels the tool as 'Read-only; the inspect step before update-walls / delete-walls,' clarifying when to use this tool versus its mutating siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description thoroughly discloses behaviors: auto-creates missing folders, default refusal with report, relink/force options, refusal of world-DB paths, and required password.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single focused paragraph with all key information front-loaded (purpose, constraints, authentication). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all relevant aspects for a complex move tool: behavior with references, folder creation, overwrite, authentication, and constraints on paths.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds context to boolean flags (force, relink) and explains path behavior (auto-create folders). Does not repeat schema descriptions, adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool moves/renames a file under the Foundry Data/ root over WebDAV, with specific reference-aware behavior. Distinguishes from simple move by detailing relink/force options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use relink:true vs force:true, and notes that it refuses live world-DB paths. However, does not explicitly contrast with sibling tools like copy-asset or relink-asset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains how tokens are built from prototypes with overrides, and that actors can be repeated. It could mention immediate placement or scene activation, but overall transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four well-structured sentences front-loading the purpose, followed by details. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema, but the tool is a command with no return value expected. The description covers input behavior well. Could mention result or side effects, but adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: it explains that tokens inherit prototype defaults, that 'actor' accepts ID or exact name, and coordinates are in absolute canvas pixels. This enriches the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places actors' tokens on a scene, using batch encounter prep as an example. It distinguishes from sibling tools like create-tokens or update-token by focusing on placing from prototypes in bulk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that this is for scripted/batch placement, contrasting with manual dragging in the app. Also specifies GM-only access, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Details the Activity system, behavior for items without activities, auto-targeting degradation headless, and GM-only restriction. Lacks explicit mention of side effects or permissions beyond GM-only, but adds significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with main purpose, no wasted words. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main use cases, error condition (no activity), and headless behavior. No output schema exists, but description hints at return (clear reason or card). Minor gaps in error handling details, but sufficient for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter's description adds value beyond the schema: explains action enum values (use/attack/damage), consume resource spending, activity selection, and critical option for damage. Schema coverage is 100%, but description enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it posts a rich dnd5e card with interactive buttons or rolls attack/damage, specifying the resource (actor's item/feature/spell) and distinguishing from plain cards via send-chat-message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (for interactive buttons without a module) and when to use an alternative (send-chat-message for plain cards). Also notes GM-only restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it only affects the map instance (not actor), missing IDs are reported but never fatal, and it requires GM permissions. This is comprehensive and honest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences that front-load the core action and add necessary nuance (survival of actor, missing IDs, GM-only). Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param tool with full schema coverage and no output schema, the description covers key aspects. It could explicitly mention return behavior (e.g., list of missing IDs), but the note that missing IDs are reported implies this. Overall very solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions). The description adds value by clarifying that tokenIds come from list-tokens and are 'placed tokens', and that the sceneIdentifier refers to a scene holding placeables. This enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes placed tokens from a scene by token ID. It distinguishes from delete-actor by specifying that only the map instance is cleared while the sidebar actor survives. This is a specific verb-resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use this tool to remove placed tokens without deleting the actor; use delete-actor for full removal. It also mentions prerequisites (token IDs from list-tokens), that missing IDs are safe (non-fatal), and that the tool is GM-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It does so comprehensively: it searches names only (not descriptions/traits), matches all whitespace-separated terms, sorts premium-first and exact-name first, and limits results to 50. There are 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with the main purpose, then detailing constraints and alternatives. Every sentence adds necessary information without redundancy. It is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description explains the search scope, limitations, and suggested follow-up tool (get-compendium-entry). It could be slightly more explicit about the output format (e.g., returns a list of matching pack entries), but it is sufficient for an AI agent to understand usage and next steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the search behavior (e.g., 'Use broad, simple terms') beyond the schema. For example, it clarifies that the query is matched only against names, not descriptions, which the schema's description doesn't explicitly state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Broad NAME search across the premium book compendium packs'. It distinguishes from siblings by noting that SRD packs are not searched and that type-specific tools exist for faceted discovery. This is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 ('quick name lookup') and when not to ('for faceted discovery by real system data... use the type-specific tools instead'). It also specifies that SRD packs never appear, setting correct expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It transparently states that the tool is backed by the Compendium Browser using real system data for CR/type/size, notes that hasSpells and hasLegendaryActions are approximate index flags, and specifies the output fields (id, name, type, uuid, pack, packLabel, img, facets) and ordering (premium-first). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph with no wasted words. It is front-loaded with the core purpose in capital letters, then sequentially covers constraints, data source, output format, and workflow hints. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (including an enum and nested object) and no output schema, the description covers the scope, data source, approximate flags, output fields, and recommended workflow. It could briefly note that all parameters are optional, but the schema already indicates no required parameters. The description sufficiently prepares the agent for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the baseline is 3. The description adds value by clarifying that hasSpells and hasLegendaryActions are approximate flags, and for challengeRating suggests using ranges for broader discovery. While it doesn't expand much per parameter beyond the schema, it provides useful context for effective use of the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: find D&D 5e creatures matching faceted criteria from premium Actor packs only, explicitly excluding SRD packs. It distinguishes itself from sibling search tools like search-compendium, search-compendium-items, and search-compendium-spells by specifying the scope and data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: for creature discovery across premium packs while the SRD is excluded. It also suggests a workflow: use this to identify candidates, then pull full stat blocks with get-compendium-entry. It mentions high result limits for encounter-building surveys, providing context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavioral traits: in-place application, rollback on failure, dry-run mode that doesn't modify the actor, multiclass proficiency subset, HP/feature/spell-slot scaling, and the return structure. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: every sentence adds value, starting with the core action, then nuances, then alternatives and error handling. It is well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, no output schema, and no annotations, the description is remarkably complete. It covers all key aspects: input parameters, behavior, dry-run, rollback, return values, and cross-references to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds significant meaning for most parameters: className behavior, actorIdentifier requirement, choices structure detailed as level->advancement-id->{chosen,selected,uuid}. However, acceptDefaults and hpMode are not explicitly mentioned, relying on inference. Still, it compensates well overall.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds one level to an existing PC, distinguishing between single-class and multiclass levels. It also explicitly distinguishes from sibling tools like create-pc, update-actor, and add-feature by specifying their roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 versus alternatives: ASI bumps must be done via update-actor, feats via add-feature. It also explains the dry-run pattern and rollback behavior, giving clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It thoroughly discloses behaviors: offline-only, dual-era support (v10/NeDB vs v13/LevelDB), stripping pack artifacts, emitting path rewrite hints, discovering standalone tiles, and paging response truncation. No contradictions present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core action, but it is lengthy (multiple paragraphs). Every sentence adds value, but minor redundancy exists (e.g., repeating offline nature). Slight conciseness improvement possible without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, offline-only, paging, path rewriting), the description is highly complete. It covers all behavioral aspects, parameter usage, return structure, and integration with sibling tools, leaving no significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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: it explains the purpose of each parameter in the overall workflow (e.g., destRoot for path rewriting, index for survey, offset/sceneLimit for paging, packName for filtering) and their interplay, surpassing basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it reads a Foundry SCENE-PACK MODULE off disk, detailing the content (module.json + compendium packs) and output (era-normalized documents for import). It distinguishes itself from sibling tools like create-scene (which handles online scene creation) and import-cards/import-item by being offline and module-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: offline reading of Tom-Cartos-style packs for import, with explicit instructions for survey mode (index:true), paging (offset, sceneLimit), and integration with create-scene for payload files. It also explains when to use each parameter, effectively guiding the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes behavior: patch applies values as-is, arrays replace whole; deletePaths are converted to Foundry deletion form; actorIdentifier accepts token IDs for delta edits on placed tokens. This goes beyond schema details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no wasted words. Key information is front-loaded regarding purpose and operations, and supplementary details follow logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with only 2 required and no output schema, the description covers all essential aspects: the capabilities, how parameters work, and important nuances (e.g., token handling). It is fully sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning with concrete examples for patch and deletePaths, and explains the token instance behavior for actorIdentifier, providing practical context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits an embedded item on an actor, detailing specific operations (patch, deletePaths, name/img). It explicitly distinguishes from the sibling manage-activity tool, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool (low-level item editing) versus when to use manage-activity (activities). It also recommends using get-actor or get-actor-entity to find the item and paths, offering clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses destructive behavior (content replaces existing), creation of new pages (newPageName), and that tool is GM-only. No annotations present, so description fully handles transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, four sentences with clear front-loading. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main use cases and distinguishes from sibling, but lacks description of return value or error handling. Acceptable for a straightforward update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by explaining interactions between pageId, newPageName, and content. Schema coverage is 100%, but description provides additional context on conditional behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it updates a journal entry by renaming or modifying page content, and distinguishes from update-quest-journal for quest-style updates. Specific verb 'update' with resource 'JournalEntry'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (generic update) and when not to (use update-quest-journal instead). Provides conditional logic for page targeting and notes GM-only restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: results is destructive (deletes and recreates entries), editResults leaves other entries byte-identical, bad edits are isolated and reported, range overlap/gap is warned, and uuid references to SRD are refused. It also notes GM-only restriction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured, starting with the overarching purpose and then detailing the two modes. Every sentence provides essential information, though some redundancy (e.g., repeated warnings) could be trimmed. It remains efficient for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, two modes, no output schema), the description covers all necessary aspects: parameter behavior, mode differences, SRD restrictions, error handling, and access restrictions (GM-only). It adequately prepares the agent to use the tool correctly without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains the difference between editResults and results, the auto-assignment of ranges, the SRD restriction, and the use of `name` vs `text` vs `uuid`. For editResults, it clarifies how to target entries via `roll` or `resultId`. This significantly aids the agent in using parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool updates RollTable fields and entries, with two distinct modes: targeted edits via editResults or destructive whole-set replace via results. It distinguishes itself from create-rolltable and delete-rolltable by specifying updating behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use each mode: editResults for fixing individual entries (e.g., a typo) while preserving others, and results for replacing all entries. It implies to use get-rolltable for reading, and notes that the tool is GM-only, providing clear guidance on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the mechanism: reconstructs old→new id maps from provenance flags and rewrites teleportToken destinations. Discloses idempotency, GM-only restriction, and non-destructive handling of external pointers. Fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise six-sentence paragraph. Front-loaded with main purpose. Every sentence adds essential context: why needed, mechanism, idempotency, error behavior, and usage instruction. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (import process, teleporter remapping) and lack of output schema, the description covers all necessary aspects: purpose, why fresh IDs cause issues, required parameter, invocation timing, idempotency, and reporting of out-of-import destinations. Complete for intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (sourceModule) with 100% schema coverage. The description adds significant meaning: explains how it's used ('reconstructs the old→new scene/region id maps from the provenance flags') and provides an example ('the read-pack module.id'). Clearly explains role beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Second pass of a scene-pack import: rewrite cross-scene teleporter destinations after the scenes + regions have been created.' It identifies the specific verb (remap), resource (teleporter destinations), and context (post-import). This distinguishes it from sibling tools, none of which handle teleporter remapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Call it ONCE after all chosen scenes are imported. GM-only.' It explains when to use (after scenes created, before teleporters functional), idempotency (safe to re-run), and error handling (reports external destinations rather than silent drop). This leaves no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fvtt-mcp-molten5e MCP server](https://glama.ai/mcp/servers/Txpple/fvtt-mcp-molten5e/badges/card.svg)](https://glama.ai/mcp/servers/Txpple/fvtt-mcp-molten5e)

Score Badge

Copy to your README.md:

[![fvtt-mcp-molten5e MCP server](https://glama.ai/mcp/servers/Txpple/fvtt-mcp-molten5e/badges/score.svg)](https://glama.ai/mcp/servers/Txpple/fvtt-mcp-molten5e)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Txpple/fvtt-mcp-molten5e'

If you have feedback or need assistance with the MCP directory API, please join our Discord server