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

No annotations provided, so description must cover all behavioral traits. It only states requirement for valid TGT and ability to request multiple SPNs, but omits details like side effects, authentication requirements, or output format for a 16-parameter 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?

Description is brief, uses bullet points for use cases, and front-loads the main purpose. Every sentence adds value.

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

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

Given 16 parameters and no output schema, the description covers core purpose but fails to explain return values or how to interpret results, leaving a gap for complete understanding.

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 has 100% coverage, so parameters are well-documented. Description provides no additional meaning beyond summarizing that service takes comma-separated SPNs, which is already in the schema.

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

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

Description states specific verb 'request' and resource 'Service Tickets (TGS)' for specified SPNs. Clearly distinguishes from sibling 'rubeus_asktgt' which handles TGT requests.

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

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

Provides explicit use cases (e.g., access services after TGT, kerberoasting alternative, S4U prereq). Lacks explicit when-not-to-use or alternatives, but 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?

The description explains that the TGT can be saved to a file, applied to the current session (PTT), or returned as base64. It lists multiple authentication methods and flags like opsec. Without annotations, it carries the full burden but does not discuss side effects or error conditions.

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

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

The description is well-structured with bullet points and example use cases, conveying essential information without unnecessary verbosity. Every sentence adds value.

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

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

Given 17 parameters and no output schema, the description covers authentication methods, output options, and use cases adequately. It could mention prerequisites like domain controller connectivity or error handling, but overall is fairly complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by grouping authentication methods (password, hash, certificate) and providing context for output options (outfile, ptt) through example use cases, exceeding the schema-only information.

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 requests a Ticket Granting Ticket (TGT) using user credentials. It distinguishes from sibling tools like rubeus_asktgs (which requests service tickets) by focusing on TGT acquisition.

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

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

The description includes example use cases (lateral movement, test credential validity, support subsequent ticket operations) that indicate when to use the tool. However, it does not explicitly state when not to use or mention alternatives among sibling 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, and the description does not disclose behavioral traits such as whether the conversion writes to a file or returns data, whether it is destructive, or any error conditions. The tool likely modifies state (e.g., creating a file), but this is not clarified.

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

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

The description is extremely concise, with two short sentences that state purpose and basic action. No unnecessary details, and the key information is front-loaded.

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

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

Without an output schema, the description should explain what the agent receives after conversion (e.g., base64 string, file path). It only says 'usable kirbi ticket' without specifics. Additionally, interplay of optional parameters like ptt or outfile is not explained.

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 covers all 8 parameters with descriptions, achieving 100% coverage. The description does not add new meaning beyond what the schema provides, but the schema itself is adequate, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool converts an AS-REP response to kirbi ticket format, with a specific verb and resource. The tool name itself is descriptive, and the purpose is unambiguous.

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

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

No guidance on when to use this tool versus alternatives like rubeus_kirbi or other conversion utilities. The description does not mention prerequisites or exclusions, leaving the agent to infer usage context.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It explains that the AS-REP response contains encrypted data with the user's password hash, but omits critical details such as required permissions, side effects (if any), stealthiness, rate limits, or any consequences of using the 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 front-loaded with the core purpose in the first sentence, followed by concise bullet points. It is efficient but slightly verbose with repeated details; overall no wasted content.

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

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

Given the tool's complexity (12 parameters, no output schema), the description covers the main use case but lacks details on return values, typical output examples, and behavior under different scenarios. It is adequate but not comprehensive.

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

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

Schema coverage is 100% with parameter descriptions, so the baseline is 3. The description adds context for a few parameters (output format, OU targeting) but does not explain others like creduser, des, or ldapfilter 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 clearly states the tool performs AS-REP Roasting against accounts lacking Kerberos preauthentication, specifies the target vulnerability, and lists features like per-user targeting, output formats, and OU filtering. This distinctively differentiates it from siblings like rubeus_kerberoast.

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

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

The description implies usage for accounts with 'Do not require Kerberos preauthentication' enabled, but does not explicitly compare with sibling tools or provide when-not-to-use guidance. No exclusion criteria or prerequisites are mentioned.

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

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

