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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only names the high-level action and does not indicate whether this reads the certificate store, requires privileges, writes files, or has other side effects. The export boolean hint lives in the schema, not the description.

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 six words with no filler and a clear front-loaded verb. It is very concise, though its brevity leaves some behavioral context to be inferred; every word still 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 no annotations and no output schema, the description is too thin. It does not explain what the tool returns, whether exporting writes files when export=true, or what happens when invoked with no arguments. An agent is left to infer expected behavior from the tool name and schema alone.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description adds no parameter-level detail beyond the schema's explanations of 'store' and 'export', but it does not need to because the schema already documents both 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 states a concrete action ('Export') and a specific resource ('certificates with private keys'), which clearly differentiates it from sibling mimikatz tools focused on credentials, Kerberos, and SAM. The purpose is immediately obvious and unambiguous.

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

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

There is no explicit when-to-use guidance or comparison to alternatives. The resource name implies this is for certificate-related tasks, but the description neither states when to choose it over other mimikatz tools nor mentions prerequisites. Usage is only implied.

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

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

With no annotations, the description must disclose safety-relevant behavior, but it only says commands are executed. It does not mention that arbitrary Mimikatz commands can dump credentials, require privileges, or have significant 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?

A single, front-loaded sentence with no filler or redundancy. It earns conciseness points, but 'custom' remains vague and could have been clarified without much extra length.

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

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

For an arbitrary command-execution tool with no annotations and no output schema, the description is too thin: it omits usage role, command syntax examples, output behavior, and risk/privilege prerequisites.

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 fully describes the 'commands' parameter as an array of strings with 100% coverage. The description adds no new parameter-level meaning, so the baseline 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 names a clear action ('Execute') and object ('custom Mimikatz commands'), and 'custom' separates it from the fixed-purpose sibling tools. It does not fully define what 'custom' entails, but it is not a tautology.

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

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

There is no guidance on when to use this generic tool instead of the many specific siblings (e.g., mimikatz_sekurlsa_logonpasswords). The word 'custom' implies a fallback role, but the intended selection criteria are left to inference.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Decrypt DPAPI master keys' implies an operation but does not explain side effects, required privileges, whether SYSTEM hive access is mandatory, what happens when keys are missing, or what the output looks like.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently states the core action and resource, making it easy to parse quickly.

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 there are no annotations, no output schema, and the tool operates on security-sensitive DPAPI data, the description is too sparse. It lacks necessary context about when an agent should choose this tool, what inputs are expected in practice, and what result or side effects to anticipate.

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 no extra meaning beyond what the schema already states for 'guid' and 'system'; it does not clarify how the parameters interact or whether both are 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 states a clear verb and resource: 'Decrypt DPAPI master keys.' This is specific enough to identify the tool's function within the mimikatz family, but it does not explicitly contrast it with siblings such as mimikatz_lsadump_secrets or mimikatz_crypto_certificates, so it falls short of full differentiation.

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

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

There is no guidance on when to use this tool versus alternatives like mimikatz_custom or other DPAPI-related operations. No context is given about online versus offline use cases, prerequisites, or typical workflow placement.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It states the action and result but omits that this forges a credential — a high-impact, detectable offensive action requiring domain-equivalent privileges — and that it leaves a persistent backdoor. 'Create' implies mutation, but the operational gravity and security posture are undisclosed.

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

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

A single, nine-word sentence with zero filler. The core purpose is front-loaded and 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 7-parameter offensive tool with no annotations and no output schema, one sentence is inadequate. It doesn't describe expected results (the ticket file written to output), the dependence on a prior KRBTGT hash acquisition step, or the safety implications, leaving an agent unable to gauge impact before invoking.

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

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

Schema description coverage is 100%, and each of the seven parameters (domain, sid, krbtgt_hash, user, id, groups, output) is already self-explanatory with sensible defaults documented. The description adds no parameter information, but under 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 uses a specific verb ('Create') and clearly identifies the resource ('a Golden Ticket') with its intent ('persistent domain access'). The term 'Golden' inherently distinguishes it from the sibling mimikatz_kerberos_silver tool, though the description doesn't explicitly name that alternative.

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

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

