BloodHound MCP Server

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.

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.

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.

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.

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.

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.