Without annotations, the description carries the full burden. It mentions using a TGT, the Kerberos Set Password protocol, and targeting other users with permissions. However, it does not disclose potential side effects, authentication requirements, or whether the operation is destructive. The phrase 'just their TGT' is ambiguous.

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

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

The description is three sentences, concise and front-loaded with the main action. It could be slightly more structured (e.g., separate bullet for permissions) but is efficient overall.

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

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

Given no output schema and the tool's security-sensitive nature, the description should explain return values, success/failure indications, and prerequisites. It lacks information on what happens after the password change, and the complexity of Kerberos protocols warrants more 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?

Schema coverage is 100% (all 5 parameters have descriptions). The description restates the target user capability but adds no new semantic information beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool changes/resets a user's password using a TGT via the Kerberos Set Password protocol. It specifies the verb (change/reset) and resource (password), and the technique is distinct from sibling tools like rubeus_asktgt or rubeus_kerberoast.

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

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

The description implies usage when you have a TGT and want to change a password, including targeting other users with permissions. However, it lacks explicit guidance on when not to use it, prerequisites beyond a TGT, or alternatives like using a service ticket.

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 full burden. It discloses that it detects OS/mode and lists tools/config, which is sufficient for a read-only operation. No contradictions.

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

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

The description is two sentences, very concise, and front-loaded with the core purpose. Every sentence adds value.

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

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

For a zero-parameter tool with no output schema, the description covers the main purpose. It could mention that no arguments are required, but overall it is complete.

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

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

There are no parameters, so the description does not need to add meaning beyond the schema. It provides context about what is checked, which 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 explicitly states the tool checks the environment and lists available tools, detecting OS and mode. It clearly distinguishes from sibling tools, which perform specific Kerberos 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?

As a no-parameter diagnostic tool, its use case is self-evident: it is for initial environment assessment. However, it does not explicitly state when to use it vs. alternatives or provide 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?

No annotations are provided, so the description carries the full burden. It discloses that 'The process can be hidden or visible,' which is a behavioral trait. However, it does not mention other important details like whether the tool requires administrative privileges, what happens to the parent process, or if network credentials are stored. Some behavioral information is given but not comprehensive.

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

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

The description consists of three brief, front-loaded sentences. The first sentence states the core purpose, the second explains the utility, and the third adds a behavioral detail. No redundant or irrelevant information. Every sentence 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?

Given the complexity (6 parameters, no output schema, many sibling tools), the description provides a good overview: purpose, use case, and a behavioral option. However, it does not explain the 'logon type 9' concept or clarify behavior when parameters like 'ticket' are omitted. Still, for an agent familiar with Rubeus, it is largely sufficient.

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 only one meaningful elaboration: 'The process can be hidden or visible,' which relates to the 'show' parameter. For other parameters, the description does not add beyond what the schema already specifies (e.g., 'Ticket to apply to new process' is already in the schema description). Limited additional semantic value.

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

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

The description clearly states the action: 'Create a new process with network credentials (logon type 9).' It identifies the resource (a new process) and the specific context of network credentials and applying tickets, which differentiates it from sibling tools like rubeus_ptt (injects into current process) or rubeus_s4u (impersonation). No ambiguity.

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

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

The description explains when to use the tool: 'Useful for applying tickets to a separate process.' However, it does not provide explicit guidance on when not to use it or mention alternative tools (e.g., rubeus_ptt for immediate ticket injection). The usage context is clear but lacks exclusions or comparisons.

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 covers behavior. It indicates a read operation ('Display') that returns a value, with no side effects. The behavior is transparent given the tool's simplicity.

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

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

The description is concise at two sentences, front-loads the main action in the first sentence, and avoids unnecessary details. Every word contributes value.

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

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

For a tool with no parameters, no output schema, and a simple read operation, the description is complete. It explains what is returned and why it is useful, meeting all informational needs.

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 no parameters, so schema coverage is 100%. The description correctly omits parameter details, as none exist. The baseline score of 4 is appropriate since no additional parameter info 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 clearly states the tool's purpose: 'Display the current user's Logon Unique ID (LUID).' It uses a specific verb ('Display') and identifies the exact resource (LUID), which differentiates it from sibling tools that handle ticket 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 usage context by stating that the LUID is 'needed for various ticket operations,' indicating when this tool should be used as a prerequisite. However, it does not explicitly state when not to use it or list alternatives, but the context is clear.

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

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

