Get Author

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

With readOnly/idempotent/openWorld annotations already covering safety, the description adds real beyond-schema context: the affiliation field can be stale so employment must not be inferred, view='context' drops the nested author record and swaps numeric impact_clusters for impact_directions, server collections cap at 100, and neighbor computation adds significant latency. This is exactly the operational nuance an agent needs.

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?

Front-loads the purpose, then the data-quality caveat, then a clearly enumerated view section, then the neighbor flag. Every block is structured and earns its place; it is slightly long but the length is justified by the two response shapes it must disambiguate.

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?

An output schema exists so return values need not be re-explained, and the description still covers the response-shape differences, caps, and latency. It is complete for correct invocation, missing only explicit sibling routing, which is minor given the output schema and annotations.

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 0%, so the description must carry the parameters and it largely does: it enumerates both view enum values with distinct semantics and explains what include_neighbors adds along with its latency cost. Only author_id_or_url goes undocumented, but its meaning is self-evident.

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?

States a specific verb and resource ('Fetch agent-oriented context for a Lacuna author') and clarifies via the view section that it returns an aggregate context (papers plus impact_directions). However, it never explicitly distinguishes itself from siblings like get_author_papers, get_author_directions, or get_author_neighbors, leaving the agent to infer that this is the composite entry point.

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?

Provides implied guidance by marking view='context' as 'recommended' and explaining what each mode does. But there is no explicit when-to-use-this-vs-alternatives statement, e.g. when to call get_author_context rather than get_author_papers or get_author_neighbors, which is exactly the ambiguity an agent faces with these siblings.

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