BloodHound MCP Server

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.

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.

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.

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.

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.

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.