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

With no annotations provided, the description carries the burden of disclosure. It accurately conveys that the tool is a read-only audit trail, but it does not mention output format, pagination behavior, or any access restrictions. The description could go further in explaining what the returned data looks like or any limitations.

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

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

The description is compact and front-loaded, with only three sentences. It wastes no words and effectively covers purpose, usage, and differentiation.

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

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

For a simple optional-parameter audit list tool, the description provides sufficient context: what it does, when to use it, and how it differs from the main sibling. The presence of an output schema covers return values, and the parameter schema covers defaults and filters. It does not mention service_id fallback or ordering, but these are documented in the schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds some context by mapping event examples to categories, but it does not explain parameters beyond what the schema already provides. The use cases like 'whether an action actually went through' implicitly relate to severity/contains but are not explicitly tied to parameters.

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

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

The description clearly identifies the tool as an account audit trail for the service, listing specific event types (restarts, config uploads, settings changes, game installs) and concrete use cases like 'who restarted the server'. It also explicitly distinguishes itself from pz_tail_log by contrasting service actions with game actions.

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

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

The description gives direct call-to-action phrases ('Call this for...') and names the alternative tool (pz_tail_log) for game-specific events, making it clear when to use this tool versus siblings. This is explicit and actionable.

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

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

No annotations are provided, so the description must disclose behavior. It clearly describes a read-only listing operation and the fields returned, but it does not go beyond that. It lacks explicit statements about side effects (though 'list' implies none), authentication requirements, or any caveats. This is adequate but not rich.

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

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

The description is two sentences, front-loaded with the action and resource ('List every service'), and provides essential context without any filler. Every word earns its place.

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

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

With 0 parameters and an output schema present, the description fully covers what the tool does. It explains the scope ('every service on the Nitrado account') and the purpose, making it complete for this simple list operation.

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

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

The tool has zero parameters, and the baseline for 0 parameters is 4. The description correctly omits parameter details since there are none to explain. No further elaboration is needed.

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

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

The description uses a specific verb and resource: 'List every service on the Nitrado account' and specifies the returned fields (id, game, status, expiry). It clearly distinguishes itself from siblings by focusing on the account-level listing, not on specific Project Zomboid operations.

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

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

The description provides a clear and explicit when-to-use instruction: 'Call this when you don't yet know the service_id... or when the user asks what they have hosted.' However, it does not explicitly mention when not to use it or alternatives, though 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.

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

With no annotations provided, the description carries the burden. It discloses meaningful behaviors: the tool reports only differences and redacts passwords unless requested ('Passwords are redacted unless you ask for them'). These go beyond the schema and give the agent important expectations for output. It falls short of fully describing permissions or side effects, but for a read-only diff 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.

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

The description is two sentences: the first clearly states function and output, the second provides use cases and a security note. It is front-loaded, every sentence earns its place, and there is zero wasted wording.

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

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

The tool has an output schema, so return values need not be explained. The description covers purpose, use cases, and redaction behavior. It does not explicitly state that long values are truncated by default, but that is documented in the full_values parameter schema. Overall, it is complete enough for confident tool selection and invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific value; the only mention ('Passwords are redacted unless you ask for them') mirrors the include_secrets parameter description. It does not further clarify any parameter semantics beyond what the schema already provides.

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

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

The description states a specific verb+resource: 'Compare a saved snapshot's server .ini with the one running now, and report only what differs.' It clearly distinguishes the tool from siblings like pz_get_config_profile by emphasizing the diff-only output and the comparison against live config.

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

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

The description gives clear usage context with concrete examples ('what changed since Friday', 'what did I break', 'checking whether an edit actually landed'). However, it does not explicitly mention when not to use this tool or name alternative siblings, so it misses the full 5.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the returned config is an exact snapshot and that passwords are redacted unless requested, which are key behavioral traits. It does not mention error conditions or authorization, but the essential behavior is clearly communicated.

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

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

The description is two sentences, front-loaded with the core action and then adding use cases and redaction behavior. Every sentence earns its place with no unnecessary filler or repetition of schema details.

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

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