No guidance is given on when to use this tool versus siblings like mimikatz_kerberos_silver (service tickets), mimikatz_kerberos_ptt (injecting an existing ticket), or prerequisites such as needing an already-obtained KRBTGT hash via dcsync. The phrase 'for persistent domain access' implies a persistence scenario but offers no exclusions, preconditions, or alternative routing.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It implies a read-only listing but does not disclose ticket output format, privilege requirements, or side effects such as writing .kirbi files when export is enabled. The export behavior appears only in the schema.

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

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

The description is a single, front-loaded sentence with no filler or repetition. It states the action, the resource, and the scope efficiently.

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 list tool with one optional parameter and no output schema, the description plus parameter schema is minimally viable. However, without annotations it lacks behavioral context, and it offers no guidance on how this relates to sibling mimikatz commands.

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

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

Schema description coverage is 100%, and the single optional export parameter is already documented in the schema. The description adds no additional meaning about parameters, 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 states a clear verb ('List'), a specific resource ('Kerberos tickets'), and a scope ('in current session'). This distinguishes it from the many sibling mimikatz tools, especially mutation-focused ones like golden, silver, ptt, and purge.

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 no explicit guidance on when to choose this tool over its siblings, nor any exclusions or prerequisites. 'In current session' gives scope but does not help an agent decide between this and related kerberos or sekurlsa tools.

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

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

No annotations are provided, so the description carries the full burden of explaining behavior. It discloses that a ticket is imported into the current session, but it does not mention side effects, required privileges, expected output, or that this modifies the session's Kerberos ticket cache. This is a thin description for a security-sensitive operation.

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

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

A single, front-loaded sentence captures the tool's core function with no filler. Every word contributes meaning, and the widely recognized 'Pass-the-Ticket' label reinforces the intent.

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

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

For a one-parameter tool, the description is mostly sufficient to know what to pass. However, it lacks practical context about when this step is needed in an attack workflow, what happens after import, and any prerequisites or caveats. An agent could invoke it correctly but with limited understanding of consequences.

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 'ticket' parameter described as a path to a .kirbi file. The description adds no parameter-level detail beyond the schema, 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 states a specific action, 'Import a Kerberos ticket', and a clear scope, 'into the current session'. It is distinct from sibling tools that create, list, or purge Kerberos tickets, though it does not explicitly name those alternatives.

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

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

The phrase 'Pass-the-Ticket' and 'into the current session' imply the intended use: after obtaining a ticket file, import it so the current session can use it. However, there is no explicit guidance about when not to use it or which sibling tools to prefer instead.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Purge' implies a destructive action, the description does not state that this invalidates the current authenticated session, that the user will need to re-acquire tickets, that elevated privileges may be required, or how this affects other running processes. For a destructive operation with zero annotation coverage, this is a significant gap.

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

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

A single, front-loaded sentence containing only the essential information: the verb, the object, and the scope. Every word earns its place and there is no filler.

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

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

For a zero-parameter tool the description states the core action adequately, and no output schema means return values need not be described. However, as part of a security-sensitive mimikatz toolset, the description omits the disruptive consequence (loss of all cached credentials, forced re-authentication) and any indication of privileges needed, leaving the agent without full operational context.

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

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

The tool has zero parameters with 100% schema coverage, so the baseline is 4. The description correctly implies the operation takes no arguments by not referencing any. There is nothing for the description to add to the schema, and the description doesn't invent phantom options.

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 ('Purge') plus a clear resource ('all Kerberos tickets') and scope ('from current session'). It is readily distinguishable from sibling tools like mimikatz_kerberos_list, mimikatz_kerberos_ptt, and mimikatz_kerberos_golden without opening any schema.

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

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

The description gives no guidance on when to use this tool versus alternatives. There is no mention of cleanup after ticket-based attacks, no indication that it should be used before testing golden/silver tickets, and no mention that listing (mimikatz_kerberos_list) or injection (mimikatz_kerberos_ptt) are different operations.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create' implies a forging operation, but the description does not explain whether the ticket is injected into memory, saved to disk, or simply produced as output. It also omits any security or side-effect context.

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

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

The description is a single, front-loaded sentence with no wasted words. It is concise but perhaps overly brief, sacrificing useful operational context for brevity.

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

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

