rubeus_golden

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.