The description provides purpose, use cases, and a key behavioral caveat (password redaction), while the parameter semantics are fully covered by the schema and the return behavior is covered by the output schema. The description is compact yet complete for this tool's complexity.

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

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

Schema description coverage is 100%, so all four parameters already have meaningful descriptions. The tool description adds only the redaction note tied to include_secrets, but overall the schema does the heavy lifting, so a baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Return a config file exactly as it was when the snapshot was taken.' It clearly distinguishes this from current-state reads by emphasizing the snapshot aspect and gives concrete use cases like seeing a past setting or recovering a lost value.

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

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

The description explicitly says 'Use this to see what a setting used to be, or to recover a value that was changed or lost,' which provides clear when-to-use guidance. It does not name alternatives or exclusions, but the context is strong enough to infer when this historical read is appropriate.

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

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

With no annotations, the description carries the full burden. It implies a read-only operation via 'Return' and 'see what is already installed', which is adequate for a get tool, though it does not explicitly state safety 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.

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

Two concise sentences: the first states what it returns, the second gives usage guidance. No wasted words, front-loaded with the primary function.

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

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

Given the tool's low complexity, the presence of an output schema, and the clear read-only purpose, the description fully covers its operation and usage. No significant gaps remain.

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

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

The input schema fully documents the single optional service_id parameter, including its default behavior. The description adds no additional parameter detail, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns the current Mods and WorkshopItems lists in load order. This distinguishes it from siblings like pz_set_mods (which changes mods) and pz_get_settings (which retrieves settings).

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

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

The description explicitly advises calling this before changing mods, providing clear usage context. It does not mention alternatives or exclusions, but the 'when to use' is explicit.

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

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

No annotations are provided, so the description carries the burden; it covers size (~270 settings), the effect of the search parameter (narrows and returns documentation), and the fallback behavior (full name/value list without help text). It also frames the operation as a read, implying no side effects. This is strong behavioral disclosure 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.

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

Three sentences, front-loaded with purpose, then details. No wasted words; every clause adds useful information.

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

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

For a read-only tool with two optional params and an output schema, the description covers the main use case, volume expectations, and search behavior. It even ties into a sibling tool (pz_set_sandbox). Thus complete.

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

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

Schema already documents both parameters with 100% coverage, so baseline is 3. The description adds extra semantics for `search`, giving example terms and explaining it also returns in-file documentation, which goes beyond the schema. `service_id` is adequately covered by schema.

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

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

The description clearly states the tool reads sandbox tuning (SandboxVars.lua) and lists example settings (zombie population, speed, loot rarity), which is a specific verb+resource. It also distinguishes itself by instructing to call this before pz_set_sandbox, differentiating it from sibling configuration tools.

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

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

The description explicitly says to call this before pz_set_sandbox to get real setting names and enum numbers, providing a concrete use case. It also advises using `search` to narrow results. It doesn't mention alternatives explicitly, but the guidance is clear.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It does indicate that the operation is a read ('Read the main .ini') and that it returns a parsed object, which conveys the core behavior. However, it does not mention any potential side effects, error conditions, or requirements such as permissions or file existence. The description is adequate but lacks richness beyond the basic read-and-parse behavior.

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

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

The description is two sentences, front-loaded with the primary function, and includes just enough usage guidance. There is zero redundancy or filler; every sentence serves a purpose. It is a model of concise, effective tool documentation.

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

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

For a tool with a single optional parameter, no required fields, an output schema, and a read-only nature, the description is complete. It covers what the tool does, when to use it, and how it differs from the raw-file alternative. The output schema handles return value details, so the description does not need to repeat them.

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

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

Schema description coverage is 100% because the single parameter (service_id) has a full description with default and meaning. The tool description adds no additional information about the parameter, so it does not exceed the baseline of 3 for high coverage. The description's focus on settings output is not tied to the parameter semantics.

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

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

The description clearly states the verb ('Read'), the resource ('the main .ini'), and the outcome ('return it as a parsed key/value object'). It also distinguishes from the sibling pz_read_file by emphasizing that this returns parsed data, making it easier for specific setting lookups. The examples (password, max players, PVP, public name) further clarify the tool's specific purpose.

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

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