With no annotations, the description carries the burden. It states it can decrypt ticket contents if a key is provided, but does not clarify whether any state changes occur or what happens on failure.

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 that front-load the main purpose and add a key capability (decryption) and usage context without unnecessary words.

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

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

Given no output schema and no annotations, the description lacks details on return format, error handling, or what specific ticket information is displayed, leaving gaps 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 input schema has 100% parameter description coverage, so the tool's description adds only marginal value by grouping decryption keys; it does not enhance understanding beyond the schema.

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

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

The description clearly states the tool parses and displays detailed information about a Kerberos ticket, and distinguishes it from sibling tools like rubeus_dump or rubeus_klist by focusing on analysis of captured tickets.

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

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

The description mentions it is 'useful for analyzing captured tickets' but provides no explicit guidance on when to use it versus alternatives or when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool requests a real TGT and modifies it, requiring the krbtgt key. However, it does not explain side effects (e.g., network calls, ticket caching) or output behavior, leaving 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 concise at four sentences, front-loading the core purpose. It avoids unnecessary details but could be slightly more structured for clarity.

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

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

With 18 parameters and no output schema, the description covers the tool's function and prerequisites but omits details on return values or output format. It is adequate for understanding the main behavior but incomplete for full usage context.

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

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

Schema coverage is 100%, so the schema adequately describes parameters. The description only adds context about the krbtgt key requirement, which is already in the schema. It does not provide additional semantic guidance beyond that.

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 forges a Diamond Ticket (modified legitimate TGT), and distinguishes it from golden tickets by highlighting stealthiness. This helps the agent differentiate from siblings like rubeus_golden.

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

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

The description implies usage as a stealthier alternative to golden tickets and notes the requirement for the krbtgt key. However, it does not explicitly state when not to use or list alternatives beyond golden tickets.

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

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

With no annotations, the description discloses key behaviors: extraction from current or all sessions (with elevation) and output format (base64 kirbi). It does not mention side effects or detailed auth requirements, but is relatively 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?

Three sentences: first states purpose, second explains scope, third describes output format. No wasted words, front-loaded with core action.

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 primary behavior and output, but lacks guidance on parameter combinations (e.g., when to use filters). For a dump tool, it is fairly complete but could benefit from a usage note.

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 each parameter described briefly (e.g., 'Target specific LUID'). The tool description adds no further parameter context beyond the schema, 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 clearly states the tool dumps Kerberos tickets from memory (current or all sessions). It distinguishes from sibling tools like rubeus_klist and rubeus_ptt by focusing on extraction rather than listing or injection.

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

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

The description implies usage for extracting tickets, mentioning elevation for all sessions, but does not explicitly advise when to use alternatives or provide exclusions. Among many sibling tools, some guidance would be helpful.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool creates a TGT granting domain-wide access, bypasses authentication, and enables persistence. However, it does not detail side effects (e.g., whether the ticket is injected into memory without ptt), required privileges, or behavioral effects of optional parameters like ldap or outfile.

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

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

The description is concise (4 sentences) and front-loaded with the main action. It efficiently conveys requirements and consequences without unnecessary detail. It could be slightly improved by ordering the requirements inline rather than a bullet list, but overall it is well-structured.

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

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

Despite 21 parameters and no output schema, the description only covers 3 requirements. It ignores many key parameters (e.g., groups, sids, starttime, ptt) that affect behavior. An agent would lack guidance on how to configure these or interpret results, making the description incomplete for a complex tool.

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

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