This is a security-sensitive tool with 6 required parameters, no annotations, and no output schema, yet the description only provides a one-line summary. It does not explain the tool's role in the broader Kerberos attack flow, what happens after ticket creation, or how it relates to sibling tools like ptt or golden.

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

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

Schema description coverage is 100%, so every parameter already has a clear meaning in the input schema. The description itself adds no parameter-level nuance beyond what the schema provides, which matches the baseline score for high schema coverage.

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

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

The description clearly states a specific action ('Create') and resource ('Silver Ticket'), and adds 'service-specific access' to differentiate it from broader ticket-forging tools. However, it does not explicitly name any sibling tool, so differentiation is implied rather than stated.

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

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

The description gives no guidance on when to use this tool versus alternatives like mimikatz_kerberos_golden or mimikatz_kerberos_ptt. There is no mention of prerequisites, post-creation steps, or conditions that would make this tool preferable.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does disclose two important traits — that this is an attack and that it requires elevated AD rights. But it omits detectability (DCSync generates notable DC logs such as event 4662), the scale of impact when `all` is used, and what the operation returns, all of which are material for an offensive tool with zero annotation safety signals.

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 totaling 14 words: the action is front-loaded and the prerequisite follows immediately. Every word earns its place, with no filler and no restatement of the tool name.

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

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

The description covers the core action and prerequisites, but with no output schema and no annotations, the agent is left without expected output (dumped hashes), the operational difference between syncing one user versus all users, and risk/detectability warnings. For an offensive credential-replication tool, additional context is needed for correct and safe invocation.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents all four parameters, including the caution flag on `all` and concrete examples for `user`. The description adds no parameter-level detail beyond the schema, which is acceptable but not additive.

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 ('Perform DCSync attack to replicate AD credentials'), clearly identifying both the action and its objective. However, it does not explicitly differentiate this tool from sibling credential-dump tools like mimikatz_lsadump_sam or mimikatz_lsadump_secrets, so the agent must infer the network-replication distinction on its own.

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 prerequisite statement ('Requires domain admin or replication rights') provides a concrete condition for when this tool is a viable choice and implies that lower-privileged contexts should use other mimikatz tools. However, it never names alternatives or states when NOT to use DCSync (e.g., when local SAM or memory dumping would suffice), leaving usage guidance implied rather than 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, and the description adds little beyond the one-line summary. It does not disclose privilege requirements, whether the operation is read-only, what output format to expect, or that offline hive paths are supported.

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

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

The description is one short, front-loaded sentence with no filler. The action, target, and scope are all clear in seven words, making it appropriately concise for a tool with such a simple purpose.

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

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

For a tool with no annotations, no output schema, and two optional offline-analysis parameters, this description is too sparse. It does not explain live versus offline operation, required privileges, or how to pick it over related mimikatz tools. The one-liner is insufficient for confident invocation in varied scenarios.

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

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

Schema covers 100% of parameters with clear descriptions for sam_hive and system_hive, so the baseline is 3. The description adds no extra parameter meaning, but no compensation is needed since the schema already carries that 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 states a specific action ('Dump'), a specific resource ('SAM database hashes'), and clarifies the scope ('local accounts'). This makes it immediately distinct from siblings like mimikatz_lsadump_dcsync (domain hashes) and mimikatz_lsadump_secrets.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention that dcsync is for domain hashes, that the hive parameters enable offline analysis, or any prerequisites. The agent must infer usage from the name and schema alone.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states the operation, not requirements like elevated privileges, potential side effects, or the sensitivity of the output. The word 'Dump' implies reading secrets but gives no further safety or context information.

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

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

The description is a single, front-loaded sentence with no filler. The parenthetical example adds useful clarification without bloating the text.

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

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

With no annotations, no output schema, and a security-sensitive operation, the description is too thin. An agent would benefit from knowing expected output, required privileges, and how this relates to the many sibling mimikatz tools. The invocation is simple due to zero parameters, but the behavioral context is missing.

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

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

There are zero parameters, so the description does not need to document parameter details. The baseline for a no-parameter tool is 4, and the description adequately focuses on the tool's action rather than any inputs.

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: 'Dump LSA secrets' with an example of the contents ('service account credentials, etc.'). It identifies the target clearly, though it does not explicitly contrast this with sibling lsadump tools like mimikatz_lsadump_sam or dcsync.

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

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

