idamesh MCP server

Read from the package source without running it. The installed server may list more.

• add_bookmark

  Add a marked position (bookmark) at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first. ``description`` is the label shown for the mark. When the address is already bookmarked its slot is reused and the description updated. The result reports the resolved ``address`` (``0x`` hex), the ``slot`` the mark occupies, and ``ok``

• analyze_component

  Analyze a *component* — the call-subtree rooted at one function — as a single unit. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved to the root function. ``depth`` bounds how many call layers below the root are pulled in (clamped to a server maximum). Each reached function is returned as a ``members`` entry with its ``address``, ``name``,

• analyze_function

  Return a composite report for the function at or containing ``address``, assembled in one call from what an analyst would otherwise fetch tool-by-tool. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved and mapped to its owning function first. The report bundles the function's ``name`` and compact ``profile`` (byte ``size``, control-flow blo

• apply_annotations

  Apply a previously exported (or merged) annotation record into this database. ``record`` is an annotation document in the shape ``export_annotations`` returns — ``provenance`` plus ``names`` / ``comments`` / ``prototypes`` entry lists. Each item is written best-effort: an item the database refuses (a bad identifier, an unparsable prototype, a function comment at a non-function address) is collecte

• basic_blocks

  List the control-flow basic blocks of the function at or containing ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved and mapped to its owning function first. Each block reports its ``start`` and ``end`` (a half-open span) and the ``successors`` it may branch to, as their start addresses. The reply is capped at a server maximum

• callees

  List the functions directly called by the function at or containing ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved and mapped to its owning function first. Each callee is reported once, with its entry ``addr`` and ``name``. An out-of-range or unresolvable address, or one that lies in no function, yields an error result rathe