The description explicitly tells the user when to call this tool: 'Call this when the user asks about a specific setting'. It also implies the alternative of reading the raw file, which corresponds to pz_read_file, and positions this tool as easier for that use case. However, it does not explicitly name the alternative tool or state when not to use it, so it falls short of a full 5.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It transparently states that it returns only names, ids, and dates, and adds context that this is config history with auto-generated snapshots. It does not mention potential side effects, but for a read-only list operation this is sufficient.

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

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

The description is two sentences, front-loaded with the primary action, and every clause adds value. It avoids repetition and clearly communicates the tool's purpose, data source, and limitations.

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

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

The tool is simple (one optional parameter) and has an output schema, so the description need not explain return values. It provides complete guidance on what the tool does, what it returns, and how it relates to sibling tools.

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

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

The schema covers the single optional parameter (service_id) completely, including its default behavior from the NITRADO_SERVICE_ID environment variable. The description itself does not add parameter-level semantics, so the baseline score of 3 applies.

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

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

The description clearly states it lists saved configuration snapshots, using a specific verb and resource. It distinguishes itself from sibling tools like pz_get_config_profile and pz_diff_config_profile by noting those are for looking inside snapshots.

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

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

It explicitly explains the tool's scope (returns only names, ids, dates) and directs users to pz_get_config_profile or pz_diff_config_profile when they need the contents of a snapshot. This provides clear when-to-use and alternative guidance.

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

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

With no annotations provided, the description carries the full burden. It explains the two modes (list and glob search) but does not explicitly state read-only safety, potential for large result sets, or error behavior. The listing nature is inherently non-mutating, but more caveats could be disclosed.

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

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

Two concise sentences that front-load the primary action and then add usage context. Every word earns its place, with no redundancy or fluff.

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

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

Given a simple list tool with full schema coverage and an output schema, the description adequately covers purpose, usage, and scope. It provides enough context for an agent to decide when to use it, while parameter details are fully handled by the schema.

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

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

Schema descriptions cover all three parameters 100%, including absolute path, glob pattern, and service_id default. The description adds a '*.lua' example but does not significantly exceed the schema's explanatory power, so baseline 3 is appropriate.

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

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

The description clearly states the tool lists a directory and supports recursive glob search, distinguishing it from siblings like pz_read_file (reads file content) and pz_list_logs (targets logs specifically). It also specifies the resource ('directory on the gameserver') and the action ('list').

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

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

It instructs to call this tool to explore the server filesystem beyond known config files, which implies other tools should be used for config files. However, it does not explicitly name alternative tools, so it falls short of a full 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the ordering ('newest-first') and the content of each entry ('kind, size and start time'), which are behavioral traits beyond just 'list'. It also defines the scope (live console plus rotated logs), but it does not explicitly state that it is read-only or mention potential permissions or failure modes.

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

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

The description is two sentences with no redundant words. The first sentence front-loads the purpose and output details, and the second sentence gives practical usage guidance. It is concise and well-structured.

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

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

The tool has a simple input surface (one optional parameter) and an output schema, so the description does not need to explain return values. It covers what logs are included, ordering, available fields, and when to use it, making it complete for effective agent selection and invocation.

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

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

The input schema already provides 100% coverage for the single optional parameter service_id, including its default behavior. The tool description adds no parameter-specific information, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb (List) and identifies the resource precisely: 'the server's log files'. It enumerates specific log types (live console, chat, user, admin, map, pvp, DebugLog-server) and output fields (kind, size, start time), clearly distinguishing it from sibling tools like pz_list_files or pz_tail_log.

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

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

It explicitly states when to call the tool: 'when the user asks what logs exist, or before tailing one you're not sure is there.' This gives clear context but does not explicitly name alternative tools or provide when-not-to-use exclusions, missing the highest bar of the rubric.

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

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

With no annotations, the description carries the transparency burden. It discloses that server names are host-assigned, so paths cannot be guessed, and that this is a discovery operation. It doesn't mention caching/refresh behavior (left to the schema) or side effects, but for a read-only locate operation, it provides useful context beyond simple restatement.

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

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