There is no guidance on when to use this tool versus alternatives such as mimikatz_lsadump_sam or mimikatz_lsadump_dcsync. The description implies it is for LSA secrets but provides no context, prerequisites, or exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does clearly state the core behavior: spawning a command prompt with the current, potentially elevated context. However, it does not disclose whether the prompt is interactive or blocking, what side effects occur, or what the tool returns, so the transparency is only minimally 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 one tight sentence with no filler. Every word contributes meaning, and the main action ('Spawn a command prompt') is front-loaded before the contextual detail.

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 zero-parameter tool this is close to adequate, but the absence of annotations and an output schema means the description should clarify what happens after the prompt spawns or offer a usage cue, such as running it after privilege elevation. The lack of any such context, amid 20 similar tools, leaves the agent guessing about the result of 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 has zero parameters and 100% coverage, so the baseline is 4. The description correctly avoids inventing parameter details that do not exist and introduces no ambiguity.

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

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

The description uses a direct verb ('Spawn') and identifies a concrete resource ('a command prompt') with an explicit scope ('current (potentially elevated) context'). This makes it distinguishable from the credential-dumping and Kerberos-focused sibling tools, though it does not explicitly name an alternative the way the strongest definitions do.

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

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

There is no guidance on when to use this tool versus siblings like mimikatz_token_elevate, mimikatz_privilege_debug, or the credential-recovery tools. The agent is left to infer that this is the 'run an arbitrary shell' tool among 20 similar Mimikatz commands.

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

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

With no annotations, the description carries the full behavioral burden. It states the core action—enabling SeDebugPrivilege—but does not disclose whether administrator rights are required, whether the change is scoped to the current process, whether it persists, or any security side effects.

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

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

The description is one short sentence that front-loads the action, names the specific privilege, and states its purpose. Every word contributes meaning; there is no padding or repetition of the tool name.

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 zero-argument utility, the description is adequate: it names the effect and the intended use. However, it omits useful operational context such as required elevation, the fact that SeDebugPrivilege is typically disabled by default, and its relationship to other mimikatz commands that depend on it.

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

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

The input schema has zero parameters, so the description is not responsible for explaining parameter behavior. The baseline for zero-parameter tools is 4, and no parameter-semantics gap exists.

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: 'Enable SeDebugPrivilege,' and 'for process manipulation' explains why this capability matters. This clearly distinguishes the tool from the credential, Kerberos, and LSASS-dump siblings.

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

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

The phrase 'for process manipulation' implies this is a prerequisite or setup step for process-related tasks, but it does not explicitly state when to run this tool versus alternatives like token_elevate or process_list, nor does it note that many other mimikatz commands require SeDebugPrivilege first.

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 bears the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not state whether elevated privileges are required, what 'security context' precisely includes, or whether any side effects or restrictions apply.

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

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

A single, front-loaded sentence contains no filler and communicates the essential action and scope immediately. Every word earns its place.

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

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

With no annotations and no output schema, the short description is minimally viable but leaves ambiguity around the return format and the exact meaning of 'security context.' It is enough to attempt a call, but not enough to fully set expectations for the result.

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

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

The input schema has zero parameters, so there are no parameter semantics to explain. The baseline of 4 applies because no parameter documentation burden exists.

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: it lists running processes and adds a distinguishing qualifier, 'with security context.' Among siblings that focus on credentials, Kerberos tickets, and vault data, this clearly identifies a process enumeration tool.

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

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

There is no guidance on when to use this tool instead of the many credential-focused siblings, nor any mention of prerequisites or exclusions. The intended role within a Mimikatz workflow is left entirely to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, but it only states 'List.' It does not mention required privileges, whether this operation reads from LSASS memory, or any side effects. The description is not contradictory, but it is too thin to reveal meaningful 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 a single concise sentence with no filler, and the action is front-loaded. It earns its place, though its terseness limits how much structural value it provides.

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

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

With no annotations, no output schema, and many closely related sibling tools, the description leaves major gaps: when to prefer it, what rights are needed, and how it differs from other Kerberos-related commands. It is minimally sufficient for a human who already knows the tool, but not complete enough for an AI agent choosing among siblings.

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?