• callgraph

  Return the call graph rooted at the function at or containing ``address``, explored breadth-first. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved and mapped to its owning function first. ``depth`` bounds how many call layers are explored and is clamped to a server maximum. The result reports the ``root`` address, the ``nodes`` reached (e

• declare_stack

  Define a stack-frame variable on a function. The ``function`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved to the owning function's entry. ``name`` and ``type`` give the new frame variable its name and C type; ``offset`` is the signed frame offset it occupies. The result reports the resolved ``function`` (``0x`` hex), the variable ``name``, and ``ok``

• declare_type

  Install C type declaration(s) into the local type library. The ``declaration`` is C source that may contain one or more type declarations (``struct``, ``union``, ``enum``, ``typedef``, …), parsed against the local type library. The result reports ``ok``, the ``count`` of types added, and their ``names``. This modifies the database. Source that fails to parse yields an error result rather than fail

• decompile

  Return Hex-Rays pseudocode for the function at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved to a function entry before decompiling. The result carries the joined ``pseudocode`` text plus the individual source ``lines``. If no decompiler is available, or the address is not within a function, the call returns an error result

• define_codewrite action

  Create an instruction at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first and should point at the first byte of the intended instruction. The analyzer decodes one instruction and infers its length. The result reports the resolved ``address`` (``0x`` hex), ``ok``, and the ``size`` in bytes the new instruction occupies. Th

• define_funcwrite action

  Create a function at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first, and should point at the entry instruction of the intended function. The analyzer infers the function's end. The result reports the resolved ``address`` (``0x`` hex), ``ok``, and the new function's ``name`` (null when it is unnamed). This modifies the

• delete_stackwrite action

  Remove a stack-frame variable from a function. The ``function`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved to the owning function's entry. ``name`` is the frame variable to remove. The result reports the resolved ``function`` (``0x`` hex), the variable ``name``, and ``ok``. This modifies the database and destroys the existing frame variable. A name

• detect_stack_strings

  Detect strings assembled on the stack byte-by-byte via immediate stores.

• detect_vulns

  Scan for common vulnerability patterns with explainable heuristics.

• disasm

  Return a bounded linear disassembly starting at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved to the first instruction listed. ``count`` bounds how many instructions are rendered and is clamped to a server maximum. Each row carries its ``addr``, the opcode ``bytes`` as a hex string, and the rendered instruction ``text``. Th

• entity_query

  Search the database's named entities — functions, named globals, and imported symbols — as one filtered stream. ``query`` matches a case-insensitive substring of each entity's name (empty matches all). ``kind`` restricts the search to one entity kind (``"function"`` / ``"global"`` / ``"import"``) or spans all three when ``"any"``. ``limit`` caps how many matches are returned (clamped to a server m

• enum_upsertwrite action

  Create or update an enumeration type without destroying its existing members. ``name`` is the enum type name; ``members`` is an object mapping each member name to its integer value. The enum is created when missing; each supplied member is added when absent or updated when its value changed, while members already present and not listed are preserved. The result reports the enum ``name``, ``ok``, a

• export_annotations

  Export this database's user annotations as a portable record. Returns the user names, line/function comments, and (when ``include_types``) prototypes the user set, each keyed by effective address, plus a ``provenance`` block (input path, SHA-256, imagebase, IDA version) that identifies the binary. ``funcs`` optionally restricts the export to the given functions — each a hex literal (``0x…``), deci

• export_funcs

  Export the database's functions as a compact bulk list suitable for feeding into other tools. ``offset`` skips that many functions from the start; ``count`` caps how many are returned (clamped to a server maximum). Each row carries just the function ``name`` and its entry ``address`` (``0x`` hex). The result carries the ``total`` function count and a ``truncated`` flag, plus a ``next_cursor`` when

• find_bytes

  Search the loaded image for a byte ``pattern`` and return the addresses where it matches. ``pattern`` is an IDA-style hexadecimal byte pattern that may contain wildcards — for example ``"48 8B ?? 05"``, where ``??`` (or ``?``) matches any byte. ``limit`` caps how many matches are returned (clamped to a server maximum). The result echoes the ``pattern`` and lists each match's ``address`` as ``0x``

• find_crypto

  Identify cryptography in the loaded image by its constant signatures.

• find_dangerous_callers

  List the dangerous imported APIs the image calls and where it calls them.

• find_regex

  Search the strings IDA extracted from the binary for those whose value matches a Python regular expression. ``pattern`` is applied with ``re.search`` against each string's decoded value. ``limit`` caps how many matches are returned (clamped to a server maximum). The result echoes the ``pattern`` and lists each match's ``address`` (``0x`` hex) and matching ``value``, with ``truncated`` set when the

• force_recompile

  Invalidate the decompiler cache for the function at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first and mapped to its enclosing function. The stale cached pseudocode is dropped so the next ``decompile`` regenerates fresh output after type, rename, operand, or data edits. The result reports the resolved ``address`` (``0x

• func_profile

  Return a compact summary of the function at or containing ``address``, without decompiling it. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved and mapped to its owning function first. The summary reports the function's ``address`` and ``name``, its byte ``size``, its control-flow ``block_count`` and ``edge_count``, and its call degree — `

• func_query

  Filter the database's functions by a conjunction of predicates. ``name`` matches a case-insensitive substring of the function name (empty matches all). ``min_size`` and ``max_size`` bound the function's byte size inclusively; a ``max_size`` of ``0`` leaves the upper end unbounded. ``is_library`` and ``is_thunk`` are tri-state — omit (null) to ignore the flag, or pass ``true`` / ``false`` to requir

• get_bytes

  Read ``size`` raw bytes starting at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved to the start of the region first. The result echoes the resolved ``address`` (``0x`` hex) and ``size``, and returns the ``bytes`` as a lowercase hex string. An out-of-range or unresolvable address, or an unreadable region, yields an error resu

• get_global_value

  Read the value of a named global as an integer. ``name`` may be a symbol name or an address (hexadecimal or decimal); it is resolved to the global first. ``size`` bytes are read and decoded under the database's byte order and, when ``signed`` is true, as a two's-complement value — exactly as ``get_int`` does. The result echoes the resolved ``name`` and ``address`` (``0x`` hex), the ``size`` and ``

• get_int

  Read an integer of ``size`` bytes at ``address`` and decode it. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first. The bytes are interpreted under the database's byte order and, when ``signed`` is true, as a two's-complement value. The result reports the resolved ``address`` (``0x`` hex), the ``size`` and ``signed`` interpretation, th

• get_metadata

  Describe the loaded database: input file identity, processor and bitness, byte order, entry point and image base, and coarse counts of functions and segments. Call this first to orient on an unfamiliar target before enumerating or decompiling anything.

• get_string

  Read a string starting at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first. At most ``max_length`` bytes are scanned, auto-detecting the terminator and encoding. The result reports the resolved ``address`` (``0x`` hex), the decoded ``value``, and its byte ``length``. An out-of-range or unresolvable address, or the absenc

• idb_snapshot

  Save a compressed ``.i64`` snapshot of this database to ``path``. Writes a compressed copy to the given destination without disturbing the live database or its loose working files, so a session stays open and editable after the snapshot. The result reports the destination ``path``, ``ok``, and the written file ``size`` in bytes. This writes a file (but does not modify the open database). A destina

• imports

  List the module's imported symbols as a bounded page grouped by their originating library. ``offset`` skips that many imports from the start; ``count`` caps how many are returned (clamped to a server maximum). Each row carries the symbol name, its import-table address, the module it is drawn from, and its ordinal when the platform links by ordinal. The result carries the total count and a ``trunca

• imports_query

  Filter the module's imported symbols. ``name`` matches a case-insensitive substring of the imported symbol name and ``module`` a case-insensitive substring of the originating library; either empty leaves that axis unfiltered, and the two combine as a conjunction. ``limit`` caps how many matches are returned (clamped to a server maximum). Each match carries the symbol ``name``, its import-table ``a

• insn_query

  Filter the decoded instructions of the function at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved to the containing function, which is decoded and scanned. ``mnemonic`` requires an exact (case-insensitive) mnemonic when non-empty. ``operand_kind`` requires the instruction to carry at least one operand of that kind (``"reg"``

• int_convert

  Reinterpret an integer ``value`` across every representation at a given bit width. ``value`` may be written in hexadecimal (``0x…``), binary (``0b…``), octal (``0o…``), plain decimal, or as a quoted character literal (``'A'``), with an optional leading sign. ``bits`` sets the width the unsigned and two's-complement ``signed`` views are computed at. The result reports the ``decimal`` value, its ``u

• list_funcs

  List the database's functions in address order as a bounded page. ``offset`` skips that many functions from the start; ``count`` caps how many are returned (clamped to a server maximum). The result carries the total function count and a ``truncated`` flag so a caller can page through the whole set.

• list_globals

  List the database's named global (data) symbols in address order as a bounded page. ``offset`` skips that many globals from the start; ``count`` caps how many are returned (clamped to a server maximum). Each row carries the symbol name, its address, item size in bytes, and its declared type when known. The result carries the total count and a ``truncated`` flag so a caller can page through the who

• list_strings

  List the strings IDA extracted from the binary as a bounded page in address order. ``offset`` skips that many strings from the start; ``count`` caps how many are returned (clamped to a server maximum). Each row carries the string's ``address`` (``0x`` hex), its byte ``length``, its encoding ``type`` (for example a C/ASCII or a Unicode string), and its decoded ``value``. The result carries the tota

• lookup_funcs

  Find functions whose name contains ``query`` (case-insensitive). ``limit`` caps how many matches are returned (clamped to a server maximum). The result echoes the ``query`` and lists each match's function ``name`` and entry ``address`` (``0x`` hex), with ``truncated`` set when the cap elided further matches. Read-only.

• make_data

  Define a data item at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first. Supply a C ``type`` declaration (e.g. ``"int"`` or ``"char[16]"``) to define a typed item sized to that type; otherwise supply a ``size`` in bytes (1/2/4/8 → byte/word/dword/qword) to define a primitive item. At least one of ``type`` or ``size`` must

• patchwrite action

  Overwrite the raw bytes at ``address`` with ``bytes``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first. ``bytes`` is the replacement data as a hexadecimal string, with whitespace between octets tolerated (``"90 90"`` and ``"9090"`` are equivalent). The result reports the resolved ``address`` (``0x`` hex), the ``size`` in bytes writt

• patch_asmwrite action

  Assemble the single instruction ``assembly`` and patch it at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first. ``assembly`` is one line in the database architecture's syntax (e.g. ``"jmp 0x401000"`` or ``"nop"``), encoded by IDA's native assembler as if placed at the resolved address and written there. The result reports

• read_struct

  Interpret the memory at ``address`` as the aggregate type named ``struct``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first. The struct's field layout drives the decode: primitive fields (1/2/4/8-byte int, char, or pointer) are rendered as an integer/hex ``value`` under the database's byte order, while larger, aggregate, or array fi

• register
• rename

  Set the user name of the item at ``address`` to ``name``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first, and may point at a function or a data item. The result reports the resolved ``address`` (``0x`` hex), the ``old_name`` that was in force beforehand, the new ``name``, and ``ok``. This modifies the database. An empty or invalid

• search_structs

  Search the database's aggregate (struct and union) types for those whose name contains ``query`` (case-insensitive); an empty ``query`` lists every struct/union. ``limit`` caps how many matches are returned (clamped to a server maximum). The result echoes the ``query`` and lists each match's ``name``, total byte ``size``, and ``member_count``, with ``truncated`` set when the cap elided further mat

• search_text

  Search the rendered disassembly listing for a substring. Each defined item's line is rendered to plain text (control tags stripped) and tested for a case-insensitive match against ``text``. ``limit`` caps how many matches are returned (clamped to a server maximum). The result echoes the query ``text`` and lists each match's ``address`` (``0x`` hex) and the matching ``line``, with ``truncated`` set

• server_health

  Report server liveness and whether a database is currently bound and ready to serve reads, along with the server version and the MCP protocol revisions this endpoint can negotiate. Safe to poll at any time.

• set_comment

  Attach ``comment`` at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first. By default the text is written as the item comment at that address; set ``function`` to route it to the enclosing function's comment instead, and set ``repeatable`` to use the repeatable slot (echoed at every cross-reference) rather than the anchored

• set_op_type

  Set the display representation of an instruction operand. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first and should point at an instruction. ``operand`` is the zero-based operand index. ``type`` names the representation to apply — a numeric base (``"hex"``, ``"dec"``, ``"oct"``, ``"bin"``, ``"char"``) or ``"offset"``. The result re

• set_type

  Apply the C declaration ``type`` to the function or data item at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first. ``type`` is a C declaration or function prototype (e.g. ``int f(char *)`` or ``unsigned int``) parsed against the local type library and applied at the address. The result reports the resolved ``address`` (`

• survey_binary

  Return a one-call triage overview of the whole database, so an agent need not fan out to ``list_funcs`` / ``imports`` / ``list_strings`` separately to orient. The overview bundles the database ``metadata``, coarse ``counts`` (functions, imports, strings, segments), the ``entrypoints``, a ``roles`` histogram over an authored function-role taxonomy (``thunk`` / ``library`` / ``small-leaf`` / ``leaf`

• trace_data_flow

  Trace the value at an instruction operand through one function, bounded.

• trace_source_to_sink

  Find intra-procedural taint paths from input sources to dangerous sinks.

• type_inspect

  Inspect the definition of the type named ``name`` from the database's local type catalog. The result reports the type's ``name``, its coarse ``kind`` (e.g. struct / union / enum / typedef / pointer), its byte ``size``, and its ``members`` — one row per field with the member ``name``, rendered ``type``, byte ``offset`` from the start of the aggregate, and member ``size``. ``members`` is empty for n

• type_query

  Search the database's local type catalog for named types whose name contains ``query`` (case-insensitive); an empty ``query`` lists every named type. ``limit`` caps how many matches are returned (clamped to a server maximum). The result echoes the ``query`` and lists each match's ``name``, its coarse ``kind`` (e.g. struct / union / enum / typedef / pointer), and its byte ``size``, with ``truncated

• undefine

  Undefine the item at ``address``, reverting it to raw bytes. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved first. The function, code, or data definition covering the address is discarded. The result reports the resolved ``address`` (``0x`` hex) and ``ok``. This modifies the database and destroys the existing definition at the address. A

• xref_query

  Query the cross-references around ``address`` with kind/type filters. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved to a concrete anchor first. ``direction`` is ``"to"`` (edges pointing at the anchor) or ``"from"`` (the call edges leaving the function that owns it). ``kind`` filters on ``"code"`` / ``"data"`` and ``type`` on ``"call"``

• xrefs_to

  List the cross-references that point at ``address``. The ``address`` may be a hexadecimal literal (``0x…``), a decimal literal, or a symbol name; it is resolved to a concrete target first. Each edge carries the referring ``from`` address, the enclosing ``func`` name when the source is inside a function, the ``kind`` (``code``/``data``), and the finer ``type`` (``call``/``jump``/``read``/``write``/

• Code scan348 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 63 days ago12/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

88/100

higher than 75% of 48,255 servers

Tools

61

the typical server has 7

Tools that change things

10%

typical: 0%. Fewer write tools means less an agent can break

GitHub stars

1

more than 65% of 28,688 servers

Downloads a week

23

more than 9% of 12,191 servers with a package

idamesh: common questions

Is idamesh MCP server safe?

Yes, by our scan: it is graded A (88/100). Read the idamesh safety report

How do I install idamesh?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does idamesh need an API key?

No secret keys are declared. It reads 1 setting from the environment.

Is idamesh maintained?

The last commit was 102 days ago (2026-07-25). The latest release is v1.0.0.

How does idamesh compare with other MCP servers?

safety score 88/100 (higher than 75% of 48,255 servers); tools 61 (the typical server has 7); tools that change things 10% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.