The description is two sentences, front-loaded with the core purpose, and every word earns its place. The second sentence adds essential guidance without redundancy.

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

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

Given the tool's low complexity (2 optional params) and the presence of an output schema, the description is complete. It states what is returned (absolute paths), which files, and when to call it, making it self-sufficient for an agent.

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

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

The schema covers both parameters thoroughly: refresh's description explains cache bypass, and service_id's description explains Nitrado service id and default. The description adds no additional parameter meaning, so a baseline score of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states the tool's purpose: 'Discover the absolute paths of this server's config files'. It names specific file types (<name>.ini, _SandboxVars.lua, _spawnregions.lua) and distinguishes it from siblings by emphasizing the host-assigned naming and need to call before touching config paths.

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

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

It provides explicit usage context: 'the server name is host-assigned, so call this before touching any config path instead of guessing filenames.' This indicates when the tool should be used relative to other config/file tools, though it doesn't name specific sibling alternatives.

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

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

With no annotations, the description carries the full burden for behavior disclosure. It states output is 'as text' and 'raw contents,' which is helpful, but it does not address edge cases like binary file handling, file-not-found errors, or size limits. This leaves some behavioral ambiguity.

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

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

The description is two sentences, front-loaded with the core action, and every sentence adds useful information (purpose, usage guidance, shortcut options). There is no wasted wording or redundancy.

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

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

Given the tool's simplicity, the output schema covers return values, and the description covers purpose, usage, and path/shortcut behavior. It lacks explicit details on failure modes or limits, but for a basic read tool, the description is sufficiently complete.

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

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

Schema coverage is 100%, so the schema already explains the `file` parameter thoroughly, including shortcuts. The description adds context about absolute paths and shortcuts, but it enumerates only three shortcuts ('ini', 'sandbox', 'spawnregions') while the schema also includes 'spawnpoints,' creating a slight inconsistency. The description still adds value with examples of full file types.

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

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

The description clearly states the tool's function as 'Read a file from the gameserver as text,' with a specific verb and resource. It distinguishes itself from siblings like pz_write_file (write), pz_list_files (list), and pz_tail_log (tail) by emphasizing raw full contents and providing examples such as SandboxVars.lua, a log, or a save file.

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

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

The description provides explicit usage context: 'Call this when you need the raw contents.' This clearly signals when to use it, though it does not explicitly name alternatives or exclusions. It implies a distinction from tailing or listing by focusing on full file reads.

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

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

With no annotations, the description carries full disclosure. It states players are disconnected, restart takes roughly a minute, and warns that status may show stale 'started' briefly. This fully exposes behavioral side effects and timing.

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

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

The description is four sentences, front-loaded with the primary purpose, and every sentence adds meaningful context. No wasted words.

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

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

For a restart tool with an output schema, the description covers the process, timing, side effects, and potential pitfalls. It is fully complete given the tool's simplicity and rich schema.

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

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

The schema already covers both parameters with descriptions, so baseline is 3. The description does not add extra detail beyond the schema, but it also doesn't need to since coverage is 100%.

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

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

The description clearly states the tool's function: 'Restart the gameserver so config or mod changes take effect.' It also distinguishes itself by noting it is the only way to start a stopped server, setting it apart from siblings like pz_stop.

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

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

Explicit guidance is provided: 'Call this after any write, once the user confirms.' It also clarifies when to use it as a start action and warns about interpreting pz_server_status results, giving clear 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.

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

No annotations are provided, so the description must disclose behavioral traits. It conveys that the tool fetches 'live status' and lists the returned data, implying a read-only network query. However, it doesn't explain error handling, data freshness guarantees, or the implications of the optional service_id parameter beyond the schema. This is adequate but not deeply transparent.

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

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

The description is two sentences long, front-loaded with the core status fields and followed by usage triggers. Every word earns its place; there is no redundancy or filler.

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

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