Schema coverage is 100% with good parameter descriptions. The description adds context by grouping required parameters and mentioning hash types (RC4, AES), which aids interpretation. However, it does not substantially extend beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool forges a Golden Ticket (a forged TGT) using the krbtgt hash, specifying the verb 'forge' and the resource 'Golden Ticket/TGT'. It distinguishes from siblings like rubeus_asktgt (which requests a TGT) and other Rubeus tools by its unique purpose of creating a persistent, domain-wide access ticket.

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 lists prerequisites (Domain SID, krbtgt hash, target username, domain) but does not explicitly state when to use this tool versus alternatives like rubeus_diamond or rubeus_asktgt. It lacks when-not-to-use guidance and does not mention situational context such as privilege requirements or detection risks.

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 mentions looping and optional auto-renewal, but does not disclose side effects (e.g., whether tickets are removed from the source), authorization needs, or destructive potential, which is insufficient for a monitoring/ticket extraction 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 extremely concise, with three short sentences. Every sentence adds value—first states the action, second elaborates on loop and auto-renewal, third gives use case. No 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?

The tool has 6 parameters and no output schema. The description lacks details on return values or output format, which is critical for an agent to process results. It also does not explain how 'runfor' interacts with the loop or what 'harvested' means in terms of output, leaving significant gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it does not explain how parameters like 'monitorinterval' or 'registry' affect behavior, relying entirely on the already documented 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 monitors and harvests TGTs continuously, with specific verb 'harvest' and resource 'TGTs'. It distinguishes from siblings like rubeus_asktgt or rubeus_dump by focusing on capturing new tickets from other users.

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 usage scenario: 'Useful for capturing tickets from other users logging in.' However, it lacks explicit when-not-to-use guidance or comparison with alternatives, leaving the agent to infer context.

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

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

With no annotations, the description adequately conveys the tool's behavior: it computes hashes and lists output hash types. No destructive or hidden side effects are indicated, and the read-only nature is implied.

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

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

The description is three sentences long, front-loads the core functionality, and contains no unnecessary words. Every sentence is meaningful.

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?

Although no output schema exists, the description lists the hash types returned. It gives context on usage for ticket requests. Missing details like error handling or exact output format, but sufficient for a simple computation tool.

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

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

The input schema has 100% description coverage, so baseline is 3. The description adds value by explaining that user and domain are required for AES salt, which goes beyond schema parameter descriptions.

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

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

The description clearly states it calculates Kerberos password hashes from plaintext and lists specific hash types, which distinguishes it from sibling tools like rubeus_asktgt that use hashes for ticket requests.

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

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

The description mentions that hashes can be used for ticket requests, providing context for when to use this tool. However, it does not explicitly state when not to use it or compare to alternatives, leaving some inference to the agent.

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

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

Without annotations, the description carries the full burden. It explains that the tool requests TGS tickets encrypted with password hashes, mentions OPSEC considerations (AES vs RC4), and notes the output format for hashcat/John. It does not disclose prerequisites like domain credentials or potential alerts, but covers key behavioral aspects.

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

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

The description is concise with three short paragraphs and bullet points for features. It is front-loaded with the primary purpose. While not as lean as one sentence, it efficiently communicates key details without unnecessary verbosity.

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 23 parameters and no output schema, the description covers the overall goal, key features, and output format. It addresses targeting, stealth, filtering, and output compatibility. Minor gaps like exact return structure or credential requirements exist, but completeness is high for a complex offensive security tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema by grouping features (e.g., targeting, stealth, filtering) and explaining the purpose of advanced options like aes, stats, and ldapfilter. This extra value 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 clearly states the tool performs a Kerberoasting attack to extract service account password hashes, using the specific verb 'Perform' and resource. It distinguishes from sibling tools like rubeus_asreproast by focusing on TGS ticket requests for SPN accounts, leaving no ambiguity about its unique 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 implies usage for offline cracking of service account passwords and lists relevant features, providing clear context for when to use the tool. However, it lacks explicit exclusions or alternative tool references, though the sibling list makes the distinction apparent.

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

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

No annotations provided, so the description must carry the full burden. It discloses that the tool modifies a session key but omits any side effects, prerequisites, or error conditions. For a tool modifying a security token, this is insufficient.

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

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

The description is two sentences, front-loaded with purpose, and contains no unnecessary words. It is efficiently concise.

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

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

The tool has 7 parameters and no output schema. The description fails to explain return values, workflow, or error handling, leaving gaps 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?

Schema coverage is 100% with each parameter having a description. The tool description adds no additional meaning beyond what the schema provides, so baseline 3 applies.

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

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

