JADX-MCP-SERVER

Overview Schema Source Related Servers Discussions Admin

add_comment

Add persistent comments to decompiled classes, methods, fields, or source lines in JADX-GUI to document reverse-engineering findings and make annotations searchable later.

Instructions

Add a comment to decompiled code, shown in JADX-GUI and saved with the project.

Comment a class by passing only class_name, a method by also passing method_name (use method_signature such as '(I)V' to pick between overloads), or a field by passing field_name.

To comment a code line, pass line=N, the 1-based line number in the decompiled source of that class; get it from get_class_source(with_line_numbers=True) rather than counting lines. The comment is appended to the end of that line, and on a class, method or field declaration line it comments that declaration instead, matching what the comment shortcut does in JADX-GUI. Braces and blank lines have nothing to comment and are rejected, listing the nearest lines that work. Line numbers shift once a comment is added above, so re-read the source before addressing another line.

Every write is verified against the freshly decompiled code and the response echoes the rendered line, so there is no need to read the class back to check. A comment that does not render is rolled back and returns an error rather than being silently stored, which JADX itself does not detect.

A new comment on the same target replaces the previous one, so annotations can be refined without creating duplicates, and passing an empty comment removes it. style is one of LINE, BLOCK, BLOCK_CONDENSED, JAVADOC or JAVADOC_CONDENSED (default: LINE).

Use this to record what a class or method actually does while reverse engineering: the comments persist in the JADX project and are searchable later with search_classes_by_keyword(search_in="comment").

Input Schema

Name	Required	Default
`line`	No
`style`	No	LINE
`comment`	Yes
`class_name`	Yes
`field_name`	No
`method_name`	No
`method_signature`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: comments persist in the JADX project, every write is verified against freshly decompiled code, failed renderings are rolled back, new comments replace old ones, and empty comments remove them. It also discloses line-number shifting and rejection of braces/blank lines.

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

Conciseness5/5

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

Despite its length, the description is organized into focused paragraphs covering target selection, line behavior, verification, replacement semantics, style, and purpose. Every sentence conveys operational information needed for correct invocation.

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?

For a 7-parameter mutation tool with no annotations and no schema descriptions, the description is complete: it covers all targeting modes, line-number handling, verification/rollback, replacement/removal behavior, and style choices. The presence of an output schema means return-format details need not be fully explained.

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 must compensate, and it does. It explains class_name, method_name, method_signature for overloads, field_name, line as a 1-based decompiled source line, comment, and style with its five values and LINE default.

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?

The description opens with a specific verb and resource: 'Add a comment to decompiled code.' It immediately distinguishes class, method, field, and line targets, so an agent can understand the tool's scope without inspecting the schema.

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

Usage Guidelines5/5

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

It gives explicit targeting rules: pass only class_name for a class, also method_name for a method, field_name for a field, or line=N for a code line. It also tells the agent to obtain line numbers from get_class_source(with_line_numbers=True) rather than counting manually, and explains the intended reverse-engineering use case.

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