There are zero parameters and an empty input schema, so there is no parameter behavior for the description to document. The baseline of 4 applies because no parameter semantics are needed beyond what the schema already shows.

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 clear verb ('List') with a concrete resource ('Kerberos credentials and tickets'), so the core operation is understandable. It does not differentiate itself from sibling tools such as *kerberos_list, which could plausibly also list Kerberos ticket material.

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

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

There is no guidance about when to choose this command versus mimikatz_sekurlsa_logonpasswords, mimikatz_sekurlsa_msv, or mimikatz_kerberos_list. The only implied context is that the agent wants Kerberos credential or ticket information, which is not sufficient for reliable tool selection.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the operation requires elevated privileges and reads credentials from memory, suggesting a non-destructive but privileged action. It does not disclose effects on LSASS, output behavior, or risk of detection, leaving a moderate transparency gap.

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

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

Two short sentences with no filler: the action, target, data types, and prerequisite are all front-loaded. Every phrase earns its place, and the length is appropriate for the tool's simplicity.

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 is adequate for a simple one-optional-parameter tool, but it omits guidance on when to choose this instead of related sekurlsa or lsadump tools. It also does not describe the output shape or remote-targeting caveats beyond the schema, which is a notable gap given there is no output schema.

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

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

The single optional parameter has 100% schema description coverage, so the schema already explains target_host and its access requirement. The tool description adds no parameter-level detail, which matches the baseline expectation for high 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 uses a concrete verb ('Extract') and names the resource: plaintext passwords, hashes, PIN codes, and Kerberos tickets from memory. It implies the broadest sekurlsa credential dump, distinguishing it from siblings that target a single source like wdigest, kerberos, or msv, though it never explicitly names LSASS or live logon sessions.

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

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

It states the prerequisite of elevated privileges, which is important operational context. However, there is no explicit when-to-use guidance versus sibling tools such as mimikatz_sekurlsa_wdigest or mimikatz_lsadump_sam; the intended selection context is only implied by listing multiple credential types.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states that credentials are extracted but does not disclose required privileges, potential side effects, whether the operation is read-only, or security/AV implications. For a sensitive Mimikatz operation, this is a significant transparency gap.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes meaning: 'Extract' states the action, 'MSV1_0 credentials' states the resource, and '(NTLM hashes)' clarifies the output type.

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 contextually complex: it interacts with LSASS memory, likely requires high privileges, returns credential material, and has many closely related sibling tools. With no output schema and no annotations, the description should at least note prerequisites or expected output shape. It only gives a one-line action, leaving the agent without key operational context.

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

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

The input schema has zero parameters and 100% coverage, so there is nothing for the description to explain about parameters. The description adds value by clarifying what the tool produces, but no parameter-specific documentation 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 names a specific verb ('Extract') and a precise resource ('MSV1_0 credentials'), with a clarifying parenthetical ('NTLM hashes') that indicates the expected result type. This is clear and helps distinguish the tool from wdigest or kerberos siblings, but it does not address overlap with sekurlsa_logonpasswords, so sibling differentiation is incomplete.

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

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

No when-to-use guidance is provided beyond the inherent implication of the action itself. The description does not mention when to prefer this over sekurlsa_logonpasswords, how it relates to the other sekurlsa tools, or any prerequisites such as elevated/system privileges.

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

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

No annotations are present, so the description carries the full burden. It says credentials are extracted from LSASS memory but does not disclose the elevated privileges typically required, the sensitive/permission-sensitive nature of the operation, or any risks 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?

The description is a single efficient sentence with no filler. The action and target are front-loaded, making it easy for an agent to parse quickly.

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 sensitive credential-extraction tool with no annotations, output schema, or parameters, the description is too minimal. It omits operational context such as prerequisites, expected output, and how it relates to other Mimikatz credential-extraction functions.

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 an empty schema, so there is no parameter detail the description needs to add. The baseline of 4 for no-parameter tools 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 a specific verb and resource: extract WDigest credentials from LSASS memory. The WDigest naming distinguishes it from sibling tools targeting other credential types or functions like msv, kerberos, or logonpasswords.

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

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