The description clearly states the verb 'modify' and the resource 'kirbi ticket's session key'. It is specific and distinct from sibling tools like rubeus_golden or rubeus_dump.

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

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

The description mentions 'useful for advanced ticket manipulation', which implies usage context but does not provide explicit when-to-use or when-not-to-use guidance, nor 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 bears full burden. It correctly indicates a read-only listing operation, but omits details like required permissions, potential side effects, or output format. For a list tool, the behavior is adequately implied but not fully transparent.

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

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

The description is two sentences, front-loaded with the core action, and contains no unnecessary words. Every sentence adds value: what it does and how it compares to the native command.

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 four optional parameters and no output schema, the description is mostly sufficient but lacks details on output format or further behavioral context. It does not fully cover the complexity of differentiating from many 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?

Schema coverage is 100%, so the description adds no extra parameter meaning beyond the existing field descriptions. The baseline of 3 is appropriate; the description does not enhance or clarify parameter usage further.

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 detailed Kerberos ticket information, and distinguishes it from the native klist by noting more detail and filtering options. While it doesn't specify the exact type of tickets or differentiate from siblings like rubeus_triage, the purpose is specific and actionable.

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

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

The description implies usage for inspecting tickets in more detail than the native klist, but lacks explicit guidance on when to choose this tool over siblings (e.g., for obtaining tickets vs. listing cached tickets). No exclusion or alternative contexts are provided.

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

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

No annotations are present, and the description only states the tool displays information, implying a read-only behavior. It does not disclose any permissions needed, side effects, or output format, leaving significant gaps for an agent.

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

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

The description is very concise, with two sentences that convey the core purpose. It is front-loaded and avoids unnecessary detail, 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?

For a simple tool with no required parameters and a clear purpose, the description is adequate. However, it could benefit from mentioning what information is displayed (e.g., user, domain, logon type) given the tool's security context and lack of output schema.

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

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

Schema description coverage is 100%, so the parameters are well-defined in the schema. The description adds the context of 'current or specified logon session', which aligns with the parameters but does not provide additional semantic depth beyond what the schema already offers.

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 displays information about logon sessions, with options for current or specified sessions. It distinguishes from sibling tools that perform actions like 'ask', 'dump', or 'golden', but does not explicitly differentiate beyond the core action of displaying.

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

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

No guidance is provided on when to use this tool versus alternatives. The sibling tools cover many related Kerberos operations, but no context is given for when 'rubeus_logonsession' 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?

No annotations provided, so description must bear full burden. Says 'just observation' implying read-only, but does not explicitly disclose if it modifies state, requires privileges, or what happens on interval completion. Adequate but not fully explicit.

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?

Efficient two-sentence description that is front-loaded with primary purpose. No wasted words.

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

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

Given no output schema, description explains real-time display behavior. Could mention continuous monitoring until 'runfor' expires, but parameter covers duration. Largely complete for a monitoring tool.

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

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

Schema coverage is 100%, so baseline 3. Description does not add any extra meaning to parameters; the schema already describes each parameter adequately.

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 monitors for new TGT events, distinguishes from harvest by being lightweight and observation-only. Gives specific verb 'monitor' and resource 'new TGTs'.

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

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

Provides clear context that it is for observation without harvesting/renewal, implying use when only monitoring is needed. But does not explicitly state when not to use or list alternatives beyond harvest.

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 fully convey behavior. It mentions importing a ticket and enabling access, but does not disclose side effects like ticket replacement, permission requirements, or error scenarios. It lacks detail 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?

Two concise sentences: the first states the purpose and the second explains the mechanism. No redundancy, front-loaded key 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?

The description covers the core action and input, but lacks details on output (e.g., success/failure indication) and potential errors. Given no output schema, more information would help an agent handle the tool correctly.

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

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

The input schema already provides high-coverage descriptions for both parameters (ticket format, luid elevation). The tool description does not add additional meaning beyond what is in the schema, so baseline score 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 passes a Kerberos ticket to the current session, specifying the action, input format, and result. It distinguishes itself from sibling tools like rubeus_asktgt or rubeus_golden by focusing on applying an existing ticket.

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

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