For a simple status tool with one optional parameter and an output schema, the description covers the essential context: what data is returned and when to invoke it. It omits response format details, but those are likely handled by the output schema, and the tool's complexity does not demand more.

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

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

Schema coverage is 100%, with the only parameter (service_id) described as 'Nitrado service id. Defaults to NITRADO_SERVICE_ID when omitted.' The tool description adds no parameter-specific insight, but with full schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as providing live status of the PZ gameserver, listing specific fields (online/offline, address, slots, players, version, memory). This distinguishes it from sibling tools focused on configs, files, mods, and settings, 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.

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

The description explicitly states when to call the tool: 'Call this when the user asks whether the server is up, who is playing, or for the connection address.' This provides clear guidance on use cases, though it does not name alternative tools for non-status queries.

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

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

With no annotations, the description carries the burden. It explains the workshopId/modId distinction and load order implications, which is useful. However, it does not disclose whether the operation is atomic, reversible, or requires a restart, which is typical for a mutation tool. It does signal it's a write operation via 'Update' and 'add/remove/reorder'.

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

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

Three sentences, each delivering useful information: purpose, ID nuance, and usage guidance. No filler or redundancy.

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

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

The description, combined with the fully-described schema, gives sufficient context for a setter tool. It explains the critical domain specifics (ID types, load order) and usage scope. The presence of an output schema handles return value documentation, so the description doesn't need to cover that.

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

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

The schema covers all parameters at 100% coverage, so the baseline is 3. The description reinforces the need for both IDs and load order, but this information is already in the schema's mods parameter description, so it adds marginal value beyond the schema.

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

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

The description clearly states the tool updates Mods and WorkshopItems together, and explicitly says it handles add/remove/reorder of the server's mod list. This distinguishes it from sibling pz_get_mods (which reads mods).

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

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

The description explicitly states when to use it: 'Call this for any add/remove/reorder of the server's mod list.' This gives clear context, though it doesn't explicitly exclude alternatives; the sibling pz_get_mods is obviously for reading, so the guidance is sufficient.

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

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

With no annotations provided, the description carries the full burden and excels. It discloses that changes are in-place, preserves comments/ordering/untouched settings, that values are raw game enums where 1 means a specific option, and that changes take effect after restart. This goes far beyond a simple 'update' and gives the agent critical operational context.

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

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

The description is three sentences long, front-loads the core action, and every sentence adds unique value. There is no fluff or repetition; example syntax is bundled into the parameter guidance. It is dense yet highly readable.

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

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

Despite the tool's complexity (nested objects, enums, side effects), the description covers all major areas: the in-place behavior, the need to consult pz_get_sandbox, the restart requirement, and the rejection of unknown names. Since an output schema exists, not describing return values is acceptable, and the description fully equips the agent to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds valuable semantics beyond the schema: it explains dotted names for nested settings and the raw enum pitfall, while the schema already covers unknown name rejection and provides an example. This additional context justifies a 4.

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

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

The description opens with a specific verb and resource: 'Change sandbox settings in place', clearly identifying the tool's action and target. It distinguishes this tool from siblings like pz_set_settings by emphasizing in-place modification that preserves comments, ordering, and untouched settings. This makes the tool's unique purpose immediately clear.

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

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

The description provides clear usage context: it tells users to use dotted names for nested settings and to look up raw values with pz_get_sandbox first. It also notes the restart requirement, which informs when to apply changes. However, it does not explicitly mention when to avoid this tool or compare it directly to pz_set_settings, though the preservation hint implies the distinction.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals key behavioral traits: it preserves comments/ordering, appends missing keys, and performs an incremental update. This goes well beyond the title and gives a clear picture of non-destructiveness, though it does not cover permissions or failure modes.

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

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

The description is two sentences, front-loaded with the core behavior, and includes valuable context without any fluff. Every word earns its place.

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

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

For a tool with 2 parameters, an output schema, and detailed schema descriptions, the description is sufficiently complete. It explains the main ini behavior and usage context. Minor omissions like explicit relation to sibling tools are not critical given the clear examples.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions example keys, but the schema already documents the settings object and service_id with clear descriptions. The description adds no additional semantic value beyond what the schema provides.

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

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

