Get director network

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: the tool returns all connected companies up to specified depth, includes specific fields for each company, and mentions that depth 2 'can return many results for large companies.' However, it doesn't cover rate limits, authentication needs, or potential performance implications beyond the depth warning.

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 efficiently structured in three sentences: first states purpose and scope, second describes output format, third provides usage context. Every sentence adds value with zero waste. 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.

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

Given the tool's moderate complexity (network traversal), no annotations, and no output schema, the description does well but has gaps. It explains what the tool does, when to use it, and output format at a high level, but doesn't detail the exact structure of returned data or potential limitations beyond depth considerations. For a network analysis tool without output schema, more detail on result format would be helpful.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds marginal value by mentioning 'up to the specified depth' and the traversal concept, but doesn't provide additional syntax or format details beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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: mapping corporate networks via shared directors for UK companies. It specifies the verb ('Map'), resource ('corporate network'), scope ('connected to a UK company via shared directors'), and distinguishes from siblings like get_company (single company) or get_directors (directors of one company).

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 clear context for when to use this tool: 'identifying corporate group structures, related party relationships, and director interlocks.' It doesn't explicitly state when not to use it or name alternatives among siblings, but the context strongly implies this is for network analysis rather than retrieving individual company or director data.

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