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

Without annotations, the description must carry the burden of behavioral disclosure. It mentions the purpose but does not disclose any behavioral limitations, such as whether the search is exact or fuzzy, what happens if no insider is found, or if the query is case-sensitive. The description does not contradict annotations (none provided), but it under-discloses.

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 concise and front-loaded with the purpose, then lists what information is available (transactions, affiliations, performance). It is efficient without waste, though it could be slightly more structured for readability.

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 has one parameter and no output schema, the description is moderately complete. It tells the agent what to input and what it returns, but it lacks details on edge cases, such as how the 'slug' works or how to handle ambiguous names. It also does not mention potential errors or limitations, which would help an agent decide if this is the right tool.

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 coverage is 100%, so the query parameter is fully described in the schema. The description adds context that the query can be either an ID or name, which adds some meaning beyond the schema's 'search', but it does not add syntax or format details. Baseline 3 is appropriate.

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 states a clear purpose: to look up a European corporate insider by ID or name and view their disclosed transactions, affiliations, and performance. It effectively distinguishes itself from sibling tools like get_cluster_buys and get_recent_filings by focusing on a specific insider entity.

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 implies that this tool is used when you need information on a specific insider, but it does not explicitly state when to use it versus alternatives like get_cluster_buys. It lacks explicit 'when not to use' guidance, which is a gap given the sibling tools could be alternatives.

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