Repository navigation
Cannot use any MCP tooling (server namespace prepended to requests) #100
Description
I am using Ollama locally on my Ubuntu 24.04.5 LTS machine with Ghidrassist and GhidrAssistMCP plugins in Ghidra 12.1.4 (also tested on Ghidra built from source, noted as Ghidra 12.3)
If I request MCP tool usage by ticking the Use MCP tickbox, the llm consistently cannot use the MCP server/tools. I noticed the LLM was adding the MCP Server name (noted in Settings-> MCP Servers) to the json request tool call. For example my server is noted as MyServer in the settings page. get_hexdump end up being 'myserver_get_hexdump' in the requests (noted in the output window, wireshark and Ghidra debug console) and thusly fails to get any tools AT ALL.
Tested on same machine with Oghidra and all works (albiet a different client server)
If I use curl to send requests with get_hexdump, I get the bytes I need back ok.
Nothing apart from session startup appears in the MCP plugin logs
All tests on settings pages come back with ticks
Any ideas?
Activity
boondoggler commentedon Oct 21, 2026
ok, I originally built from master. I have tried the latest released plugins and these seem to a) work ok and b) still apply the namespace to the request. Confused!
boondoggler commentedon Oct 21, 2026
ok, these plugins are unstable. Ive literally powered off my pc, restarted later and its now giving me:
version: 0.2.8 mode claude-opus-4.6 error. Message: the requested operation never completed, type overloaded error
and
Message: the requested operation was never completed.
I haven't changed any settings since it worked in post 2. I'm not even using Claude, its configured for Ollama as post 1.
Its almost as if it works one time after installing the plugin and then forevermore its soiled.
gjwang commentedon Oct 21, 2026
In current master, MCPToolManager passes the original tool name to the client. Its debug line shows both names; the adapter also logs the name sent to the server. Comparing those for one failed call, alongside the exact plugin build, would help locate where the prefix persists.
For the restart issue, does the active provider/model still show Ollama after reopening? The
claude-opus-4.6error makes that selection worth checking separately.boondoggler commentedon Oct 22, 2026
I'll be working on this tomorrow again, so standby for more information.
But yes ollama is still showing.
boondoggler commentedon Oct 23, 2026
Tried on Ghidra 12.1.4 and Ghidra master (Ghidra 12.3/jdk 25)
Added files showing Ghidra debug logs, working curl session, and the mcplog (showing no mcp tool calls, curling the tools shows in the log though)
I am still getting commentary back from the Explain tab - but this isnt using MCP tools obviously
Tried on HTTP and SSE
ghidra debug_log_23_10_query_some_bytes.txt
mcp_log.txt
works_curl.txt
gjwang commentedon Oct 23, 2026
Thanks for the logs — these narrow it down. At 09:42:51 discovery succeeds with 51 MCP tools. At 09:43:08 and 09:57:04, the logged LLM responses have
finish_reason: "stop"and nomessage.tool_calls. The later response putsthought/action/inputJSON insidemessage.content; that is text, not an executable tool call. The earlier “missing length” error is also in model-generated content, rather than a recorded MCP response.In 2.2.0’s Ollama adapter, the content fallback recognizes
name/arguments, arrays of those, ortool_calls— notaction/input. The handler treatsstopas completion. That explains why these two turns never reach MCP execution. The prefix is stripped later, when execution actually happens.The next useful comparison is a sanitized outgoing Ollama
/api/chatpayload and its original response for one such turn: does the request include the expected tool schema, and does the response contain nativemessage.tool_calls? Please omit credentials and unrelated binary/chat content. These logs establish where execution stops; they don’t yet establish why native tool calls are missing.boondoggler commentedon Oct 23, 2026
Forgive my insolence, we are reaching my limits of understanding the internals here.
So just to be clear, you want sanitized POST /API/chat data from a wireshark capture?
I see references to tools, ie ghidrassistmcp_get_hexdump etc, but no message.tools.calls is found in the packets
Note, I don't get the same response/stop/fail as I got in the last run, using the same "give me the bytes at" question, this time I just get this response in the query window:
Assistant assistant
2026-10-23 14-56-28
{
"address": "00100c58",
"data": "0f 05 ba 8c b6 ....." ,
"offset": 0,
"size": 20
}
Those bytes are of course incorrect
boondoggler commentedon Oct 27, 2026
So just to be clear, you want sanitized POST /API/chat data from a wireshark capture?