kegg-mcp-server

batch_entry_lookup

Read-onlyIdempotent

Fetch up to 50 KEGG entries in one request, with automatic chunking into groups of 10 to respect API limits. Use summary or full detail for mixed database IDs.

Instructions

Fetch multiple KEGG entries in bulk (max 50 IDs).

Automatically chunks requests into groups of 10 to respect KEGG's API limit.

Args: entry_ids: List of KEGG entry IDs (e.g. ['C00002', 'C00031', 'C00033']). Can mix databases. Max 50 entries. detail_level: 'summary' (default, compact per-entry projection) or 'full' (complete flat-file parse — sequences and GENES lists make this large for 50 entries at once).

Input Schema

Name	Required	Description	Default
`entry_ids`	Yes
`detail_level`	No		summary

Output Schema

Name	Required	Description	Default
`found`	Yes
`entries`	Yes
`requested`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.5.0Oct 23, 2026

addedInput schema / properties / detail_level

Added value: +{
+  "default": "summary",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "title": "Detail Level",
+  "type": "string"
+}

removedOutput schema / $defs

Removed value: -{
-  "BatchLookupResult": {
-    "properties": {
-      "entries": {
-        "items": {
-          "additionalProperties": true,
-          "type": "object"
-        },
-        "title": "Entries",
-        "type": "array"
-      },
-      "found": {
-        "title": "Found",
-        "type": "integer"
-      },
-      "requested": {
-        "items": {
-          "type": "string"
-        },
-        "title": "Requested",
-        "type": "array"
-      }
-    },
-    "required": [
-      "requested",
-      "found",
-      "entries"
-    ],
-    "title": "BatchLookupResult",
-    "type": "object"
-  },
-  "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"
-  }
-}

addedOutput schema / properties / entries

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  "title": "Entries",
+  "type": "array"
+}

addedOutput schema / properties / found

Added value: +{
+  "title": "Found",
+  "type": "integer"
+}

addedOutput schema / properties / requested

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Requested",
+  "type": "array"
+}

removedOutput schema / properties / result

Removed value: -{
-  "anyOf": [
-    {
-      "$ref": "#/$defs/BatchLookupResult"
-    },
-    {
-      "$ref": "#/$defs/ErrorResult"
-    }
-  ],
-  "title": "Result"
-}

changedOutput schema / required

Previous value: -[
-  "result"
-]New value: +[
+  "requested",
+  "found",
+  "entries"
+]

changedOutput schema / title

Previous value: -"batch_entry_lookupOutput"New value: +"BatchLookupResult"

First observedv0.1.0Jul 29, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and open-world status, so the description is not carrying the safety burden. It adds genuinely non-obvious behavior: the max-50 ceiling, automatic chunking into groups of 10 to respect KEGG's API limit, and a warning that 'full' output is large at batch scale. Partial-failure handling is still undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and limit before any detail, and the Args block is scannable. There is minor redundancy, since the 50-ID max is stated in the intro and again in the entry_ids arg, but nothing is bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shape needn't be explained, and the description covers scale limits, chunking, and detail tradeoffs. A bulk tool would ideally state what happens when some IDs are invalid, which is the one missing operational detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it largely does: entry_ids is explained with a concrete example, an allowance to mix databases, and the 50-entry cap; detail_level explains both enum values as 'compact per-entry projection' vs 'complete flat-file parse' with the size tradeoff. The remaining gap is format/validation expectations per ID.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (fetch multiple KEGG entries) plus the bulk scope and the 50-ID cap, so it is clearly distinguished from the single-entry siblings like get_compound_info. It never names those siblings explicitly, so the differentiation is implicit 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The detail_level explanation implies when to pick 'summary' vs 'full' (large GENES/sequence payloads at 50 entries), and the bulk framing implies use over single-entry lookups. But there is no explicit 'use X instead when...' routing, and no guidance on what to do with IDs that fail or span databases beyond 'can mix databases'.

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