get_orthologous_group

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the fundamental read-only nature implicitly ('Look up'), the return type (JSON string), and the content shape. It omits error behavior for malformed og_id, validation rules, and any rate/limit characteristics, leaving real gaps for a lookup tool with zero 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?

Purpose and content are front-loaded in the first two sentences, and the NumPy-style parameter/returns blocks are scannable. The Returns section restates what an existing output schema already carries, which is mild redundancy, but overall there is little waste.

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?

For a single-parameter lookup with an output schema present, the description covers purpose, input format with examples, and a return summary. The return-format block is largely redundant against the output schema, and error/validation behavior is absent, but nothing essential for calling the tool correctly is missing.

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 compensate, and it does thoroughly: it specifies the exact format ('family@taxid|level') and gives two concrete labeled examples with taxonomic level semantics (Opisthokonta A-1, Gnathostomata IM-18). This is meaningfully more than the bare 'Og Id' string title in the schema.

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 names a specific verb and resource ('Look up information for an orthologous group (OG) in eggNOG') and enumerates exactly what is retrieved: evolutionary origin, protein and species counts, KEGG KO/GO slim annotation, and same-family OGs. This lets an agent distinguish it from retrieval siblings like get_og_content or get_protein. However, it never explicitly contrasts itself with those siblings, so the differentiation is inferred from content rather than stated.

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?

Usage is implied by the content ('look up information for an OG'), which signals a detail-fetch against a known OG id. There is no explicit when-to-use versus get_og_content/get_orthologs/get_protein_family guidance and no stated preconditions, so the agent must infer routing from the sibling names alone.

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