BloodHound MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
The tools are highly specialized with distinct purposes, such as get_computer_admin_rights vs get_computer_admin_users, which target different aspects of computer administration. However, some tools like get_computer_rdp_rights and get_computer_rdp_users have overlapping domains that could cause minor confusion, but descriptions clarify the differences. Overall, the set is well-differentiated with minimal ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as get_computer_info, list_saved_queries, and run_cypher_query. There are no deviations in naming conventions, making the set predictable and easy to navigate. This uniformity enhances usability and reduces cognitive load for agents.
Tool Count2/5
With 79 tools, the count is excessive for a single server, likely overwhelming for agents and increasing the risk of misselection. While the domain of BloodHound (Active Directory security analysis) is complex, this many tools suggests poor scoping or fragmentation, as many functions could be consolidated into more generic queries or parameters. It far exceeds the typical well-scoped range of 3-15 tools.
Completeness5/5
The tool set provides comprehensive coverage for BloodHound's domain, including CRUD operations for saved queries, detailed queries for various Active Directory objects (users, computers, groups, GPOs, OUs, domains, certificates), and advanced analysis tools like get_shortest_path and get_edge_composition. There are no obvious gaps; agents can perform reconnaissance, attack path analysis, and security assessments effectively.
Average 3.6/5 across 79 of 79 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'retrieves' information, implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or whether it returns all user attributes or a subset. The reconnaissance context hints at security implications but lacks specifics on permissions or data sensitivity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with three sentences, but the structure could be improved. The first sentence clearly states the purpose, but the second is somewhat redundant ('general overview' repeats 'information'), and the third adds reconnaissance context without clear integration. The 'Args' section is helpful but not fully integrated into the flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter, no annotations, no output schema), the description is incomplete. It covers the basic purpose and parameter but lacks details on behavioral traits (e.g., permissions, errors), output format, or how it differs from sibling tools. For a tool in a security/reconnaissance context with many related tools, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage. The description includes an 'Args' section that documents 'user_id: The ID of the user to query,' adding semantic meaning beyond the schema's title ('User Id'). However, it doesn't specify the ID format (e.g., username, email, UUID) or provide examples, leaving gaps. With low schema coverage, this partial compensation earns a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves information about a specific user in a specific domain' with 'general overview of a user's information including their name, domain, and other attributes.' This specifies the verb (retrieves), resource (user information), and scope (domain). However, it doesn't explicitly differentiate from sibling tools like 'get_users' (which likely lists multiple users) or 'get_user_info' variants (e.g., 'get_user_admin_rights'), leaving room for improvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: 'It can be used to conduct reconnaissance and start formulating and targeting users within the domain.' This implies a reconnaissance context but doesn't specify when to use this tool versus alternatives like 'get_users' for listing users or other user-specific tools (e.g., 'get_user_admin_rights'). No explicit when/when-not rules 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.
Behavior2/5
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. While it indicates this is a read operation ('retrieves information'), it doesn't disclose important behavioral aspects: whether authentication is required, rate limits, what happens if the GPO doesn't exist, whether this queries live data or cached information, or what format the information returns. The reconnaissance mention hints at security context but doesn't specify permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with three sentences plus an Args section. The first sentence clearly states the purpose, the second elaborates on what information is returned, and the third provides usage context. The Args section is appropriately separated. While efficient, the third sentence about 'conducting reconnaissance' could be more precise about the tool's specific role versus general reconnaissance activities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what 'general overview' includes beyond 'name, domain, and other attributes' (what other attributes?), doesn't describe the return format, doesn't mention error conditions, and doesn't provide enough context about the security/permission requirements implied by the reconnaissance mention. The agent would struggle to use this effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% (no parameter descriptions in schema), so the description must compensate. It provides an 'Args:' section explaining 'gpo_id: The ID of the GPO to query' which adds meaningful context beyond the bare schema. However, it doesn't explain what format the GPO ID should be (GUID, name, etc.), where to find GPO IDs, or provide examples. For a single parameter with 0% schema coverage, this is minimally adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves information about a specific GPO in a specific domain.' It specifies the verb ('retrieves'), resource ('GPO'), and scope ('specific domain'). However, it doesn't explicitly differentiate from sibling tools like 'get_gpos' (which likely lists multiple GPOs) or 'get_gpo_info' vs 'get_gpo_controllers' vs 'get_gpo_users' - the description mentions 'general overview' but doesn't clarify what distinguishes this from those other GPO-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It states 'It can be used to conduct reconnaissance and start formulating and targeting GPOs within the domain' which gives some context about when this tool might be useful, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_gpos' (for listing GPOs) or 'get_gpo_controllers'/'get_gpo_users' (for specific relationship queries). No when-not-to-use guidance or clear alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what the tool does (retrieves active sessions) and mentions potential security implications, but lacks critical behavioral details: whether this is a read-only operation, what permissions are required, how sessions are defined/identified, rate limits, error conditions, or what the output format looks like. The security context hints at sensitive data but doesn't explicitly state access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with a purpose statement followed by parameter documentation. However, the middle sentences about 'potential targets for lateral movement' and 'attack paths' are somewhat redundant with the core purpose and could be condensed. The information is front-loaded appropriately, but there's some verbosity in the security context that doesn't directly aid tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is incomplete. While it covers parameters well, it lacks critical information about behavioral characteristics (permissions, safety, rate limits), output format, error handling, and differentiation from sibling tools. The security context adds some value but doesn't compensate for these fundamental gaps in a domain where such tools likely have significant access implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents all three parameters with clear explanations beyond what the schema provides (schema description coverage is 0%). It explains that user_id identifies 'the user to query,' limit controls 'maximum number of sessions to return' with a default, and skip enables 'pagination.' This adds meaningful context that the bare schema lacks, though it doesn't specify format constraints or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves the active sessions of a specific user within the domain.' It specifies the verb (retrieves) and resource (active sessions) with a clear scope (specific user within domain). However, it doesn't explicitly differentiate from sibling tools like 'get_computer_sessions' or 'get_group_sessions,' which reduces it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions potential use cases (identifying targets for lateral movement, planning attack paths), these are application contexts rather than tool selection guidelines. There's no mention of prerequisites, when not to use it, or how it differs from similar sibling tools in the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a list operation (implying read-only) and mentions a JSON response, but lacks critical behavioral details: whether it requires specific permissions, how pagination works beyond parameters, error conditions, or if it's safe for frequent use. The description adds minimal context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and front-loaded the main purpose. It's appropriately sized with no redundant sentences, though the 'Returns' line could be more informative given no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is moderately complete. It covers parameters and return type, but lacks behavioral context (e.g., permissions, errors) and detailed output explanation, which is needed for a tool with no structured support. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining all three parameters (skip, limit, name) in the 'Args' section, adding meaning like 'for pagination' and 'Filter by query name'. However, it doesn't provide format details (e.g., case-sensitivity for name) or default values, which are in the schema but not described. Baseline is 3 as it adds value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('saved Cypher queries'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'search_objects' or 'run_cypher_query' that might also involve queries, though 'list_saved_queries' appears unique among the provided siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., authentication), context (e.g., after creating queries), or comparisons with sibling tools like 'search_graph' or 'interpret_cypher_result' that might overlap in query-related functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Create' implies a write operation but doesn't disclose behavioral traits like required permissions, whether duplicates are allowed, error handling for invalid queries, or if the query is validated before saving. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and uses minimal sentences. Every part adds value: the first sentence states the purpose, and the subsequent lines document parameters and returns efficiently. It could be slightly more front-loaded by integrating parameter hints into the main sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, and no output schema, the description is moderately complete. It covers the basic purpose and parameters but lacks details on behavioral aspects (e.g., permissions, validation) and output specifics beyond 'JSON response', which is insufficient for a creation tool without structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'name' is for the saved query and 'query' is the Cypher query to save, clarifying their purposes. However, it doesn't provide format details (e.g., query syntax, name constraints), keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new saved Cypher query') and specifies the resource ('saved Cypher query'), which is distinct from sibling tools like 'list_saved_queries' or 'run_cypher_query'. However, it doesn't explicitly differentiate from potential alternatives like modifying existing queries, though no such sibling exists in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing queries to save), compare to 'list_saved_queries' for viewing saved queries, or specify use cases like storing frequently used queries for reuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves information (implying read-only) and mentions reconnaissance use, but doesn't disclose behavioral traits like permissions required, rate limits, error conditions, or what 'other attributes' includes. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences and an Args section, front-loading the core purpose. The reconnaissance sentence adds context but could be more integrated. There's minimal waste, though the structure could be tighter by merging the second and third sentences for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers the basic purpose and parameter but lacks details on return values (e.g., what attributes are included), error handling, or prerequisites. For a tool in a complex domain with many siblings, this leaves the agent under-informed about how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description includes an 'Args' section that documents the single parameter 'computer_id' as 'The ID of the computer to query', adding basic semantics. However, it doesn't explain the format of the ID (e.g., GUID, hostname) or provide examples, which limits its utility. With 1 parameter, the baseline is 4, but the minimal explanation reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves information about a specific computer in a domain, providing a general overview including name, domain, and other attributes. It distinguishes from siblings like 'get_computers' (plural) by focusing on a single computer, though it doesn't explicitly name alternatives. The purpose is specific but could be more precise about what 'other attributes' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reconnaissance and targeting within a domain, suggesting it's for initial information gathering. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_computer_info' vs 'get_computer_admin_rights' or other sibling tools. The guidance is contextual but lacks explicit comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'retrieves' implies a read-only operation, the description doesn't mention authentication requirements, rate limits, pagination behavior beyond the 'skip' parameter, error conditions, or what format the returned computers data takes. For a database query tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The parameter explanations are clear and efficient, though the formatting with 'Args:' and bullet-like indentation is slightly inconsistent. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no output schema, the description does a decent job explaining parameters but lacks critical context. It doesn't describe the return format (what 'computers' data looks like), error handling, or how this tool fits within the Bloodhound query ecosystem. For a database retrieval tool with many similar siblings, more contextual guidance would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for all three parameters that isn't in the schema (which has 0% description coverage). It explains that 'domain_id' identifies 'the domain to query', 'limit' sets the 'maximum number of computers to return' with a default, and 'skip' is for 'pagination' with a default. This compensates well for the schema's lack of descriptions, though it doesn't elaborate on domain_id format or pagination mechanics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves computers from a specific domain in the Bloodhound database.' This specifies the verb ('retrieves'), resource ('computers'), and scope ('from a specific domain in the Bloodhound database'). However, it doesn't explicitly differentiate from sibling tools like 'get_computer_info' or 'search_objects', which reduces clarity in a crowded namespace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., 'get_computer_info', 'search_objects', 'get_ou_computers'), there's no indication of when this specific retrieval tool is appropriate, what prerequisites exist, or what distinguishes it from other query methods in the Bloodhound context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data (implying read-only) and mentions pagination via 'skip' and 'limit', which is useful. However, it lacks details on permissions required, rate limits, error conditions, or the return format (e.g., list structure, fields included). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with the core purpose in the first sentence and additional context in the second. The parameter explanations are concise and directly relevant. There's minimal waste, though the second sentence could be considered slightly extraneous for pure tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no output schema, the description does a fair job: it covers parameter meanings and implies read-only behavior. However, it lacks details on the return format, error handling, and security implications (e.g., domain context), which are important for a tool in this domain. It's adequate but has clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all three parameters: 'gpo_id' specifies the target GPO, 'limit' defines the maximum return count with a default, and 'skip' explains pagination with a default. This adds meaningful context beyond the bare schema, though it doesn't detail format constraints (e.g., GPO ID structure).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieves') and resource ('computers within a specific GPO'), making the purpose evident. It distinguishes from siblings like 'get_computers' (general) and 'get_ou_computers' (OU-based), but doesn't explicitly contrast them. The second sentence about 'identify potential targets' adds context but isn't essential to the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. While the description implies it's for GPO-specific computer retrieval, it doesn't mention when to choose it over 'get_computers' or 'get_ou_computers', nor does it discuss prerequisites or exclusions. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'retrieves information' and 'provides a general overview,' which implies a read-only operation, but doesn't clarify permissions needed, rate limits, pagination, error conditions, or what 'other attributes' might include. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by additional details and the parameter explanation. The 'Args:' section is well-structured. However, the reconnaissance/targeting sentence is somewhat vague and could be more precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) but lack of annotations and output schema, the description is minimally adequate. It covers the purpose and parameter semantics but lacks behavioral details like error handling or output format. For a read-only query tool, this is borderline but meets basic needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args:' section that documents the single parameter 'group_id' with a brief explanation: 'The ID of the group to query.' With schema description coverage at 0% (the schema has no descriptions), this adds meaningful context beyond the bare schema. However, it doesn't specify the format or source of the group_id, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves information about a specific group in a specific domain' and 'provides a general overview of a group's information including their name, domain, and other attributes.' This specifies the verb (retrieves), resource (group information), and scope (specific group in specific domain). However, it doesn't explicitly differentiate from sibling tools like 'get_groups' (which likely lists multiple groups) or 'get_group_members' (which focuses on members).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions 'It can be used to conduct reconnaissance and start formulating and targeting groups within the domain,' which implies a security/analysis context but doesn't specify when to use this tool versus alternatives like 'get_groups' or 'get_group_members.' No explicit when/when-not scenarios or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieval but doesn't specify whether this is a read-only operation, if it requires authentication, what happens on errors, or any rate limits. The description is minimal and lacks critical behavioral context for a tool interacting with a database.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value: the first defines the tool's function, and the subsequent lines document each parameter concisely. There's no wasted text, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of database retrieval, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'groups' means in this context, the return format, error conditions, or authentication requirements. For a tool with three parameters and no structured safety hints, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear explanations for all three parameters: 'domain_id' specifies the domain to query, 'limit' defines the maximum return count with a default, and 'skip' explains pagination with a default. This adds meaningful context beyond the bare schema, though it doesn't cover format details like domain_id structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieves') and resource ('groups from a specific domain in the Bloodhound database'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_foreign_groups' or 'get_group_info', but the domain-specific focus is implied. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'get_foreign_groups', 'get_group_info', and 'get_group_members', there's no indication of when this specific retrieval is appropriate or what distinguishes it from other group-related queries. Usage is implied only by the tool name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves computers, implying a read-only operation, but doesn't clarify if it requires specific permissions, has rate limits, returns partial data, or handles errors. The mention of 'lateral movement and privilege escalation' adds some context but is insufficient for a mutation-sensitive environment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured. It starts with the core purpose, adds usage context, and lists parameters with clear explanations. Each sentence earns its place, and there's no unnecessary verbosity. A perfect score is reserved for exceptional cases with even tighter phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and parameters adequately but lacks details on behavioral aspects like permissions, error handling, or return format. Without an output schema, the description should ideally hint at what's returned (e.g., a list of computer objects), but it doesn't, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains each parameter: 'ou_id' as 'The ID of the OU to query,' 'limit' as 'Maximum number of computers to return (default: 100),' and 'skip' as 'Number of computers to skip for pagination (default: 0).' This compensates well for the schema's lack of descriptions, though it doesn't detail format constraints (e.g., OU ID syntax).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves the computers within a specific OU in the domain.' It specifies the verb ('retrieves') and resource ('computers within a specific OU'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_computers' or 'get_computer_info', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions 'This can be used to identify potential targets for lateral movement and privilege escalation,' which hints at a security/penetration testing context but doesn't specify when to use this tool versus alternatives like 'get_computers' or 'get_ou_info.' No explicit when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that OUs are 'key in understanding the structure of the domain,' which hints at a read-only, informational purpose, but does not explicitly state whether this is a safe read operation, if it requires specific permissions, or details about rate limits, pagination behavior, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose, followed by explanatory context about OUs, and ending with parameter details. The structure is logical, though the 'Args' section is cut off ('default' incomplete for 'skip'), slightly affecting clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the purpose and parameters well, but lacks usage guidelines, behavioral details (e.g., pagination, errors), and output information, making it minimally viable for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents all three parameters, adding meaning beyond the input schema (which has 0% description coverage). It explains 'domain_id' as 'The ID of the domain to query,' 'limit' with its default and purpose, and 'skip' for pagination, effectively compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves Organizational Units (OUs) from a specific domain in the Bloodhound database.' It specifies the verb ('Retrieves'), resource ('Organizational Units'), and context ('Bloodhound database'), but does not explicitly differentiate from sibling tools like 'get_ou_info' or 'get_ou_computers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description explains what OUs are and their importance, but offers no context on prerequisites, when this tool is appropriate, or when other sibling tools (e.g., 'get_ou_info' for detailed OU data) should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions that 'Controlling a Root CA allows an attacker to issue trusted certificates' (security context), it doesn't describe the tool's operational behavior - whether it's read-only, what permissions are required, what format the information returns, or any rate limits. The description focuses on conceptual importance rather than practical tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose statement, context about Root CAs, and parameter documentation. The structure is front-loaded with the core functionality first. The security warning sentence adds value but could be more tightly integrated with usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and operates in a security/PKI context, the description provides basic completeness but lacks important details. It explains what the tool does and documents the single parameter, but doesn't address return format, error conditions, authentication requirements, or how it differs from similar sibling tools in the extensive list provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the single parameter 'ca_id' with clear semantics ('The ID of the Root CA to query'), which is valuable since the schema has 0% description coverage. For a tool with only one parameter, this provides adequate parameter understanding, though it doesn't explain what format the ID should be in or where to obtain valid IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieves information') and resource ('Root Certificate Authority'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_enterprise_ca_info' or 'get_cert_template_info', which appear to be related information retrieval tools in the same domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools that appear to retrieve similar security/PKI information (e.g., 'get_enterprise_ca_info', 'get_cert_template_info'), but the description doesn't explain when this specific Root CA tool should be chosen over those alternatives or what distinguishes it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'retrieves' data, implying a read-only operation, and mentions potential abuse contexts, but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or response format. For a tool with no annotation coverage, this is a significant gap in transparency about how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first, followed by explanatory context and parameter details. Each sentence adds value: the first defines the tool, the second explains RDP rights, the third provides security context, and the Args section clarifies parameters. There's no redundant or wasted text, though the security note could be more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and parameters well, but lacks details on behavioral traits (e.g., permissions, errors) and output format. Without annotations or an output schema, the agent is left guessing about the return structure and operational constraints, making this adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains that 'user_id' is 'The ID of the user to query,' and provides default values and purposes for 'limit' and 'skip' (e.g., 'Maximum number of RDP rights to return' and 'for pagination'). This compensates well for the schema's lack of descriptions, though it doesn't detail data types or constraints like valid ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves the RDP rights of a specific user within the domain.' It specifies the verb ('retrieves'), resource ('RDP rights'), and scope ('specific user within the domain'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_computer_rdp_rights' or 'get_group_rdp_rights', which target different entities, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions that 'RDP rights can be abused for lateral movement and privilege escalation,' which hints at a security or penetration testing context, but doesn't specify prerequisites, exclusions, or direct comparisons to sibling tools like 'get_user_ps_remote_rights' or 'get_user_dcom_rights' for similar access rights. This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains what DCOM rights are and their security implications (abuse for privilege escalation), which adds valuable behavioral context beyond just the operation. However, it doesn't disclose pagination behavior (implied by limit/skip parameters), error conditions, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste - first states the operation, second explains DCOM rights, third provides security context. Well-structured and appropriately sized for the complexity, though the first sentence has a minor grammatical error ('the a list').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 3 parameters, 0% schema coverage, and no output schema, the description provides good conceptual context about DCOM rights and security implications. However, it lacks details about the return format, pagination behavior, and doesn't fully compensate for the undocumented parameters, making it incomplete for optimal agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description doesn't mention any parameters explicitly, but implies a computer identifier is needed ('specific computer'). It doesn't explain the purpose of limit/skip parameters for pagination, leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of security principals for a specific computer's DCOM rights, with a specific verb ('retrieves') and resource ('security principals'). It distinguishes from siblings like get_computer_dcom_users by focusing on rights rather than users, but could be more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_computer_dcom_users or other rights-related tools. The description mentions DCOM rights can be abused for privilege escalation, which provides some context but doesn't specify when this tool is the appropriate choice among similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves users but does not specify if this is a read-only operation, potential rate limits, authentication requirements, or what happens on errors. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a brief purpose statement followed by a clear, bullet-point-like list of parameters and their meanings. Every sentence earns its place, and it is front-loaded with the core functionality, making it easy to parse without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description covers the purpose and parameters well but lacks behavioral details like error handling or return format. It is adequate as a minimum viable description but has clear gaps in usage guidelines and transparency, especially for a database query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for all three parameters: 'domain_id' specifies the domain to query, and 'limit' and 'skip' explain their roles in pagination with defaults. Since schema description coverage is 0%, the description fully compensates by providing clear semantics beyond the bare schema, making it highly valuable for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('users from a specific domain in the Bloodhound database'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_user_info' or 'get_foreign_users', which might retrieve similar data but with different scopes or filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_user_info' for detailed user data or 'search_objects' for broader searches. It lacks context about prerequisites, exclusions, or typical use cases, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the tool 'retrieves information' (implying a read-only operation), it doesn't clarify whether this requires specific permissions, what information is returned (e.g., CA properties, certificates issued), or any rate limits or constraints. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized: it starts with the core purpose, provides context about Enterprise CAs, and ends with parameter details. Each sentence adds value, though the context about Certificate Templates and Active Directory PKI, while helpful, could be slightly trimmed for brevity without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (querying a specific CA in an enterprise environment), no annotations, no output schema, and low schema description coverage, the description is moderately complete. It covers the purpose, context, and parameter semantics adequately, but lacks details on return values, error conditions, or behavioral traits, which are important for a tool in this domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents the single parameter 'ca_id' with a brief explanation ('The ID of the Enterprise CA to query'). With schema description coverage at 0%, this adds essential meaning beyond the schema's minimal title ('Ca Id'). However, it doesn't specify the format or source of the ID (e.g., GUID, name), leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves information about a specific Enterprise Certificate Authority.' It specifies the verb ('retrieves') and resource ('Enterprise Certificate Authority'), and distinguishes it from sibling tools like 'get_root_ca_info' by focusing on Enterprise CAs. However, it doesn't explicitly differentiate from other CA-related tools like 'get_enterprise_ca_controllers' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context by explaining what Enterprise CAs are ('issue certificates within the organization based on Certificate Templates') and their role ('critical components in the Active Directory PKI infrastructure'), which helps identify when this tool is relevant. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_root_ca_info' or other CA-related siblings, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates a read operation ('retrieves'), but lacks details about permissions required, rate limits, pagination behavior beyond basic skip/limit parameters, error conditions, or what the return format looks like. The security context hint ('identify potential targets') adds some value but doesn't cover operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose statement, use case context, and parameter documentation. The parameter section is clearly formatted. While efficient, the use case sentence could be considered slightly extraneous for pure tool selection, though it provides valuable context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter read tool with no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and parameters but lacks information about return format, error handling, authentication requirements, and performance characteristics. The security context helps but doesn't compensate for these operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting all three parameters with clear semantics: gpo_id identifies the target, limit controls result size with default, and skip enables pagination. The description provides meaning beyond what the bare schema offers, though it doesn't specify format requirements for gpo_id or constraints on limit/skip values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves') and resource ('users within a specific GPO'), making the purpose unambiguous. It distinguishes from siblings like 'get_gpo_computers' or 'get_gpo_info' by focusing specifically on users. However, it doesn't explicitly differentiate from other user-related tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions a use case ('identify potential targets for lateral movement and privilege escalation'), this is contextual rather than operational guidance. There's no mention of prerequisites, when to choose this over other user retrieval tools, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves members but doesn't cover critical aspects like whether it's a read-only operation, potential rate limits, authentication requirements, error handling, or the format of returned data. The mention of 'lateral movement and privilege escalation' adds some security context, but overall behavioral traits are inadequately described for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, adds context about memberships, and then lists parameters with explanations. Each sentence serves a purpose, though the security context sentence ('These memberships can be used...') could be considered slightly extraneous if not critical for tool selection. Overall, it's efficient and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and parameters well but lacks details on behavioral aspects like return format, pagination behavior, or error conditions. Without an output schema, the description should ideally hint at what's returned (e.g., list of users/groups), but it doesn't, leaving gaps in contextual understanding for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explicitly documents all three parameters ('group_id', 'limit', 'skip') with clear semantics, including defaults and purposes (e.g., 'skip' for pagination). This compensates fully for the schema's lack of descriptions, making parameter usage understandable without relying on the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves the members of a specific group within the domain.' It specifies the verb ('retrieves') and resource ('members of a specific group'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_group_info' or 'get_group_memberships', which might have overlapping or related functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions that memberships can be used for 'lateral movement and privilege escalation,' which hints at a security context, but doesn't specify prerequisites, constraints, or when to choose other tools like 'get_group_info' or 'get_users' for related queries. This lack of explicit usage context limits its effectiveness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool retrieves data, implying read-only behavior, but doesn't disclose critical details like authentication requirements, rate limits, error handling, or the format of returned data. The security context hint is useful but insufficient for full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by parameter details. Every sentence adds value, such as explaining the security relevance and parameter defaults. It could be slightly more concise by integrating the security hint into the main purpose, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the purpose and parameters well, but lacks details on return values, error cases, or behavioral constraints like pagination limits. This makes it minimally viable but not fully comprehensive for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all three parameters: 'group_id' is explained as 'The ID of the group to query,' and 'limit' and 'skip' are described with their purposes and defaults. This goes beyond the schema's basic titles, providing clear usage context for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves the group memberships of a specific group within the domain.' It specifies the verb ('retrieves') and resource ('group memberships'), making it understandable. However, it doesn't explicitly differentiate from siblings like 'get_group_members' or 'get_user_memberships', which is why it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'potential targets for lateral movement and privilege escalation,' suggesting it's for security analysis. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_group_members' or other sibling tools, and doesn't specify prerequisites or exclusions, leaving usage somewhat ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves GPOs, implying a read-only operation, but doesn't clarify permissions required, rate limits, pagination behavior beyond the 'skip' parameter, or what the output format looks like. The security context hint is useful but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. The first sentence states the purpose clearly, the second adds context, and the parameter explanations are concise and front-loaded. There's minimal waste, though the security context sentence could be more integrated with usage guidelines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is adequate but has gaps. It covers parameters well and states the purpose, but lacks details on behavioral aspects like permissions, error handling, or output structure. For a tool in a security context with sibling alternatives, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It clearly explains each parameter: 'ou_id' as the OU to query, 'limit' as the maximum number of GPOs to return with a default, and 'skip' for pagination with a default. This fully compensates for the schema's lack of descriptions, making parameter usage clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('GPOs within a specific OU in the domain'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_gpos' or 'get_gpo_ous', which likely retrieve GPOs at different scopes, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions a potential use case ('identify potential targets for lateral movement and privilege escalation'), but this is context-specific rather than operational guidance. There's no mention of prerequisites, when not to use it, or how it compares to sibling tools like 'get_gpos' or 'get_gpo_ous'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves information (implying read-only) and lists example attributes (name, domain, other attributes), but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what 'other attributes' specifically includes. The reconnaissance mention adds some context but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences plus an Args section. The first sentence states the purpose, the second elaborates on information retrieved, and the third provides usage context. The structure is front-loaded with the core function, though the reconnaissance sentence could be more precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and no output schema, the description adequately covers the parameter semantics and general purpose. However, as a read operation with no annotations, it lacks details on return format (e.g., structure of 'other attributes'), error handling, or dependencies, leaving gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains 'ou_id' as 'The ID of the OU to query', adding meaning beyond the schema (which has 0% description coverage and only provides a title 'Ou Id'). This compensates well for the low schema coverage, though it doesn't specify the ID format or source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves information about a specific OU in a specific domain, specifying the verb (retrieves) and resource (OU information). It distinguishes from sibling tools like 'get_ous' (which likely lists OUs) by focusing on a single OU. However, it doesn't explicitly contrast with other OU-related tools like 'get_ou_computers' or 'get_ou_users'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('to conduct reconnaissance and start formulating and targeting OUs'), suggesting this is for initial information gathering. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'get_ous' for listing OUs or 'get_ou_info' for details), nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a retrieval operation, implying read-only behavior, and hints at security context, but doesn't disclose critical behavioral traits like whether it requires authentication, rate limits, error conditions, pagination details beyond skip/limit, or what the return format looks like. For a database query tool with no annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, definition, and security context, followed by a structured Args section. It's front-loaded with the core functionality. The Args section is clear but could be integrated more seamlessly; overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters, the description is moderately complete. It covers purpose, parameter semantics, and basic context, but lacks details on return values, error handling, authentication, or performance considerations. For a database query tool in a security context, this leaves gaps that could hinder effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all three parameters: domain_id ('ID of the domain to query'), limit ('Maximum number of outbound trusts to return'), and skip ('Number of outbound trusts to skip for pagination'), including default values. This adds significant value beyond the bare schema, though it doesn't explain domain_id format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and resource 'outbound trusts from a specific domain in the Bloodhound database', making the purpose evident. It distinguishes outbound trusts from inbound by defining them as 'trust relationships where the domain trusts other domains', which helps differentiate from sibling tool 'get_inbound_trusts'. However, it doesn't explicitly contrast with that sibling, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining what outbound trusts are ('potential targets for accessing resources within another domain') and their security implications, which suggests when this tool might be relevant. However, it lacks explicit guidance on when to use this versus alternatives like 'get_inbound_trusts' or other trust-related tools, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool retrieves information (implying read-only), which is helpful, and adds security context about potential abuse. However, it doesn't disclose behavioral traits like rate limits, authentication needs, response format, or error handling. The security warning adds some value but leaves operational details unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by explanatory context and parameter details. Every sentence earns its place—no fluff or redundancy. The structure is clear with a dedicated Args section, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is partially complete. It covers the purpose and parameter semantics adequately but lacks usage guidelines, detailed behavioral context, and output information. The security note adds value, but overall, it's minimal for a tool in a security-focused context with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter: 'The ID of the Certificate Template to query.' This clarifies what template_id represents beyond the schema's basic title ('Template Id'). Since schema description coverage is 0% and there's only one parameter, the description effectively compensates by providing semantic understanding, though it doesn't specify format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves information about a specific Certificate Template.' It specifies the verb ('retrieves') and resource ('Certificate Template'), and distinguishes it from siblings by focusing on template information rather than controllers or other entities. However, it doesn't explicitly differentiate from all possible similar tools beyond the general context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions Certificate Templates can be abused for privilege escalation, which hints at security context, but doesn't specify when to choose this over other certificate-related tools like get_cert_template_controllers or when not to use it. No alternatives 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool retrieves data (implying read-only) and explains what foreign groups represent, but lacks critical behavioral details: whether it requires specific permissions, rate limits, pagination behavior beyond skip/limit defaults, or what the return format looks like. The security context about lateral movement is helpful but doesn't cover operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose statement, definition, security context, and parameter details in separate sections. Every sentence adds value, though the security context sentence could be more integrated. Slightly verbose but efficiently communicates necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter read tool with no annotations and no output schema, the description does adequately cover purpose and parameters. However, it lacks details on return format, error conditions, or examples, leaving gaps in operational understanding. The security context adds value but doesn't fully compensate for missing behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides clear parameter documentation in the Args section, explaining domain_id, limit, and skip with their purposes and defaults. This fully compensates for the lack of schema descriptions, though it doesn't elaborate on domain_id format or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and resource 'foreign groups from a specific domain in the Bloodhound database', with a detailed definition of what foreign groups are. It distinguishes from siblings by focusing on cross-domain group memberships, unlike other tools targeting computers, users, GPOs, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there's no mention of prerequisites, when-not-to-use scenarios, or comparisons to similar tools like get_groups or get_foreign_users. The description assumes the user knows when foreign group analysis is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that administrative rights 'can be abused' but doesn't clarify if this is a read-only operation, what permissions are required, whether it's rate-limited, or what the response format looks like. The description adds some security context but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter documentation. Each sentence earns its place, though the security context about abuse could be more integrated. The front-loaded purpose statement is effective, and the Args section is organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description provides adequate parameter semantics but lacks behavioral context. It covers what the tool does and what parameters mean, but doesn't explain what the output looks like, error conditions, or operational constraints, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides clear explanations for all three parameters: 'group_id' identifies the target group, 'limit' controls maximum results with default, and 'skip' enables pagination with default. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves') and resource ('administrative rights of a specific group'), making the purpose explicit. It distinguishes from sibling tools like 'get_group_info' or 'get_group_members' by focusing specifically on administrative rights rather than general group information or membership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions that administrative rights can be abused for lateral movement, persistence, and privilege escalation, it doesn't specify use cases, prerequisites, or comparisons to similar tools like 'get_user_admin_rights' or 'get_computer_admin_rights'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a 'Human-readable interpretation' but doesn't specify behavioral traits such as whether it modifies data, requires specific permissions, handles errors, or has performance considerations. For a tool with no annotations, this leaves significant gaps in understanding its operation and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose statement, followed by concise parameter and return value explanations. Every sentence earns its place by providing essential information without redundancy, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interpreting query results for security analysis), no annotations, no output schema, and 2 parameters, the description is adequate but incomplete. It covers the purpose and parameters but lacks details on output format, error handling, or integration with sibling tools. This is the minimum viable for basic understanding but misses advanced contextual needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for both parameters: 'query' is described as 'The original Cypher query that was executed,' and 'result_json' as 'The JSON result from run_cypher_query.' This clarifies their roles and relationships beyond the schema, which has 0% description coverage. Since there are only 2 parameters and the description compensates well, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Help interpret the results of a Cypher query for offensive security analysis.' It specifies the verb ('interpret'), resource ('results of a Cypher query'), and context ('offensive security analysis'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'run_cypher_query' or 'search_graph', which handle query execution rather than interpretation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it's for 'offensive security analysis' and references 'run_cypher_query' in the parameter description, suggesting it should be used after executing a query. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., direct analysis of raw results) and doesn't mention any exclusions or prerequisites, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the security implications ('abused for privilege escalation and lateral movement'), which adds valuable context beyond basic functionality. However, it lacks details on permissions required, error handling, or response format, leaving gaps for a tool with security relevance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by parameter details. Every sentence adds value, though the security context sentence could be more integrated. It's front-loaded with the core functionality, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (security-focused query with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers parameters well and adds security context, but lacks details on return values, error cases, or authentication requirements, which are important for a tool in this domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explicitly defines all three parameters ('computer_id', 'limit', 'skip') with clear explanations of their purposes, including defaults and pagination context for 'skip'. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('constrained delegation rights of a specific computer'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_user_constrained_delegation_rights' beyond the computer vs. user focus, which is implied but not stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it explains what constrained delegation rights are, it doesn't mention when to choose this over other computer-related tools (e.g., 'get_computer_admin_rights') or the user-focused sibling tool, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clarifies the security implications of RDP rights ('can be abused for lateral movement and privilege escalation'), which adds valuable context beyond basic functionality. However, it doesn't mention performance characteristics (e.g., rate limits), error conditions, or response format, leaving gaps in behavioral understanding for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized: it starts with the core purpose, adds explanatory context about RDP rights, and lists parameters with clear explanations. Every sentence earns its place, but the security warning, while useful, slightly extends beyond minimal necessity, preventing a perfect score for pure conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers purpose and parameters well, but lacks details on output format (e.g., what data is returned per user), error handling, or integration with sibling tools. This makes it minimally viable but not fully comprehensive for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the input schema provides no descriptions for parameters. The description compensates fully by explaining all three parameters: 'computer_id' (the ID to query), 'limit' (maximum number to return with default), and 'skip' (for pagination with default). This adds essential meaning beyond the bare schema, making parameter usage clear and complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'retrieves the users that have RDP rights to this specific computer in the domain.' It includes a specific verb ('retrieves'), resource ('users with RDP rights'), and scope ('this specific computer in the domain'). However, it doesn't explicitly differentiate from sibling tools like 'get_computer_rdp_rights' or 'get_computer_ps_remote_users', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions that 'RDP rights can be abused for lateral movement and privilege escalation,' which hints at security analysis contexts, but doesn't specify prerequisites, compare to similar tools (e.g., 'get_computer_rdp_rights'), or indicate when not to use it. This leaves the agent with insufficient decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clarifies that the tool retrieves 'active sessions' and implies read-only behavior through the verb 'retrieves', but doesn't explicitly state whether it's safe, requires authentication, has rate limits, or what the output format looks like. The security context about attack paths adds some value, but key operational details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by detailed parameter documentation. The first sentence efficiently states the core function, and the 'Args' section is organized. However, the middle sentences about attack paths, while informative, could be more concise or integrated better with usage guidelines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is moderately complete. It covers parameters well but lacks output details, error handling, or explicit behavioral traits. The security context is helpful, but for a tool with no structured metadata, more operational guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents all three parameters with clear semantics: 'computer_id' specifies which computer to query, 'limit' defines the maximum sessions returned with a default, and 'skip' handles pagination with a default. This fully compensates for the 0% schema description coverage, providing essential context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves the active sessions of a specific computer within the domain.' It specifies the verb ('retrieves'), resource ('active sessions'), and scope ('specific computer within the domain'). However, it doesn't explicitly differentiate from sibling tools like 'get_user_sessions' or 'get_group_sessions', which reduces it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions potential use cases (e.g., identifying targets for lateral movement), but doesn't specify prerequisites, exclusions, or compare it to related tools like 'get_user_sessions' or 'get_computer_info'. This leaves the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool does (retrieves controllers) and the purpose (identify access paths), but lacks critical behavioral details: whether this is a read-only operation, what format the results return, if there are rate limits, authentication requirements, or error conditions. The description doesn't contradict annotations (none exist), but provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It begins with the core purpose, adds explanatory context about controllers, states the use case, and then documents parameters clearly. Every sentence adds value, though the second sentence ('Controllers are entities...') could be integrated more tightly with the first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no annotations, and no output schema, the description is moderately complete. It adequately explains the parameters and purpose, but lacks information about return format, error handling, and behavioral constraints. For a read operation in what appears to be a security analysis context, more detail about result structure and limitations would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema. The schema has 0% description coverage (only titles), but the description provides clear semantic explanations: 'group_id: The ID of the group to query', 'limit: Maximum number of controllers to return (default: 100)', 'skip: Number of controllers to skip for pagination (default: 0)'. This fully documents all three parameters with purpose and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves the controllers of a specific group in the domain.' It specifies the verb ('retrieves') and resource ('controllers of a specific group'), and distinguishes it from siblings like get_group_members or get_group_info. However, it doesn't explicitly differentiate from similar tools like get_computer_controllers or get_user_controllers beyond the group focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'This can be used to help identify paths to gain access to a specific group.' This suggests a security/access analysis use case. However, it doesn't explicitly state when to use this tool versus alternatives like get_group_admin_rights or get_group_controllables, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination behavior through 'skip' and 'limit' parameters, but doesn't describe the return format (e.g., list structure, user attributes), error conditions, authentication requirements, rate limits, or whether this is a read-only operation. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose statement, use case example, and parameter documentation. The parameter section is well-structured with clear explanations. The security use case sentence could be considered slightly extraneous but adds context. Overall efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no annotations, no output schema, and 0% schema description coverage, the description does a good job with parameter semantics but lacks output format details, error handling, and behavioral context. It's adequate for basic usage but incomplete for full agent understanding. The security use case adds some context but doesn't compensate for the missing structural information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% (no parameter descriptions in schema), but the description provides clear semantic explanations for all three parameters: 'ou_id' identifies the OU to query, 'limit' specifies maximum results with default, and 'skip' handles pagination with default. This fully compensates for the schema gap and adds meaningful context beyond basic type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves'), resource ('users within a specific OU in the domain'), and scope ('within a specific OU'), which distinguishes it from sibling tools like 'get_users' (general user retrieval) or 'get_ou_computers' (different resource type). The purpose is unambiguous and well-specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_users' (all users) or 'get_group_members' (users in groups). It mentions a security use case ('identify potential targets for lateral movement and privilege escalation'), but this is an example application rather than usage guidance. No explicit when/when-not instructions or prerequisite context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a retrieval operation (implying read-only) and adds context about pagination (limit/skip) and the security relevance of results. However, it doesn't disclose critical behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the user_id doesn't exist. The description adds some value but leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by clarifying context and a parameter section. Each sentence earns its place, but the second sentence ('These are entities that the user can control and manipulate within the domain.') is somewhat redundant with the first, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters, the description is moderately complete. It covers the purpose and parameters well but lacks details on behavioral aspects (e.g., error handling, permissions) and output format. For a retrieval tool in a security context with many siblings, more guidance on usage and result interpretation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (titles only in schema), the description fully compensates by explaining all three parameters: user_id ('The ID of the user to query'), limit ('Maximum number of controllables to return'), and skip ('Number of controllables to skip for pagination'), including their default values. This adds essential meaning beyond the bare schema, making parameter purposes clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'Security Principals within the domain that a specific user has administrative control over' and mentions these are 'entities that the user can control and manipulate.' This specifies both the verb (retrieves) and resource (Security Principals under user control). However, it doesn't explicitly differentiate from similar sibling tools like get_user_controllers or get_computer_controllables, which appear to have related but distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions these controllables are 'potential targets for lateral movement, privilege escalation, and persistence,' which hints at security analysis contexts, but doesn't specify prerequisites, exclusions, or name any sibling tools as alternatives. Without explicit when/when-not instructions, usage remains ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination behavior through skip/limit parameters and implies a read-only operation ('retrieves'), but doesn't address authentication requirements, rate limits, error conditions, or what happens when no controllers exist. The description adds some context but leaves significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter documentation. All sentences earn their place, though the second sentence ('Controllers are entities that have control over the specified user') could be considered slightly redundant with the first. Overall, it's appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, no output schema), the description is adequate but has gaps. It covers parameters well and provides usage context, but doesn't describe the return format, error handling, or authentication requirements. For a security-focused tool that likely returns structured data about controllers, more detail about the response would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the schema. With 0% schema description coverage, the description fully documents all three parameters: user_id ('The ID of the user to query'), limit ('Maximum number of controllers to return'), and skip ('Number of controllers to skip for pagination'), including default values. This completely compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves') and resource ('controllers of a specific user'), making the purpose explicit. It distinguishes from many siblings by focusing on user controllers rather than computer/group/GPO controllers, though it doesn't explicitly differentiate from similar tools like get_user_controllables or get_user_admin_rights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by stating 'This can be used to help identify paths to gain access to a specific user,' which suggests security/privilege escalation scenarios. However, it doesn't explicitly state when to use this tool versus alternatives like get_user_controllables or get_user_admin_rights, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a search operation with typical return format ('matches on node names'), but lacks details on permissions, rate limits, pagination, error conditions, or whether it's read-only/destructive. The behavioral disclosure is basic but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences plus parameter explanations. It's front-loaded with the core purpose, followed by elaboration and parameter details. There's minimal redundancy, though the second sentence slightly rephrases the first without adding substantial new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter search tool with no annotations and no output schema, the description provides adequate basic information but lacks completeness. It covers what the tool does and parameters, but doesn't describe return format details, error handling, or performance characteristics that would help an agent use it effectively in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It successfully explains both parameters: 'query' as 'Search text to find nodes by name' and 'search_type' with its two options and default. This adds meaningful context beyond the bare schema, though it doesn't cover all possible edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for nodes in the Bloodhound graph by name.' It specifies the verb ('search'), resource ('nodes'), and scope ('Bloodhound graph'), but doesn't explicitly differentiate from sibling tools like 'search_objects' or 'get_*' tools that retrieve specific node types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'find specific nodes...based on a search query' and mentions typical results, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'search_objects' or 'get_*' tools for specific node types. No exclusions 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool as a retrieval operation, which implies read-only behavior, but doesn't specify authentication needs, rate limits, error conditions, or pagination details beyond the skip parameter. The cybersecurity context hints at sensitive data, but permissions or access constraints aren't addressed, leaving significant gaps for a tool with security implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter explanations. Each sentence adds value: the first defines the tool, the second elaborates on controllables, the third provides security context, and the Args section documents parameters efficiently. Minor verbosity in the second sentence could be trimmed, but overall it's front-loaded and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (security-focused domain tool with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers purpose, parameters, and high-level context, but lacks details on authentication, error handling, return format, or performance characteristics. For a tool with cybersecurity implications, more behavioral transparency would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains computer_id as 'The ID of the computer to query', limit as 'Maximum number of controllables to return (default: 100)', and skip as 'Number of controllables to skip for pagination (default: 0)'. This adds meaningful context beyond the bare schema, though it doesn't detail ID format or pagination mechanics. With 3 parameters fully documented in the description, it effectively bridges the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves') and resource ('Security Principals within the domain that a specific computer has administrative control over'), distinguishing it from siblings like get_computer_controllers (which likely shows who controls the computer) or get_computer_admin_rights (which likely shows the computer's administrative rights). The cybersecurity context ('potential targets for lateral movement, privilege escalation, and persistence') further clarifies the purpose beyond basic retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when investigating a computer's attack surface for security purposes, but it doesn't explicitly state when to use this tool versus alternatives like get_computer_controllers or get_user_controllables. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the cybersecurity framing and parameter requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the security implications of SQL administrative rights but doesn't describe what the tool actually returns (format, structure), whether it requires specific permissions, rate limits, or error conditions. The pagination behavior is only partially covered in the parameter section.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by context about SQL administrative rights, then a dedicated parameter section. Every sentence adds value, though the security context sentence could be more integrated with usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with 3 parameters and no output schema, the description adequately covers the purpose and parameters. However, it lacks details about return format, error handling, and authentication requirements. The security context is helpful but doesn't fully compensate for missing behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents all three parameters with clear explanations of their purpose. With 0% schema description coverage, this fully compensates by providing computer_id as 'The ID of the computer to query', limit as 'Maximum number of SQL administrative rights to return', and skip as 'Number of SQL administrative rights to skip for pagination'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('retrieves'), resource ('SQL administrative rights'), and scope ('of a specific computer within the domain'). It distinguishes from sibling tools like get_computer_admin_rights and get_user_sql_admin_rights by specifying it's about SQL administrative rights for computers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning SQL administrative rights can be abused for lateral movement and privilege escalation, suggesting security assessment scenarios. However, it doesn't explicitly state when to use this tool versus alternatives like get_computer_admin_rights or get_user_sql_admin_rights, nor does it provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes the tool's purpose and parameters but doesn't address key behavioral aspects: whether this is a read-only operation, what format the results return, if there are rate limits, authentication requirements, or potential performance implications. The description provides basic functional context but misses operational details needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose statement, context explanation, and parameter documentation in separate sections. It's appropriately sized (4 sentences plus parameter details) with no redundant information. Every sentence adds value, though the parameter explanations could be slightly more detailed given the 0% schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description provides adequate functional context but has significant gaps. It explains what the tool does and documents parameters, but doesn't describe return values, error conditions, or operational constraints. Given the complexity of graph analysis and attack path planning, more behavioral context would be beneficial for safe agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by clearly explaining all three parameters in the Args section: 'source_node: ID of the source node', 'target_node: ID of the target node', and 'edge_type: Type of edge (relationship) between the nodes'. This adds crucial semantic meaning beyond the bare schema types (integer, integer, string), though it could provide more detail about edge_type values or ID formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find valid relay targets') and resource ('for a given edge in the Bloodhound graph'), with explicit context about what relay targets represent ('potential nodes that could be used to relay an attack or privilege escalation between two nodes') and their purpose ('critical for advanced attack path planning'). It distinguishes from sibling tools by focusing on relay target identification rather than querying specific entities or relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for a given edge in the Bloodhound graph') and purpose ('critical for advanced attack path planning'), suggesting it's used when analyzing attack paths involving relay nodes. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_shortest_path' or 'search_graph', and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core functionality but lacks important behavioral details: it doesn't mention whether this requires special permissions, what happens when the user doesn't exist, what format the memberships are returned in, whether there are rate limits, or how errors are handled. The security context hint is useful but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by a brief explanation of what memberships are, a security context note, and a parameter section. While efficient, the second sentence ('Group memberships are the groups...') is somewhat redundant with the first and could be tightened. Overall, it's appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 3 parameters and no output schema, the description is adequate but has gaps. It covers the basic purpose and parameters well, but without annotations or output schema, it should ideally describe the return format (e.g., list of group objects with IDs/names) and any important constraints. The security context is helpful but doesn't fully compensate for missing behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It clearly explains that 'user_id' identifies 'the user to query,' 'limit' controls 'maximum number of memberships to return,' and 'skip' enables pagination by specifying 'number of memberships to skip.' Default values are also provided, giving practical usage guidance not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('group memberships of a specific user within the domain'). It distinguishes from sibling tools like 'get_group_members' (which gets members of a group) and 'get_user_info' (which gets general user information) by focusing specifically on user-to-group membership relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by mentioning 'potential targets for lateral movement and privilege escalation,' suggesting security/audit scenarios. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_user_info' or 'get_group_members,' nor does it mention any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly indicates this is a read operation ('retrieves'), mentions the security context ('can be abused for lateral movement'), and implies pagination behavior through the skip parameter. However, it doesn't disclose error conditions, rate limits, authentication requirements, or what happens when the user_id doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with four sentences: purpose statement, technical explanation, security context, and parameter documentation. The structure is front-loaded with the core functionality. The security warning sentence could be considered slightly extraneous but provides useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with 3 parameters and no annotations or output schema, the description is adequate but has gaps. It covers the basic purpose and parameters but doesn't describe the return format, error handling, or performance characteristics. The security context is helpful but doesn't fully compensate for missing operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantic meaning for all three parameters: user_id identifies the target, limit controls result volume with a default, and skip enables pagination. The description adds value beyond the bare schema by explaining what 'remote PowerShell rights' are and how parameters relate to the query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('retrieves'), the resource ('remote PowerShell rights'), and the target ('of a specific user within the domain'). It distinguishes from siblings like get_computer_ps_remote_rights by focusing on user rights rather than computer rights, and from get_user_info by specifying a particular security attribute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While it mentions the security implications of remote PowerShell rights, it doesn't specify scenarios where this query is appropriate or contrast it with other user-rights tools like get_user_admin_rights or get_user_rdp_rights. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a retrieval operation (implying read-only), mentions security context about controllers, and includes pagination parameters (limit/skip) which suggests a list operation. However, it doesn't disclose rate limits, authentication requirements, error conditions, or what format the controllers are returned in.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with the core purpose, provides background context about AIA CAs, mentions security implications, and then clearly documents parameters. Each sentence earns its place, though the security context sentence could be considered slightly extraneous for pure tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description does a reasonable job but has gaps. It explains parameters well and provides security context, but doesn't describe the return format, error conditions, or authentication requirements. The lack of output schema means the description should ideally explain what 'controllers' data looks like, which it doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the schema. While schema description coverage is 0%, the description clearly explains: 'ca_id: The ID of the AIA CA to query', 'limit: Maximum number of controllers to return (default: 100)', and 'skip: Number of controllers to skip for pagination (default: 0)'. This fully compensates for the lack of schema descriptions and adds meaningful context about defaults and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieves the controllers of a specific AIA Certificate Authority.' It specifies the verb ('retrieves'), resource ('controllers'), and target ('AIA Certificate Authority'). However, it doesn't explicitly differentiate from sibling tools like 'get_enterprise_ca_controllers' or 'get_root_ca_controllers' beyond mentioning AIA specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context by explaining what AIA CAs are and mentioning security implications ('may be able to perform certificate-based attacks'), which suggests when this tool might be relevant. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_enterprise_ca_controllers' or provide clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides limited behavioral information. It mentions this reveals 'underlying components' of complex edges, which suggests a read-only analytical function, but doesn't disclose important details like whether this requires specific permissions, what format the analysis returns, potential rate limits, or error conditions. The description doesn't contradict annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with four sentences that each add value: purpose statement, technical context, utility explanation, and parameter overview. It's front-loaded with the core functionality and wastes no words while covering essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description provides adequate basic context about what the tool does and its parameters. However, it lacks important details about the analysis output format, error handling, and specific behavioral constraints that would be needed for complete understanding, especially given the security-focused context suggested by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds some value by explaining the three parameters: source_node, target_node, and edge_type with examples ('MemberOf', 'AdminTo', 'CanRDP'). However, it doesn't fully compensate for the schema gap - it doesn't explain what format node IDs should be, whether edge_type has specific valid values, or provide complete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze the components of a complex edge between two nodes' with specific examples ('HasPath', 'AdminTo') and explains it reveals underlying relationships. It distinguishes itself from sibling tools by focusing on edge composition analysis rather than querying specific entities or relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool: 'This is useful for understanding exactly how security principals are connected' and mentions it's for analyzing high-level edges composed of multiple relationships. However, it doesn't explicitly state when NOT to use it or name specific alternative tools among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only partially discloses behavior. It describes the tool's purpose and parameters but doesn't mention important behavioral aspects like whether it's a read-only operation, potential rate limits, authentication requirements, error conditions, or what format the controllers are returned in. The description adds some context about identifying access paths but misses key operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter explanations. Every sentence adds value, though the second sentence ('Controllers are entities...') slightly repeats information from the first. The Args section is efficiently formatted but could be integrated more seamlessly with the main description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no output schema, the description does well on parameters but lacks completeness regarding return values and behavioral context. It explains what the tool does and its parameters but doesn't describe the output format, error handling, or operational constraints that would be needed for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the 0% schema coverage. It clearly explains that 'gpo_id' identifies the specific GPO to query, 'limit' controls maximum results with default value, and 'skip' enables pagination with default value. This fully compensates for the lack of schema descriptions and adds practical usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('controllers of a specific GPO'), and distinguishes from siblings by focusing on GPO controllers rather than other entity types like computers, users, or groups. The additional context about identifying access paths further clarifies 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to identify controllers for a specific GPO, but doesn't explicitly state when to use this tool versus alternatives like get_gpo_info or get_gpos. It mentions the purpose ('identify paths to gain access') which provides some context, but lacks explicit guidance on prerequisites or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data (implying read-only), but does not disclose other behavioral traits such as authentication requirements, rate limits, error handling, or the format of returned data. The description adds some context about the security relevance of linked GPOs, but lacks operational details needed for an agent to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, definition, and security context, followed by a parameter section. It is front-loaded with the core functionality. The parameter section is necessary due to low schema coverage, but the overall structure is efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a database query tool with 3 parameters, no annotations, and no output schema), the description is partially complete. It covers purpose, parameter semantics, and some usage context, but lacks details on output format, error conditions, and behavioral constraints. For a tool with no structured support, it should do more to compensate, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides clear semantics for all three parameters: domain_id specifies the domain to query, limit defines the maximum number to return with a default, and skip handles pagination with a default. This adds essential meaning beyond the bare schema, making parameters understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('linked GPOs from a specific domain in the Bloodhound database'), with a specific definition of 'linked GPOs' that distinguishes this tool from other GPO-related tools like get_gpos or get_gpo_info. It provides exact scope and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'potential targets for moving laterally, elevating privileges, or maintaining persistence in the domain,' which suggests when this tool might be relevant in security assessments. However, it does not explicitly state when to use this tool versus alternatives like get_gpos or get_gpo_ous, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions retrieval but doesn't cover permissions needed, rate limits, pagination behavior beyond default parameters, error conditions, or response format. The security context hint is useful but insufficient for a tool with 3 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, usage context, and parameter documentation. All sentences earn their place, though the security context could be more integrated. It's appropriately sized for a 3-parameter tool without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 3 parameters and no output schema, the description is adequate but has gaps. It covers parameters well and provides some security context, but lacks details about return values, error handling, and behavioral constraints. Without annotations, more completeness would be beneficial for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the 0% schema description coverage. It explains all three parameters: 'ou_id' (ID of OU to query), 'limit' (maximum groups with default), and 'skip' (pagination offset with default). This fully compensates for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and the resource 'groups within a specific OU in the domain.' It distinguishes from siblings like 'get_groups' (all groups) and 'get_ou_computers' (computers in OU) by specifying OU-scoped group retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides implied usage context ('identify potential targets for lateral movement and privilege escalation'), suggesting security assessment scenarios. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_groups' or 'get_ou_users', and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read operation ('Retrieves'), mentions the security context (Active Directory administrative rights), and warns about potential abuse implications. However, it doesn't disclose important behavioral aspects like authentication requirements, rate limits, error conditions, or what happens when the user doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by explanatory context and parameter documentation. Every sentence adds value: the first states the core function, the second explains what administrative rights are, the third provides security context, and the parameter section adds necessary details. It could be slightly more concise by integrating the security context more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description does reasonably well. It covers the purpose and parameters adequately but lacks information about return format, error handling, authentication requirements, and typical response structure. The security context about abuse is helpful but doesn't fully compensate for missing operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics beyond the input schema, which has 0% description coverage. It explains that 'user_id' identifies 'the user to query', clarifies that 'limit' controls 'maximum number of administrative rights to return' with a default, and specifies that 'skip' is for 'pagination' with a default. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('administrative rights of a specific user in the domain'). It distinguishes from sibling tools like 'get_computer_admin_rights' by specifying user-focused rights rather than computer-focused, and from 'get_user_info' by focusing specifically on administrative privileges rather than general user information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions administrative rights can be abused for lateral movement, persistence, and privilege escalation, it doesn't specify when this tool should be chosen over other user-focused tools like 'get_user_info' or 'get_user_memberships', nor does it mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately describes the core operation (retrieving memberships) and mentions security implications, but doesn't cover important behavioral aspects like authentication requirements, rate limits, error conditions, or whether the operation is read-only (though implied by 'Retrieves'). The pagination behavior is documented in the parameter section but not in the main description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter explanations. Every sentence serves a purpose: the first states the operation, the second clarifies 'group memberships,' the third provides security context, and the parameter section is essential given the schema's lack of descriptions. It could be slightly more concise by integrating parameter details more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description does a reasonable job. It covers the purpose, parameters, and some security context. However, it lacks details about return format, error handling, authentication needs, and doesn't fully compensate for the missing output schema that would describe the membership data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a dedicated 'Args' section that explains all three parameters beyond what the schema offers (0% coverage). It clarifies that 'computer_id' identifies the computer to query, 'limit' controls maximum returns with a default, and 'skip' enables pagination with a default. This adds meaningful semantic context that the bare schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('group memberships of a specific computer within the domain'). It distinguishes from siblings like 'get_computer_info' or 'get_group_memberships' by focusing specifically on computer-to-group relationships rather than general computer info or group-to-member relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'potential targets for lateral movement and privilege escalation,' which suggests security/penetration testing scenarios. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_computer_controllers' or 'get_computer_admin_rights,' nor does it provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool retrieves a list (implying read-only behavior) and mentions security risks (abuse for lateral movement), which adds useful context. However, it lacks details on permissions required, rate limits, error handling, or response format, leaving behavioral gaps for a tool with security implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, context explanation, and parameter details in a bullet-like format. It is appropriately sized with no wasted sentences, though the security context sentence, while valuable, slightly extends beyond minimal necessity. Overall, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides good parameter semantics and purpose clarity but lacks details on return values (e.g., format of the list), error conditions, or authentication needs. For a security-focused tool with potential operational impact, this leaves gaps in completeness, though it covers basics adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly lists and explains all three parameters (computer_id, limit, skip), providing clear semantics beyond the schema's basic types. The explanations include defaults and purposes (e.g., pagination for skip), effectively documenting the parameters, though it could note that computer_id is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves a list of hosts') and resource ('that this specific computer has the right to PS remote to'), distinguishing it from sibling tools like get_computer_ps_remote_users. It provides context about what PS remote rights are and their security implications, making the purpose unambiguous and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the computer_id parameter and the security context of PS remote rights, but it does not explicitly state when to use this tool versus alternatives like get_computer_ps_remote_users or other rights-related tools. No explicit exclusions or prerequisites are provided, leaving usage context partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a read operation (retrieves), includes pagination behavior through limit/skip parameters, and adds important security context about abuse potential. However, it doesn't mention authentication requirements, rate limits, error conditions, or what format the returned users come in (just IDs, names, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose statement, explanatory context, and clear parameter documentation. Every sentence earns its place, though the security warning could be more integrated. The Args section is appropriately formatted but slightly redundant with the preceding text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter read tool with no annotations and no output schema, the description covers the essential what and how adequately. However, it lacks details about the return format (what user data is included), error handling, and more specific usage guidance. The security context is valuable but doesn't fully compensate for missing operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all three parameters: computer_id identifies the target computer, limit controls result count with default, and skip enables pagination. It adds meaningful context beyond the bare schema, though it doesn't specify format requirements for computer_id or constraints on limit/skip values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('retrieves the users that have PS remote rights') and resource ('this specific computer in the domain'), distinguishing it from sibling tools like get_computer_ps_remote_rights (which likely returns rights objects rather than users) and get_computer_admin_users (which focuses on admin rights). The explanation of what PS remote rights are adds valuable context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the security warning about abuse potential, suggesting this is for security auditing. However, it doesn't explicitly state when to use this tool versus alternatives like get_computer_ps_remote_rights or get_computer_admin_users, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'retrieves a list' (implying read-only, non-destructive) and mentions security implications ('abused for lateral movement'), which adds useful context. However, it lacks details on permissions required, rate limits, error conditions, or pagination behavior beyond the skip/limit parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, explanatory context about RDP rights, and a parameter section. It avoids redundancy and is appropriately sized. However, the security context sentence, while useful, could be more tightly integrated, and the parameter explanations are slightly verbose but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description does a decent job explaining parameters and purpose. However, it lacks details on return values (e.g., format of the host list), error handling, or authentication requirements, leaving gaps given the complexity and security context implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear explanations for all three parameters: 'computer_id' (the ID to query), 'limit' (maximum number to return with default), and 'skip' (for pagination with default). This adds significant meaning beyond the bare schema, though it doesn't specify format constraints (e.g., ID structure) or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves') and resource ('list of hosts that this specific computer has the right to RDP to'), making the purpose specific and unambiguous. It distinguishes from siblings like 'get_computer_rdp_users' by focusing on rights rather than users, and from 'get_computer_admin_rights' by specifying RDP rights specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'RDP rights can be abused for lateral movement and privilege escalation within the domain,' which suggests security/penetration testing scenarios. However, it does not explicitly state when to use this tool versus alternatives like 'get_computer_rdp_users' or other rights-related tools, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates this is a read operation ('Retrieves') and provides context about the security significance of the data. However, it doesn't disclose behavioral traits like rate limits, authentication requirements, pagination behavior beyond the skip parameter, or what happens when no results are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three focused paragraphs: purpose statement, definition clarification, and parameter explanations. Every sentence adds value, though the security context sentence could be more tightly integrated with the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter read tool with no annotations and no output schema, the description is adequate but has gaps. It covers parameters well and provides security context, but doesn't describe the return format, error conditions, or how results are structured. The absence of output schema increases the need for return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all three parameters in the Args section: domain_id identifies the target domain, limit controls result count with default, and skip enables pagination with default. This adds crucial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('foreign admins from a specific domain in the Bloodhound database'), with a precise definition of what 'Foreign Admins' are. It distinguishes this tool from siblings like get_foreign_users or get_foreign_groups by focusing specifically on administrative privileges across domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for security analysis ('potential targets for lateral movement and privilege escalation'), but doesn't explicitly state when to use this tool versus alternatives like get_computer_admin_rights or get_user_admin_rights. No explicit exclusions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates this is a read operation ('retrieves') and adds context about the security implications of the data. However, it lacks details on behavioral traits such as rate limits, authentication requirements, error handling, or response format, which are important for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose, followed by a definition and usage context, then parameter details. Every sentence adds value, but the structure could be slightly improved by integrating the 'Args' section more seamlessly or using bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose, parameters, and some context, but lacks details on output format, error cases, or integration with sibling tools. For a tool with no structured support, it should do more to compensate, such as explaining the return data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains each parameter's purpose (e.g., 'domain_id: The ID of the domain to query'), adding meaning beyond the input schema which has 0% description coverage. It clarifies defaults and pagination use for 'limit' and 'skip'. Since schema coverage is low, the description compensates well, though it could provide more on parameter constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'retrieves foreign GPO controllers from a specific domain in the Bloodhound database' with a specific verb ('retrieves') and resource ('foreign GPO controllers'), and provides a detailed definition of what foreign GPO controllers are. It distinguishes from sibling tools like 'get_gpo_controllers' by specifying 'foreign' controllers across domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating these are 'potential targets for lateral movement and privilege escalation as well as cross domain compromise,' suggesting when this tool might be relevant. However, it does not explicitly state when to use this tool versus alternatives like 'get_gpo_controllers' or other domain-specific tools, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves data (implying read-only behavior) and hints at security implications, but lacks details on permissions required, rate limits, pagination behavior beyond skip/limit, or what the return format looks like. It adds some behavioral context but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by definition and context, then parameter details. Every sentence adds value, but it could be slightly more concise by integrating the parameter explanations more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no output schema, the description does a decent job explaining parameters and purpose. However, as a data retrieval tool in a security context with no annotations, it should ideally cover more about return values, error conditions, or usage examples to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly documents all three parameters (domain_id, limit, skip) with clear meanings, including defaults and purposes like pagination. This adds significant value beyond the bare schema, though it doesn't specify format constraints for domain_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('foreign users from a specific domain in the Bloodhound database'), plus provides a detailed definition of 'Foreign Users' that distinguishes it from sibling tools like get_users or get_user_info. It explicitly explains the security relevance of these entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'potential targets for lateral movement and privilege escalation,' which suggests when this tool might be relevant in security assessments. However, it doesn't explicitly state when to use it versus alternatives like get_users or get_user_memberships, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool's purpose and security use case but lacks details on behavioral traits like whether it requires specific permissions, how it handles errors, if there are rate limits, or what the return format looks like (e.g., list of OU names or objects). For a read operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first, followed by usage context and parameter details. Every sentence adds value, but the parameter explanations could be slightly more integrated into the flow rather than listed as bullet points, though this is minor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers purpose, usage context, and parameter semantics adequately, but lacks details on behavioral aspects like permissions, error handling, or return format. For a read tool in a security context, more transparency would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all three parameters: 'gpo_id' is explained as 'The ID of the GPO to query', 'limit' as 'Maximum number of OUs to return (default: 100)', and 'skip' as 'Number of OUs to skip for pagination (default: 0)'. This provides clear context beyond the basic schema, though it doesn't specify format details like what constitutes a valid GPO ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('OUs that are linked to a specific GPO in the domain'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'get_gpos' (lists GPOs) or 'get_ous' (lists OUs) by focusing on the relationship between a specific GPO and its linked OUs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to identify potential targets for lateral movement and privilege escalation'), which helps guide usage in security assessment scenarios. However, it does not explicitly state when not to use it or name specific alternatives among the many sibling tools, such as 'get_ou_gpos' (which retrieves GPOs linked to an OU, the inverse relationship).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the tool retrieves GPOs and their security relevance, but does not disclose behavioral traits such as rate limits, authentication needs, error handling, or response format. It adds some context about GPOs being key for identifying edges, but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, GPO explanation, and security context, followed by a structured Args section. It is front-loaded with key information, though the security sentence could be more integrated. Minimal waste, but slightly verbose in the explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters with 0% schema coverage, the description is moderately complete. It covers purpose, parameters, and some security context, but lacks details on return values, error cases, or performance considerations. Adequate for basic use but with gaps for full operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'domain_id' as 'The ID of the domain to query', 'limit' as 'Maximum number of GPOs to return (default: 100)', and 'skip' as 'Number of GPOs to skip for pagination (default: 0)'. This clarifies purpose and defaults beyond the bare schema, though it could provide more on parameter constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieves' and resource 'Group Policy Objects (GPOs)' with specific context 'from a specific domain in the Bloodhound database.' It distinguishes from siblings by focusing on GPO retrieval rather than other entities like users, computers, or groups, and explicitly mentions GPOs are for policy settings in Active Directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying GPOs in a domain, particularly for security analysis ('abused for persistence and privilege escalation'), but does not explicitly state when to use this tool versus alternatives like 'get_gpo_info' or 'get_linked_gpos'. It provides context but lacks direct comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It adequately describes the read-only nature ('Retrieves') and security implications, but lacks details on authentication requirements, rate limits, error conditions, or return format. The behavioral context is basic but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose first, followed by Tier 0 explanation, usage context, and parameter details. Each sentence adds value, though the security context sentence could be more integrated. Overall efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description provides adequate basics but lacks completeness. It covers purpose and parameters well, but misses details on return format, error handling, and deeper behavioral traits needed for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantic explanations for all three parameters: gpo_id identifies the target, limit controls result size with default, and skip enables pagination. This adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves'), target resource ('Tier 0 groups linked to a specific GPO'), and domain context. It distinguishes this tool from siblings by focusing on GPO-linked Tier 0 groups rather than general GPO or group queries, with explicit explanation of Tier 0 significance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for security analysis ('identify potential targets for lateral movement and privilege escalation'), providing some context. However, it doesn't explicitly state when to use this versus alternative tools like get_gpo_info or get_groups, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool retrieves data (read-only implied) and mentions pagination via skip/limit, but lacks details on permissions needed, rate limits, error handling, or what 'controllables' specifically entail beyond 'Security Principals'. Some behavioral context is given but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, elaboration, and security context. The Args section is clear but could be integrated more seamlessly. No wasted words, though the security context sentence might be slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters with 0% schema coverage, the description is moderately complete. It covers purpose and parameters but lacks details on return format (e.g., list of objects, fields), error cases, or deeper behavioral traits like authentication requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining group_id queries a specific group, limit caps results with a default, and skip enables pagination with a default. However, it doesn't specify data types or constraints (e.g., limit range), leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves') and resource ('Security Principals within the domain that a specific group has administrative control over'), making the purpose specific. It distinguishes from siblings by focusing on what a group controls (e.g., vs. get_group_controllers which likely shows who controls the group).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for security analysis ('potential targets for lateral movement, privilege escalation, and persistence'), but does not explicitly state when to use this tool vs. alternatives like get_group_controllers or get_computer_controllables. No exclusions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes what DCOM rights are and their security implications, which adds useful context. However, it doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or what happens if the group doesn't exist. The description doesn't contradict annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with four sentences: purpose statement, DCOM explanation, security context, and parameter details. It's front-loaded with the core functionality. The parameter section is clear but could be slightly more integrated with the main text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description is moderately complete. It covers purpose, security context, and parameter semantics adequately. However, it lacks details about return format, error conditions, or examples, which would be helpful given the complexity of DCOM rights and the absence of structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all three parameters: 'group_id' identifies the target group, 'limit' controls maximum returns with a default, and 'skip' enables pagination with a default. This adds meaningful context beyond the bare schema, though it doesn't specify format constraints for group_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('DCOM rights of a specific group within the domain'), making the purpose specific and actionable. It distinguishes this tool from siblings like 'get_computer_dcom_rights' by focusing on groups rather than computers, and from other group-related tools by specifying DCOM rights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning DCOM rights for privilege escalation and lateral movement, suggesting it's for security analysis. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_group_admin_rights' or 'get_group_ps_remote_rights', nor does it provide exclusions or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a read operation ('retrieves') and provides context about what 'active sessions' means. However, it doesn't mention authentication requirements, rate limits, error conditions, or what the return format looks like. The security context about lateral movement is useful but doesn't fully describe behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences plus parameter documentation. The first sentence states the purpose, the second clarifies 'active sessions,' and the third provides security context. The Args section is well-structured. Minor typo ('hte' instead of 'the') slightly reduces quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description provides adequate coverage of purpose and parameters but lacks details about return format, error handling, and authentication requirements. The security context is helpful but doesn't fully compensate for missing behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by providing clear parameter documentation in the Args section. It explains group_id as 'The ID of the group to query,' limit as 'Maximum number of sessions to return' with default, and skip as 'Number of sessions to skip for pagination' with default. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('retrieves') and resource ('active sessions of the members of a specific group within the domain'). It distinguishes itself from sibling tools like get_user_sessions and get_computer_sessions by specifying group-based session retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'potential targets for lateral movement and privilege escalation,' but doesn't explicitly state when to use this tool versus alternatives like get_user_sessions or get_computer_sessions. No explicit exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action ('retrieves') and adds security context about potential abuse, which is useful. However, it lacks details on permissions needed, rate limits, pagination behavior beyond skip/limit, or response format, leaving gaps in operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by parameter explanations. Sentences are efficient, with no wasted words. It could be slightly more concise by integrating the security note into the main purpose, but overall it's appropriately sized and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, 0% schema coverage, no annotations, and no output schema, the description provides adequate basics but lacks depth. It covers purpose and parameters well but misses behavioral details like error handling, authentication needs, or example outputs. For a tool with moderate complexity and no structured support, it's minimally complete but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all three parameters: user_id specifies the target, limit controls result count with a default, and skip handles pagination. This adds meaningful context beyond the bare schema, though it could detail data types or constraints more explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves') and resource ('SQL administrative rights of a specific user within the domain'), making the purpose specific and actionable. It distinguishes from siblings by focusing on SQL admin rights for users, unlike tools like get_computer_sql_admin_rights or get_user_admin_rights, which target different resources or rights types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'a specific user within the domain' and the security context of SQL rights, but it does not explicitly state when to use this tool versus alternatives like get_computer_sql_admin_rights or general user rights tools. No exclusions or prerequisites are provided, leaving usage context partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly indicates this is a read operation ('Retrieves') and provides security context about the data's purpose. However, it doesn't disclose important behavioral traits like authentication requirements, rate limits, error conditions, or whether this queries live data versus cached information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, explanatory context, and dedicated parameter documentation. Every sentence adds value, though the second sentence slightly rephrases the first. The Args section is efficiently formatted with clear explanations for each parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description provides good parameter documentation and clear purpose. However, it lacks information about return format, error handling, authentication requirements, and doesn't fully address when to use this versus similar sibling tools. The security context is helpful but doesn't compensate for all missing behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all three parameters in the Args section. It clarifies computer_id identifies 'the computer to query', limit controls 'maximum number of administrative users to return', and skip enables 'pagination'. Default values are also provided, adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves'), resource ('administrative users of a specific computer'), and scope ('in the domain'). It distinguishes from sibling tools like get_computer_info or get_computer_controllers by focusing specifically on admin users, not general computer data or other relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the security-focused explanation ('identify potential targets for lateral movement and privilege escalation'), but doesn't explicitly state when to use this tool versus alternatives like get_computer_admin_rights or get_computer_controllers. No explicit exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes what the tool does (retrieves controllers) and the purpose (identify access paths), but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what format the results come in. The description provides basic operational context but lacks important behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, explanation of controllers, usage context, and parameter documentation. It's appropriately sized for a 3-parameter tool, though the parameter documentation could be slightly more concise. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description provides good parameter documentation and purpose clarity. However, it lacks information about return format, error handling, and authentication requirements. Given the complexity of domain/security tools, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear documentation for all 3 parameters: computer_id (what it represents), limit (maximum number to return with default), and skip (pagination with default). The description adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves') and resource ('controllers of a specific computer'), and distinguishes it from siblings like get_computer_info or get_computer_admin_rights by focusing specifically on controllers. It also provides context about what controllers are and their purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to identify access paths to a computer, but doesn't explicitly state when to use this tool versus alternatives like get_computer_controllables or get_computer_admin_users. It provides some context but lacks explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool retrieves data (read-only implied by 'Retrieves'), mentions security implications, and hints at pagination via skip/limit parameters. However, it lacks details on authentication needs, rate limits, error handling, or response format, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, security context, and parameter details. It is front-loaded with the core functionality, though the security implications sentence could be more concise. No wasted words, but minor room for tightening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is moderately complete. It covers parameter semantics well and provides security context, but lacks details on return values, error cases, or operational constraints, which are important for a tool with security implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully. It provides clear semantics for all three parameters: domain_id ('ID of the domain to query'), limit ('Maximum number of DC Syncers to return'), and skip ('Number of DC Syncers to skip for pagination'), including default values. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves security principals') and resource ('given the "GetChanges" and "GetChangesAll" permissions on the domain'), distinguishing it from siblings like get_domains or get_users by focusing on DC Sync attack vectors. It explicitly identifies the security principals as users, groups, and computers with specific permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for security auditing by mentioning 'DCSync attack' and 'targets for lateral movement or privilege escalation', but does not explicitly state when to use this tool versus alternatives like get_security_controllers or other sibling tools. No explicit exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the security implications ('can be abused for lateral movement and privilege escalation'), which adds useful behavioral context beyond just being a read operation. However, it doesn't mention permissions required, rate limits, error conditions, or what the return format looks like, leaving gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three purpose-focused sentences followed by a well-structured Args section. The security context sentence earns its place by providing important behavioral insight. Minor improvement could be front-loading the Args section more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 3 parameters and no output schema, the description does reasonably well on purpose and parameters. However, without annotations and with no output schema, it should ideally describe the return format or structure. The security context helps, but completeness is limited by missing output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear documentation for all 3 parameters in the Args section. It explains group_id's purpose, defines limit with default value and meaning, and explains skip for pagination with default. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves') and resource ('remote PowerShell rights of a specific group within the domain'), making the purpose explicit. It distinguishes from siblings by focusing on group-level PowerShell rights (vs. computer-level or user-level rights tools like get_computer_ps_remote_rights or get_user_ps_remote_rights).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by explaining what remote PowerShell rights are and their security implications, but doesn't explicitly state when to use this tool versus alternatives. No specific exclusions or prerequisites are mentioned, leaving the agent to infer from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clarifies this is a read operation ('Retrieves'), mentions pagination behavior through limit/skip parameters, and adds security context about potential abuse. However, it doesn't disclose authentication requirements, rate limits, error conditions, or what the return format looks like (though no output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three focused sentences: purpose statement, RDP rights explanation, and security context. The parameter documentation is clearly separated in an Args section. While efficient, the security context sentence could be considered slightly extraneous for pure tool selection, though it provides valuable usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description does reasonably well by explaining parameters and operation purpose. However, it lacks details about return format, error handling, authentication requirements, and explicit differentiation from sibling tools. The security context helps but doesn't fully compensate for missing structural information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all three parameters: 'group_id' identifies the target group, 'limit' controls maximum returns with default value, and 'skip' enables pagination with default value. This adds crucial meaning beyond the bare schema, making parameter purposes and behaviors clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('RDP rights of a specific group within the domain'), making the purpose explicit. It distinguishes from siblings like 'get_computer_rdp_rights' by specifying group-level rights rather than computer-level, and from 'get_group_info' by focusing specifically on RDP rights rather than general group information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining what RDP rights are and their security implications ('can be abused for lateral movement and privilege escalation'), which suggests this tool is for security auditing. However, it doesn't explicitly state when to use this versus alternatives like 'get_computer_rdp_rights' or 'get_group_info', nor does it provide prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read operation ('Retrieves'), which is appropriate. It adds useful context about DCOM rights' security relevance, but doesn't disclose other behavioral traits like authentication requirements, rate limits, error conditions, or what happens when no rights are found. The description doesn't contradict any annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement upfront, followed by explanatory context about DCOM rights, then a well-organized parameter section. Every sentence adds value: the first states the tool's function, the second explains DCOM rights, the third provides security context, and the Args section documents parameters. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 3 parameters and no output schema, the description is reasonably complete but has gaps. It explains what the tool does and documents parameters, but doesn't describe the return format (what DCOM rights data looks like), pagination behavior beyond skip/limit parameters, or error scenarios. The security context is helpful, but operational details are missing for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a helpful Args section that explains all three parameters beyond what the schema offers (0% schema description coverage). It clarifies that user_id identifies 'the user to query', limit controls 'maximum number of DCOM rights to return', and skip enables 'pagination'. This compensates well for the schema's lack of descriptions, though it doesn't specify format expectations for user_id or constraints on limit/skip values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves'), resource ('DCOM rights'), and target ('of a specific user within the domain'). It distinguishes from sibling tools like get_computer_dcom_rights by focusing on user-level rights rather than computer-level, and from get_user_info by specifying DCOM rights as the data retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by explaining what DCOM rights are and their security implications ('can be abused for privilege escalation and lateral movement'), which suggests this tool is for security auditing. However, it doesn't explicitly state when to use this tool versus alternatives like get_user_info or get_computer_dcom_rights, nor does it provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by describing the output format ('path will show all the intermediary nodes and the types of relationships'), error behavior ('If this returns a 500 or 404 error it is likely that the path does not exist'), and the tool's purpose in security analysis. It doesn't mention rate limits, authentication requirements, or performance characteristics, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with four sentences that each serve a purpose: purpose statement, use case, output description, and error handling. The parameter documentation is clearly separated with an 'Args:' section. It could be slightly more front-loaded by moving the error information to the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% schema description coverage, the description provides good coverage of purpose, parameters, and basic behavior. However, it doesn't describe the return format in detail (beyond mentioning nodes and relationships), doesn't explain what constitutes a valid Object ID, and doesn't mention pagination or result limits for potentially long paths.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all three parameters: 'start_node' as 'Object ID of the starting node (source)', 'end_node' as 'Object ID of the ending node (target)', and 'relationship_kinds' as 'Optional comma-separated list of relationship types'. This adds crucial meaning beyond the bare schema, though it doesn't provide examples or format details for the relationship kinds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find the shortest path'), resource ('between two nodes in the Bloodhound graph'), and purpose ('attack path analysis'). It distinguishes itself from sibling tools like 'search_graph' or 'run_cypher_query' by focusing specifically on shortest path calculation rather than general search or query execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context ('useful for attack path analysis') but doesn't explicitly state when to use this tool versus alternatives like 'search_graph' or 'run_cypher_query'. It mentions error conditions (500 or 404) but doesn't provide guidance on tool selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes what the tool retrieves and the security implications, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the computer_id doesn't exist. The description adds value but leaves gaps in operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured with a clear purpose statement, explanatory context, and a well-organized Args section. Every sentence earns its place, with no wasted words, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description does a reasonable job but has gaps. It explains parameters well and provides security context, but doesn't describe the return format, error handling, or authentication requirements. Given the complexity of security tools, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all three parameters in the Args section. It clarifies that computer_id identifies the target computer, limit controls result size with a default, and skip enables pagination with a default. This adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieves' and the resource 'constrained users of a specific computer in the domain', with a specific explanation of what constrained users are. It distinguishes from siblings like get_computer_admin_users by focusing on constrained delegation access rather than admin rights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to identify potential targets for lateral movement and privilege escalation. It doesn't explicitly state when not to use it or name specific alternatives among siblings, but the context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the operation as a retrieval (read-only) and includes a security context about DCOM rights abuse, which adds value. However, it lacks details on permissions needed, error handling, rate limits, or what the return format looks like (e.g., list of user objects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by explanatory context and a clear parameter section. Every sentence earns its place: the first states what it does, the second explains DCOM rights, the third provides security context, and the Args section is essential given the lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description does a good job covering the basics: purpose, parameters, and security relevance. However, it lacks details on output format (e.g., what fields users have) and any behavioral constraints like authentication needs, leaving some gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must fully compensate. It explicitly documents all three parameters (computer_id, limit, skip) with clear meanings, default values, and usage context (e.g., 'for pagination'), adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves'), target resource ('users that have DCOM rights to a specific computer'), and scope ('in the domain'). It distinguishes itself from sibling tools like get_computer_dcom_rights by focusing on users rather than rights, and from other computer-related tools by specifying DCOM rights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the security warning about DCOM rights being 'abused for privilege escalation and lateral movement,' suggesting this tool is for security assessment. However, it doesn't explicitly state when to use this tool versus alternatives like get_computer_dcom_rights or other computer rights tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clarifies that this is a retrieval/query operation (not a mutation) and hints at security analysis use cases, but lacks details on permissions, rate limits, error handling, or response format. It adds some behavioral context (e.g., pagination via skip/limit) but is incomplete for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, definition, usage hint, and parameter details in a bullet-like format. It is appropriately sized with no redundant sentences, though the usage hint could be more integrated. Every sentence adds value, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters, the description is moderately complete. It covers purpose, parameters, and some context, but lacks details on return values, error cases, or deeper behavioral traits (e.g., what happens if domain_id is invalid). It is adequate for basic use but has gaps for a tool in a security analysis context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully. It provides clear semantics for all three parameters: 'domain_id' as the ID to query, 'limit' as maximum returns with default 100, and 'skip' for pagination with default 0. This adds essential meaning beyond the bare schema, effectively documenting all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and resource 'inbound trusts from a specific domain in the Bloodhound database,' with a precise definition of 'inbound trusts' as trust relationships where the domain is trusted by others. It distinguishes from sibling 'get_outbound_trusts' by specifying directionality, making it highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by defining inbound trusts and mentioning they are 'potential targets for moving to other external domains or other domains within the forest,' which suggests when this tool is relevant. However, it does not explicitly state when to use it versus alternatives like 'get_outbound_trusts' or other trust-related tools, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a read operation ('Retrieves'), includes pagination behavior via limit/skip parameters, and adds security context about how these rights can be abused. However, it doesn't mention authentication requirements, rate limits, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose statement, domain context, security implications, and parameter documentation. The security abuse sentence could be considered slightly extraneous but provides valuable context. Overall efficient with clear sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter read tool with no annotations and no output schema, the description provides good coverage: clear purpose, parameter semantics, and behavioral context about pagination and security implications. Missing details about return format and exact output structure prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides clear documentation for all 3 parameters: computer_id (what to query), limit (maximum number to return with default), and skip (pagination offset with default). This adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('administrative rights of a specific computer in the domain'), with additional context about what administrative rights are. It distinguishes from siblings like 'get_computer_info' or 'get_computer_memberships' by focusing specifically on admin rights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the computer_id parameter and domain context, but does not explicitly state when to use this tool versus alternatives like 'get_computer_admin_users' or 'get_computer_controllers'. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the critical security implication ('can issue arbitrary certificates and potentially compromise the domain'), which is valuable behavioral context. However, it doesn't mention authentication requirements, rate limits, error conditions, or what format the returned controllers are in (e.g., user objects, group objects, or identifiers).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and front-loaded: the first sentence states the core purpose, the second explains the security significance, the third provides usage context, followed by a clean parameter section. Every sentence earns its place with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description does well on purpose and parameters but has gaps. It doesn't describe the return format (what a 'controller' object contains), error conditions, or authentication requirements. The security context is helpful, but operational details are missing for complete agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for all three parameters: ca_id ('The ID of the Enterprise CA to query'), limit ('Maximum number of controllers to return'), and skip ('Number of controllers to skip for pagination'). It even includes default values not present in the schema annotations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves') and resource ('controllers of a specific Enterprise Certificate Authority'), distinguishing it from sibling tools like get_enterprise_ca_info (which retrieves CA info rather than controllers) and get_root_ca_controllers (which targets root CAs instead of enterprise CAs). The mention of ESC3/ESC6 attack paths further clarifies the security context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for identifying ESC3/ESC6 attack paths by finding controllers who can issue arbitrary certificates), but doesn't explicitly mention when NOT to use it or name specific alternatives. It implies usage for security auditing rather than general administration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool retrieves (control relationships) and clarifies terminology, but it lacks details on permissions required, rate limits, pagination behavior beyond skip/limit parameters, or error conditions. It adds useful context but does not fully cover behavioral traits for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, explanatory paragraphs, examples, and a dedicated Args section. It is appropriately sized for the tool's complexity, but the examples could be slightly condensed, and the opening could be more front-loaded to immediately state the core functionality before details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 3 parameters with 0% schema coverage, and no output schema, the description does a good job explaining purpose, parameters, and context. However, it lacks details on return values (e.g., format of retrieved controllers) and full behavioral transparency, which would be needed for a perfect score in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly lists and explains all three parameters (domain_id, limit, skip) with their purposes and defaults, adding significant meaning beyond the bare schema. This fully compensates for the lack of schema descriptions, making parameter semantics clear and complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves security principals with control relationships over other objects in the domain, using specific terminology ('security principals', 'control relationships', 'AdminTo, WriteOwner, GenericAll'). It explicitly distinguishes from domain controllers (AD servers) and provides concrete examples, making the purpose highly specific and well-differentiated from siblings like get_computer_controllers or get_user_controllers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining Bloodhound terminology and the importance of control relationships for attack paths, which implicitly guides when to use this tool. However, it does not explicitly state when to use this tool versus alternatives like get_computer_controllers or get_user_controllers, nor does it mention exclusions or prerequisites, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the security implications ('can be abused for privilege escalation and lateral movement'), which is valuable context beyond basic functionality. However, it doesn't mention performance characteristics like rate limits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, explanatory context, and a well-organized parameter section. Every sentence adds value without redundancy, and the information is appropriately front-loaded with the core functionality first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 3 parameters and no output schema, the description provides good coverage of what the tool does, parameter meanings, and security context. The main gap is lack of information about return format or what the retrieved rights look like, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains what 'user_id' represents ('ID of the user to query') and provides clear semantics for 'limit' and 'skip' parameters including their default values and purposes (pagination). This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('retrieves') and resource ('constrained delegation rights of a specific user within the domain'), making the purpose specific and unambiguous. It distinguishes from sibling tools like 'get_computer_constrained_delegation_rights' by specifying user-focused retrieval rather than computer-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'within the domain' and explaining what constrained delegation rights are, but it doesn't explicitly state when to use this tool versus alternatives like 'get_user_info' or other user-focused tools. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read operation ('Retrieves'), provides security context about controllers, and mentions the vulnerability identification purpose. However, it doesn't disclose potential limitations like rate limits, authentication requirements, error conditions, or what format the returned controllers will be in (though no output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, domain explanation, security context, and well-organized parameter documentation. Every sentence earns its place, and the information is front-loaded with the most important details first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 3 parameters and no output schema, the description provides strong coverage of purpose, parameters, and security context. The main gap is the lack of information about return format or structure, which would be helpful given no output schema exists. However, the description is otherwise quite complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear documentation for all three parameters: explains what 'template_id' represents, clarifies that 'limit' controls maximum return count with default, and describes 'skip' as pagination mechanism with default. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves'), the resource ('controllers of a specific Certificate Template'), and provides domain-specific context about what controllers are ('security principals that can modify the Certificate Template or its properties'). It explicitly distinguishes this tool from sibling tools like 'get_cert_template_info' by focusing on controllers rather than general template information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('critical for identifying ESC2 vulnerabilities') and implicitly distinguishes it from other tools by its specific focus on controllers. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for related queries, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the critical security implications ('can compromise the entire PKI infrastructure'), which helps the agent understand the tool's importance. However, it doesn't cover other behavioral traits like rate limits, authentication needs, or response format, leaving gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by critical security context, and then parameter details in a structured 'Args' section. Every sentence earns its place without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (security-focused tool with 3 parameters), no annotations, and no output schema, the description does well by covering purpose, security context, and parameter semantics. However, it lacks details on return values (e.g., what 'controllers' data looks like) and doesn't mention potential errors or constraints, leaving some gaps for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully. It does so by clearly explaining all three parameters: 'ca_id' as the ID to query, 'limit' for maximum results with a default, and 'skip' for pagination with a default. This adds essential meaning beyond the basic schema, making parameters well-understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('controllers of a specific Root Certificate Authority'), making the purpose specific. It distinguishes from siblings like 'get_root_ca_info' by focusing on controllers rather than general CA information, and it explicitly mentions the security context (ESC4/ESC5 attack paths), which adds unique value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by mentioning it's 'critical for identifying ESC4 and ESC5 attack paths,' which implies when to use it in security assessments. However, it doesn't explicitly state when not to use it or name alternatives (e.g., 'get_enterprise_ca_controllers' for different CA types), keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the search functionality and pagination behavior (default values for limit/skip), but doesn't mention performance characteristics, rate limits, authentication requirements, or what happens with invalid queries. It provides basic operational context but lacks deeper behavioral insights.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured with a clear purpose statement followed by well-organized parameter documentation. Every sentence earns its place, with no redundant information. The bullet-point format for object_type values enhances readability without wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters and no annotations/output schema, the description provides excellent parameter documentation and clear purpose. However, it doesn't describe the return format (what fields objects have, structure of results) or error conditions, which would be helpful given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides comprehensive parameter documentation that fully compensates. It explains each parameter's purpose, provides examples for 'query' and 'object_type', lists valid values for object_type, and specifies default values for limit and skip. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('search for objects') and resources ('BloodHound database'), and distinguishes it from siblings by focusing on name/ID-based searching rather than relationship analysis or specific object type queries. The opening sentence provides a complete functional statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('when you don't know their exact ID'), but doesn't explicitly mention when not to use it or name specific alternatives among the many sibling tools. The guidance is helpful but could be more comprehensive regarding tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers excellent behavioral transparency. It explains HTTP response code interpretation (200, 404, 400, 401/403, 5xx), clarifies that 404 is not an error, and describes authentication/permission issues. This goes well beyond basic functionality disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and front-loaded: purpose statement first, then behavioral details, then parameter explanations, then return value description. Every sentence earns its place with zero wasted words, making it highly efficient for agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and no output schema, the description provides complete context. It covers purpose, behavioral traits, parameter semantics, and return format. The HTTP response code explanation is particularly valuable for a database query tool, making this description self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters. It clarifies that 'query' is 'The Cypher query to execute' and 'include_properties' controls 'Whether to include node/edge properties in the response', adding crucial semantic meaning not present in the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Run a custom Cypher query') on a specific resource ('BloodHound Neo4j database'). It distinguishes itself from sibling tools like 'interpret_cypher_result' and 'search_graph' by focusing on raw query execution rather than interpretation or search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (running custom Cypher queries) and implicitly suggests alternatives through sibling tool names like 'search_graph' for simpler searches. However, it doesn't explicitly state when NOT to use this tool or provide direct comparisons with specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![bloodhound_mcp MCP server](https://glama.ai/mcp/servers/mwnickerson/bloodhound_mcp/badges/card.svg)](https://glama.ai/mcp/servers/mwnickerson/bloodhound_mcp)

Score Badge

Copy to your README.md:

[![bloodhound_mcp MCP server](https://glama.ai/mcp/servers/mwnickerson/bloodhound_mcp/badges/score.svg)](https://glama.ai/mcp/servers/mwnickerson/bloodhound_mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mwnickerson/bloodhound_mcp'

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