No guidance is provided about when to use this tool versus siblings such as mimikatz_sekurlsa_logonpasswords or mimikatz_sekurlsa_msv. The description does not mention broader alternatives or conditions that would make WDigest the right choice.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Check' suggests a read-only operation, but the description does not explicitly say so, nor does it mention whether privileges are required, whether the Mimikatz binary is actually invoked, or what failure modes exist (e.g., missing installation, incompatible system).

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

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

The description is a single sentence with no filler. The action is front-loaded, and every word contributes meaning.

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

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

For a zero-parameter status check this is adequate, but with no output schema the description does not tell the agent what result to expect (e.g., boolean, version string, compatibility matrix) or how to interpret 'compatible.' The preflight role relative to sibling tools is implied, not stated.

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?

This tool takes zero parameters and the schema covers 100% of the parameter surface. There is nothing for the description to add about parameter semantics, so the no-parameter baseline of 4 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 states a precise action ('Check') and a clear resource ('Mimikatz installation status and system compatibility'). This clearly distinguishes it from the action-oriented sibling tools, all of which are focused on credential dumping, Kerberos operations, or other post-install activities.

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 status/compatibility framing implies this tool is a preflight check before using the other mimikatz_* tools, but the description never explicitly states when to use it or that it should precede the others. No exclusions or alternative conditions are given.

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

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

Since annotations are absent, the description carries the full burden of behavioral disclosure. It names the core action but omits side effects, privilege requirements, whether the current process is modified, and any security or persistence implications. This is insufficient for a powerful token manipulation tool.

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

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

The description is a single concise sentence with no filler and the core action is front-loaded. Every word contributes to understanding the tool's purpose.

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

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

For a tool with no output schema, no annotations, and optional parameters, the description does not fully explain how to choose between SYSTEM elevation, domain admin elevation, and user impersonation. The lack of mode-selection guidance and preconditions makes it incomplete for an agent trying to invoke it safely and correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description loosely aligns with the 'user' parameter via 'impersonate another user', but it does not explain the 'domainadmin' parameter or the behavior when no parameters are supplied.

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

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

The description states a specific action ('Elevate to SYSTEM token or impersonate another user') on a clear resource type. It distinguishes this tool from the credential-dumping and Kerberos sibling tools, which all target different Mimikatz functions.

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

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

No guidance is provided on when this tool should be used versus alternatives, what prerequisites are required, or how it fits into an overall Mimikatz workflow. The context of token elevation is implied but never explicitly tied to subsequent commands.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the extraction action but omits critical operational traits: the need for admin/SeDebugPrivilege (implied by the sibling mimikatz_privilege_debug), dependence on DPAPI master keys, antivirus/EDR detection risk, and failure modes when the vault is locked, empty, or legacy-only. For a credential-exfiltration tool, this is a significant transparency gap.

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

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

A single sentence with no wasted words; every token carries meaning. The structure is minimal but appropriate for a parameterless tool. It stops short of a top score because a second clause naming the sibling for in-memory credentials would have improved routing behavior without adding bulk.

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 security-sensitive mimikatz operation with zero annotations and no output schema, one sentence is not enough. The agent gets no return-shape information, no privilege prerequisites, no warning about sensitivity or detection, and no clue which of the many credential-dumping siblings covers other sources. The description is incomplete for safe and correct invocation.

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

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

The tool has zero parameters and effectively 100% schema coverage, so the baseline of 4 applies. The description's parenthetical adds mild context about the data involved, and there are no parameters left undocumented. No deduction is warranted.

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

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

The description uses a specific verb+resource pair — 'Dump' + 'Windows Vault credentials' — and the parenthetical '(saved passwords)' clarifies what kind of data is extracted. The Vault target is distinct from siblings like lsadump_sam, sekurlsa_logonpasswords, or dpapi_masterkey, but the description never explicitly contrasts itself with those alternatives, so differentiation is partial.

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

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

There is no statement of when to use this tool versus the 21 siblings. An agent cannot tell from the description whether Vault credentials differ from what sekurlsa_logonpasswords (in-memory logon passwords), lsadump_secrets, or dpapi_masterkey would recover, and no preconditions or exclusions are given. No usage guidance is present.

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