homology"What's the mouse / rat / zebrafish ortholog of [human gene]" / "ortholog of [gene] in [species]" / "homologs of [gene]" — orthologs and paralogs for a gene across species. Use for cross-species comparison, model organism work, evolutionary analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| species | Yes | ||
| symbol_or_id | Yes | ||
| target_species | No |
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Homology records |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {
+ "species": "human",
+ "symbol_or_id": "BRAF",
+ "target_species": "mus_musculus"
+ },
+ {
+ "species": "human",
+ "symbol_or_id": "ENSG00000157764",
+ "target_species": "danio_rerio"
+ }
+]Output schema / (root)Previous value: -nullNew value: +{
+ "description": "Homology mappings for a gene",
+ "properties": {
+ "data": {
+ "description": "Homology records",
+ "items": {
+ "properties": {
+ "homologies": {
+ "description": "Homologous genes",
+ "items": {
+ "properties": {
+ "id": {
+ "description": "Homolog ID",
+ "type": "string"
+ },
+ "perc_id": {
+ "description": "Percent identity",
+ "type": "number"
+ },
+ "perc_pos": {
+ "description": "Percent positives",
+ "type": "number"
+ },
+ "species": {
+ "description": "Target species",
+ "type": "string"
+ },
+ "type": {
+ "description": "Homology type (ortholog/paralog)",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "id": {
+ "description": "Query gene ID",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds that the tool returns both orthologs and paralogs, which clarifies the output type but does not elaborate on behavior like supported species or no-match handling. Given the annotations, this is adequate but not rich.
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 example queries, immediately conveying the tool's purpose. The second sentence adds use-case context without unnecessary elaboration. No wasted words.
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?
The tool has a simple input schema and an output schema (indicated in context), so the description mainly needs to convey purpose and use cases, which it does. It covers key scenarios like model organism work and evolution. However, it could mention what happens when target_species is omitted, but the schema's optionality handles that. Overall, sufficient for a query 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?
The input schema has three parameters with 0% coverage in the description. The examples illustrate usage with species, symbol_or_id, and target_species, but the description itself does not define each parameter's meaning or whether target_species is optional. More explicit parameter descriptions would be needed to compensate for the lack of schema descriptions.
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 it returns orthologs and paralogs for a gene across species, with specific example queries that show the tool's scope. This distinguishes it from sibling tools like lookup or sequence, which focus on different biological data. The mention of cross-species comparison and evolutionary analysis further clarifies its purpose.
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 explicitly says 'Use for cross-species comparison, model organism work, evolutionary analysis,' which provides clear context for when to select this tool. However, it does not mention exclusions or alternative tools, so it stops short of the highest score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
There is heavy overlap in the ask_pipeworx family (ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, bet_research, validate_claim) — several are near-identical 'route a natural-language question to a source' tools differing only by small qualifiers. ai_visibility_check vs scan_competitor_ai_presence and entity_profile vs compare_entities vs recent_changes also blur together. An agent could easily misselect among these.
The dominant convention is snake_case verb_noun/noun_verb (list_subscriptions, scan_dependency, validate_claim, resolve_entity) which is fairly consistent, but there are several bare single-word verbs (lookup, sequence, variation, vep, xrefs, recall, remember, forget) that break the pattern. No camelCase is present, so the inconsistency is minor rather than chaotic.
38 tools is heavy, and the overwhelming majority (~31) are Pipeworx meta-tools (subscriptions, memory, feedback, trend, discovery, llms.txt generation) that have nothing to do with the server's declared Ensembl identity. Only about 7 tools are actually genomics-related, so the count is inflated by off-domain additions that dilute the surface.
For the Ensembl domain, the surface covers gene lookup, symbol resolution, sequence retrieval, orthologs, SNPs, variant effect prediction, and xrefs — but misses major Ensembl capabilities like gene trees/families, regulatory features, comparative/multi-species alignments, expression data, phenotypes, GO/ontology annotations, and region/overlap queries. Conversely the Pipeworx tools are complete for their own domain but irrelevant here, leaving the declared domain notably incomplete.