The description implies usage when you have a Kerberos ticket to use, but does not explicitly state when to avoid this tool or mention alternatives. It is self-explanatory within the context of sibling tools with distinct purposes.

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 cover behavioral traits. It states that removing tickets requires elevation for a specific LUID, which discloses a requirement. However, it does not mention side effects (e.g., loss of authentication) or confirm destructive nature beyond the verb 'Purge'.

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, each carrying essential information: the first states the action and resource, the second elaborates on the two scenarios. No redundant or extraneous 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?

For a simple tool with one optional parameter and no output schema, the description is fairly complete. It covers the core functionality, the two usage modes, and the elevation requirement. It lacks details about success indicators or error conditions, but these are minor given the tool's simplicity.

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

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

The schema covers 100% of parameters with a description for 'luid'. The description adds value by explaining the two modes (current session vs. elevated LUID), which goes beyond the schema's simple wording.

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 the specific verb 'Purge' and resource 'Kerberos tickets', clearly distinguishing it from sibling tools like rubeus_dump or rubeus_ptt. It specifies the scope: from a logon session, either current or specific LUID.

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

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

The description implies use for clearing Kerberos tickets but does not explicitly state when not to use it or mention alternative tools. No guidance on prerequisites or context is provided.

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

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

No annotations are provided, so the description carries full burden. It explains the core behavior (renewal, optional autorenew) but lacks details on prerequisites (e.g., network access to DC), side effects, output format, or error conditions. The mention of 'renewable lifetime' is vague.

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 consists of three short, front-loaded sentences. Every sentence provides value: first states the core action, second adds an optional behavior, third gives usage context. No redundancy or waste.

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

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

The tool has 6 parameters but no output schema. The description does not specify what the tool returns (e.g., renewed ticket, success message). It also fails to explain parameter interactions or constraints (e.g., ticket renewal requires domain controller). This is insufficient for a complex tool.

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

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

Schema coverage is 100%, with all parameters described in the schema. The description adds only the context of 'auto-renew continuously' for the autorenew parameter. Overall, it adds minimal meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool renews an existing TGT, specifying the verb 'renew' and the resource 'existing TGT'. This distinguishes it from sibling tools like rubeus_asktgt (create new TGT) and rubeus_asktgs (service tickets).

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

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

The description mentions it is useful for maintaining persistent access without re-authentication, implying when to use. However, it does not explicitly exclude its use for initial TGT acquisition or provide direct alternatives, only implied context.

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

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

No annotations are provided, so the description carries full burden. It describes functionality and supported features (e.g., Bronze Bit, OPSEC-safe options) but does not disclose side effects like ticket creation in memory/disk or permission requirements beyond delegation rights.

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

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

The description is concise and well-structured with bullet points, front-loading the core purpose and listing key features without extraneous 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?

Given 23 parameters and no output schema, the description lacks information about return values (e.g., ticket output format). It covers high-level functionality but misses details on what the tool actually produces.

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

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

Schema description coverage is 100%, so the schema handles parameter details. The description adds no additional semantic value beyond the high-level functionality; it does not explain parameter relationships or usage specifics.

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 performs S4U constrained/unconstrained delegation abuse, specifying S4U2Self and S4U2Proxy implementations. It distinguishes itself from sibling Rubeus tools by focusing on delegation abuse and privilege escalation.

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

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

The description mentions using this when you control an account with delegation rights, providing some context. However, it does not explicitly exclude alternatives or provide when-not-to-use guidance relative to sibling tools like rubeus_asktgs or rubeus_tgtdeleg.

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 convey behavioral traits. It states the tool creates a ticket without contacting the DC, implying it's a post-exploitation attack. It lists required secrets, indicating the need for prior compromise. However, it does not detail side effects (e.g., overwriting existing tickets) or permissions required.

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

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

The description is concise (4 sentences) and well-structured. It starts with a clear action verb ('Forge'), then lists prerequisites in a bullet-like format, and finally states the benefit. No unnecessary words.

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

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

Given 20 parameters, 3 required, and no output schema, the description covers the core functionality and prerequisites. It mentions output options (outfile) but does not describe the return format (e.g., base64 ticket). For a complex security tool, this is adequate though could be enhanced with output details.

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

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

