Skip to main content
Glama
Sign In
Ghidra MCP Server

Ghidra MCP Server

by bethington
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

connect_instance

Connect the MCP bridge to a specified Ghidra instance by project name to access its analysis tools and dynamically load the instance's schema.

Instructions

Switch the MCP bridge to a different Ghidra instance by project name.

IMPORTANT: Before calling this function only the static bridge tools are exposed (list_instances, connect_instance, tool-group management, debugger proxy). After a successful connect the bridge fetches the instance's /mcp/schema and registers Ghidra analysis tools dynamically. By default all tool groups are loaded on connect. When started with --lazy, only the default groups are loaded initially and clients may need to call load_tool_group() for additional categories. Clients that cache the initial tools/list and don't honor tools/list_changed must re-list tools after this call.

Use list_instances() first to see available instances.

Args: project: Project name (or substring) to connect to

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>"
    },
    "name": "connect_instance"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectYesProject name (or substring) to connect to

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv7.0.0
    • addedInput schema / properties / project / description
      Added value: +"Project name (or substring) to connect to"
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "connect_instanceOutput",
-  "type": "object"
-}New value: +null
  2. First observedv5.15.0

TDQS

A4.4/5.0
Behavior5/5

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

The annotations only declare readOnlyHint=false and destructiveHint=false; the description adds substantial behavioral context beyond that. It discloses that only static bridge tools are available before connecting, that schema fetching and dynamic tool registration occur after connecting, and that lazy mode and cached tools/list clients require special handling.

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?

The description is front-loaded with the purpose and then gives necessary lifecycle details. It is somewhat long, and the Args block duplicates the schema parameter description, but the behavioral detail is largely justified for a stateful connection switch.

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 complex stateful tool with no output schema, the description covers the critical context: pre-connect tool availability, post-connect dynamic registration, lazy group loading, and client re-listing requirements. Nothing essential to invoking it correctly appears to be missing.

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

Parameters3/5

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

Schema description coverage is 100%, and the description repeats the same project name/substring meaning already present in the schema. It does not add syntax, matching behavior details, or error semantics beyond what the schema provides, so the baseline 3 applies.

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 states a specific verb and resource: switch the MCP bridge to a different Ghidra instance by project name. It clearly distinguishes this from list_instances by making list_instances a prerequisite and explaining the post-connect tool-registration effect.

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?

It explicitly says to use list_instances() first and explains the before/after connect context, including lazy loading and client caching behavior. However, it does not state explicit when-not-to-use conditions or alternatives beyond the prerequisite.

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

Deploy Server

Other Tools