The description clearly states the tool updates individual keys in the main .ini while preserving comments, ordering, and other options. It also provides concrete examples (PublicName, Password, MaxPlayers, PVP) and distinguishes itself from sibling tools like pz_set_sandbox and pz_write_file by focusing on server settings.

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

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

The description explicitly instructs 'Call this for any change to server settings', providing clear context for when to use the tool. It does not explicitly name alternatives or when-not-to-use cases, but the scope is well-defined.

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

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

With no annotations, the description fully discloses the key behavioral trait: the server stops and remains offline until pz_restart is called. This is a critical side effect that the agent must know, and it is clearly stated.

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

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

The description is two sentences long, front-loaded with the action, and contains no redundant wording. Every sentence adds value: one states the purpose and the other gives usage and consequence guidance.

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

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

Given the output schema exists and the input schema is fully covered, the description provides all required context for an agent to select and invoke the tool correctly: what it does, when to use it, and the lasting effect. No significant gaps remain.

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

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

The input schema already provides 100% coverage with descriptions for both 'message' and 'service_id'. The description adds no extra parameter semantics beyond what the schema states, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Stop') and resource ('gameserver') to clearly state the action. It also distinguishes itself from the sibling pz_restart by explaining that stopping is for explicit shutdown, not for applying config changes.

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

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

Explicit guidance is provided: 'Call this only when the user explicitly wants the server down' and 'to apply config changes use pz_restart instead'. It also states the consequence that the server stays offline until pz_restart, defining the only recovery path.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It adds a useful behavioral trait: 'Only the tail is fetched, so it stays fast on multi-megabyte logs,' implying efficiency and non-full-file reads. However, it does not mention error handling, permissions, or what happens if the log is missing, leaving some transparency gaps.

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

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

The description is two sentences long, front-loaded with the core action ('Read the last N lines of a server log'), and the second sentence adds valuable context without redundancy. Every word earns its place, and it is both concise and well-structured.

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

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

Given the tool has a rich output schema, the description need not explain return values. It covers the main purpose, performance behavior, and common use cases. The only notable absence is explicit guidance on when to use a sibling tool like pz_read_file instead, but the description is otherwise complete enough for the tool's complexity.

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

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

Schema description coverage is 100%, so the input schema already provides detailed semantic meaning for all four parameters (e.g., log kinds, line limits, contains filter caveat, service_id default). The tool description itself adds no parameter-specific information, but the baseline of 3 is appropriate when the schema fully carries the weight.

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

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

The description clearly states it 'Read the last N lines of a server log' with a specific verb and resource. It further distinguishes itself from siblings by listing concrete use cases ('what happened', 'why did it crash', 'who connected', 'show me the chat') and emphasizing that only the tail is fetched, setting it apart from tools like pz_read_file that might read full files.

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

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

The description provides explicit usage context: 'This is the tool to use for...' and lists four common scenarios. It does not explicitly name alternative tools or scenarios when not to use it, but the use-case framing clearly implies the intended scope, which is a slight gap from a full 5.

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

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

With no annotations, the description carries the transparency burden. It discloses that a timestamped .bak is kept, that the file is overwritten, and that changes take effect after restart. This goes beyond schema details, though it doesn't cover error cases or permissions.

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

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

Two sentences, front-loaded with the core action, and no filler. Every clause adds value.

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

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

The description covers purpose, usage guidance, and key behavioral effects. The output schema presumably handles return values. For a file write tool, this is sufficient and complete.

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

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

Schema coverage is 100% with good descriptions for all three parameters, so the description doesn't need to add param detail. It reinforces the whole-file replacement context but adds no new parameter semantics.

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

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

The description explicitly states 'Overwrite a file on the gameserver' with a clear verb and resource, and distinguishes from pz_set_settings by indicating whole-file replacements. This clearly separates it from sibling tools.

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

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

It explicitly states 'Use this for whole-file replacements such as a rewritten SandboxVars.lua; prefer pz_set_settings for individual .ini keys,' providing direct when-to-use and alternative guidance. The restart caveat adds further usage context.

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