All 20 parameters have descriptions in the schema, so the baseline is 3. The description adds value by summarizing that the 'service account hash' is required (referencing rc4/aes128/aes256/des) and clarifying the purpose of the service SPN and domain. It does not explain every parameter but provides high-level meaning beyond the schema.

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

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

The description clearly identifies the tool's purpose: to forge a Silver Ticket (a forged Ticket-Granting Service ticket) using a service account hash. It specifies the resource (service ticket) and the action (forge/create), distinguishing it from siblings like golden tickets (domain-wide) or asktgs (legitimate request).

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 lists the required inputs (service account hash, service SPN, domain information) and explains the benefit (grants access without touching the DC). It does not explicitly mention when not to use it or compare with alternatives, but the context and prerequisites provide sufficient guidance for an experienced agent.

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

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

No annotations are provided, so the description carries the full burden. It explains that the SPN is replaced and requires the same service account, but it does not disclose whether the original ticket is modified or a new one is created, nor does it describe output format, error conditions, or side effects like pass-the-ticket 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 concise, with a clear one-line summary followed by a brief elaboration. It uses two paragraphs effectively without redundancy or unnecessary words.

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

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

The description covers the main purpose and a key use case, but it lacks details about output (no output schema) and the implications of parameters like ptt, luid, and nowrap. Given the tool's complexity and zero annotations, the description should provide more context about behavior and return values.

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

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

Schema coverage is 100% with descriptions for all six parameters. The description adds minimal extra meaning beyond the schema, merely reiterating the concept of service name substitution. Since schema already documents parameters, 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 states 'Substitute the service name in a service ticket' and explains it replaces the SPN in an existing TGS with a new service name. It clearly distinguishes itself from other Rubeus tools (e.g., asktgs, s4u) by focusing on ticket modification rather than acquisition or delegation.

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

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

The description clearly indicates when to use the tool: when you have a ticket for one service but need access to another on the same server, requiring the same service account. It does not explicitly list when not to use or name alternatives, but the context makes the intended scenario evident.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool uses Kerberos GSS-API, abuses delegation, and works with standard permissions. However, it does not detail potential side effects or network requests, though as a read-only extraction tool, the transparency 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 concise with four sentences, front-loaded with the main purpose, followed by key technical details and use cases. No unnecessary words; every sentence adds value.

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

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

Given the tool's complexity and lack of output schema, the description is largely complete: it explains what the tool does, its advantage (no elevation), and the resulting artifact (TGT for pass-the-ticket). However, it could mention how to inject or use the extracted TGT, but overall it's sufficient for advanced users.

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 both parameters described in the input schema. The description adds no new meaning beyond restating that 'target' is the target SPN for delegation and 'nowrap' controls base64 wrapping. Thus, parameter semantics score is baseline 3.

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 'extracts a usable TGT for the current user without elevation,' providing a specific verb and resource. It references the 'tgt::deleg' technique from Kekeo, distinguishing it from other Rubeus tools like asktgt or asktgs.

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

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

The description mentions no elevation is required and that the TGT can be used for pass-the-ticket, but it lacks explicit guidance on when to use this tool versus alternatives like asktgt or s4u. The context is implied rather than explicitly stated.

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

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

With no annotations, the description carries full burden. It states 'without full extraction', indicating a non-destructive, lightweight operation. However, it does not disclose other behavioral traits such as whether it modifies state, permissions required, 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 two sentences, front-loaded with the primary action, and provides additional context in the second sentence. Every word earns its place with no fluff 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 is simple (4 optional params, no required, no output schema, read-only), the description covers the main action adequately. It could mention return format or behavior with no results, but overall it is fairly complete for a triage tool.

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

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

Schema coverage is 100%, and each parameter has a basic description in the schema. The tool description adds no additional meaning beyond what is already in the schema, 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 clearly states it displays a quick summary of tickets in sessions, using specific verbs (display/show) and resource (tickets). It distinguishes from siblings like rubeus_dump by noting 'without full extraction', making the purpose unambiguous.

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

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

The description mentions 'useful for reconnaissance', which implies usage context, but it does not explicitly state when to use this tool versus siblings like rubeus_klist or rubeus_dump, nor does it provide when-not-to-use guidance.

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