Skip to main content
Glama
kegg-mcp-server

kegg-mcp-server

by Lucas-Servi

draw_pathway_map

Read-onlyIdempotent

Draw a KEGG pathway map as a PNG with gene boxes colored by highlight groups, redrawn from KGML layout, and return an exact summary of colored boxes and matched KOs.

Instructions

Draw a KEGG pathway map as a PNG image, with gene boxes coloured by group.

The map is redrawn from KEGG's KGML layout (gene boxes, compounds, reactions and links to other maps), not copied from KEGG's image. Each gene box is split into one stripe per highlight group: coloured when the group has one of the box's KOs, grey when it doesn't. Returns the PNG plus an exact summary of what the image shows (per group: map KOs found and boxes coloured; per box: KOs and the groups that have them), so check the summary rather than describing the picture from memory.

Args: pathway_id: KEGG map number: 'map00010', 'ko00010', an organism map such as 'eco00010' (drawn as the KO reference map), or '00010'. Global and overview maps (011xx, 012xx) are refused. highlight: Optional {label: ids}, at most 8 groups (e.g. one per genome). Ids are KO ids ('K00844', 'ko:K00844', 'KEGG:K00844') or complete EC numbers ('2.7.1.1', 'EC:2.7.1.1'). One item may hold one gene's ids separated by spaces ('K00845 EC:2.7.1.2', or a GenBank db_xref string). A KO with no KO match is coloured through EC numbers only when one item carries every EC KEGG links to it; those KOs are listed under matched_by_ec.

Input Schema

NameRequiredDescriptionDefault
highlightNo
pathway_idYes

Output Schema

NameRequiredDescriptionDefault
urlYes
boxesNo
notesNo
stepsNo
titleYes
groupsNo
box_countYes
pathway_idYes
step_countNo
image_widthYes
image_heightYes
map_ko_countYes
boxes_truncatedNo
steps_truncatedNo
unrecognized_idsNo
boxes_with_any_groupNo
steps_with_any_groupNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioural context beyond them: how stripes are assigned per group, that non-matching boxes are grey, that the return includes a PNG plus a structured summary, and that the summary is authoritative over visual inspection. The refusal of 011xx/012xx maps is a concrete constraint an agent could not infer.

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 the outcome (PNG) and the key differentiator (redrawn from KGML), then structured Args covering each parameter. Dense but nearly every sentence carries decision-relevant information; the EC-matching sentence is the most convoluted and could be tightened without losing meaning.

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

Completeness5/5

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

An output schema exists, yet the description still explains that the return is a PNG plus a per-group/per-box summary and tells the agent how to use it. Combined with full parameter documentation and the map-type restriction, an agent has everything needed to call this correctly on the first attempt.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does so thoroughly: pathway_id accepts 'map00010', 'ko00010', organism maps like 'eco00010', or bare '00010'; highlight is a {label: ids} map of at most 8 groups whose ids may be KO ids in three prefixes or EC numbers in two forms, with space-separated multi-id items and a documented EC fallback via matched_by_ec. This far exceeds what the bare schema conveys.

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

Purpose5/5

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

States a specific verb and resource ('Draw a KEGG pathway map as a PNG image') and adds the distinguishing implementation detail that the map is redrawn from KGML layout rather than copied from KEGG's image. This clearly separates it from the sibling render_pathway_ascii and the various get_pathway_* retrieval tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Gives concrete inclusion/exclusion rules: global and overview maps (011xx, 012xx) are refused, and the highlight groups are capped at 8 (e.g. one per genome). It also instructs the agent to check the returned summary rather than describing the picture from memory. It stops short of explicitly naming render_pathway_ascii as the text alternative, so routing between the two renderers is left implicit.

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