Retrieve KEGG Orthology entries and cross-organism orthologs for a given KEGG gene ID to compare gene function across organisms.
Get KO (KEGG Orthology) entries and cross-organism orthologs for a gene.
Args: gene_id: KEGG gene ID (e.g. 'hsa:1956').
| Name | Required | Description | Default |
|---|---|---|---|
| gene_id | Yes |
Changes observed during successful MCP inspections.
v0.5.0Output schema / (root)Previous value: -{
- "$defs": {
- "ErrorResult": {
- "description": "Structured error returned by a tool when the KEGG API fails.\n\nA tool returns this instead of raising so the model can reason about\nthe failure and decide whether to retry, change inputs, or give up.\nA point lookup that receives a 404 uses code ``not_found``; an empty search\nremains a successful result with no items.",
- "properties": {
- "code": {
- "default": "kegg_api_error",
- "title": "Code",
- "type": "string"
- },
- "error": {
- "title": "Error",
- "type": "string"
- },
- "hint": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "title": "Hint"
- },
- "path": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "title": "Path"
- },
- "retryable": {
- "default": false,
- "title": "Retryable",
- "type": "boolean"
- },
- "status": {
- "anyOf": [
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "title": "Status"
- }
- },
- "required": [
- "error"
- ],
- "title": "ErrorResult",
- "type": "object"
- }
- },
- "properties": {
- "result": {
- "anyOf": [
- {
- "additionalProperties": true,
- "type": "object"
- },
- {
- "$ref": "#/$defs/ErrorResult"
- }
- ],
- "title": "Result"
- }
- },
- "required": [
- "result"
- ],
- "title": "get_gene_orthologsOutput",
- "type": "object"
-}New value: +nullv0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, covering most of the behavioral profile. The description adds nothing beyond that: no indication of result shape, whether orthologs come from all organisms, or whether lookups hit a remote service with latency limits.
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?
One sentence of purpose plus a single argument line, front-loaded and free of filler. The Args block is a bit ceremonial for one parameter but the example earns its place.
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?
With no output schema, the description should say more about what comes back — the split between KO assignments and ortholog records, and whether orthologs are grouped by organism. A single-param read tool is simple, so this is adequate but incomplete.
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% and the schema only says 'Gene Id' with no type guidance, so the description's concrete format example ('hsa:1956') is genuinely load-bearing. It doesn't state the accepted ID namespaces beyond the one example, which keeps it from a 5.
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 (Get) and two specific resources (KO entries and cross-organism orthologs) scoped to a gene, which clearly separates it from get_gene_info and search_ko_entries. It doesn't explicitly name the sibling it replaces, so it stops short of 5.
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?
There is no when-to-use guidance, no mention of when to prefer get_gene_info or get_ko_info instead, and no prerequisites or organism-scope caveats. Only the argument is documented, leaving the agent to infer selection from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.