operations_info

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

The description explicitly states 'read-only,' which reveals the non-mutating nature of the tool, and it notes parameter prerequisites for specific info types. However, it does not disclose output structure, error behavior, response format, or any rate limits or permission requirements. Since annotations are absent, the description carries the full burden, and this level of detail is adequate but not rich.

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

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

The description is front-loaded with a one-sentence purpose, then uses compact bullet-like lines to list info_type options and args. Each line earns its place, and there is minimal fluff. Some redundancy exists (e.g., 'get' repeated), but overall it is well-structured and not overly long.

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

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

The description covers all parameters and options, but it lacks details on return values or error handling. Since there is no output schema, the description would need to describe what each info_type returns to be fully complete. As it stands, an agent knows what to query but not what response to expect.

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

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

The input schema provides no descriptions (0% coverage), but the description fully explains every parameter: info_type lists valid options and default, domain_id is tied to meta_nodes/meta_tree, and object_id to meta_entity. This goes well beyond the schema and gives the agent all the needed semantic information.

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

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

The description opens with a specific verb and resource: 'Query read-only BloodHound Enterprise operational status and meta data.' It then enumerates distinct info_type options, each with a clear purpose, making it obvious what the tool does and differentiating it from sibling tools that focus on entity information (e.g., domain_info, entity_info).

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 tool provides clear context for when to use it—'read-only operational status and meta data'—and details the available info_type options with their required parameters (e.g., 'requires: domain_id' for meta_nodes). It does not mention exclusions or alternative tools, but the context is sufficient for an agent to decide when to invoke it.

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