expression_atlas_gene

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

With no annotations provided, the description carries the full behavioral disclosure burden. It transparently says the public REST API no longer exposes numeric per-gene values and that results are experiments matching the gene's description/species. This is a substantive, honest limitation disclosure that goes well beyond the schema.

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 English portion is concise and front-loaded, but the Chinese section repeats much of the same information without adding new guidance. Phrases like '此处诚实返回相关实验' are more rhetorical than operational, adding noise for an agent deciding when to call the tool.

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 that an output schema exists and there are only two simple parameters, the description is largely complete for invocation: it identifies inputs, the matching behavior, and the key limitation. It could be stronger with an explicit pointer to expression_atlas_experiment or matching semantics, but nothing essential for a basic call 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 coverage is 0%, so the description must compensate for the two undocumented parameters. It adds real meaning to gene_id by specifying that it accepts a gene ID or symbol with concrete examples TP53 and ENSG00000141510. It also notes species is optional, though it does not describe acceptable species values beyond relying on the schema default.

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 specific action and resource: 'Find Expression Atlas experiments relevant to a gene.' It clearly names gene identifiers and species as inputs, and differentiates this from numeric expression retrieval by explaining the REST limitation. It does not explicitly name or contrast the sibling expression_atlas_experiment tool, so it stops short of full sibling differentiation.

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 gives useful usage context: it is for finding experiments where a gene's expression can be viewed, and it notes that numeric per-gene expression values are not returned. However, it does not name any alternative tool for numeric values or experiment metadata, nor does it say when not to use this tool beyond the numeric limitation.

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