Claude Desktop MCP Tools Listed but Not Called: Fix Guide

If Claude Desktop shows an MCP connector and its tools, but every attempt ends with Failed to call tool and the server log never records tools/call, stop reinstalling the server. A successful tools/list followed by no tools/call means discovery worked and the failure is later in the client dispatch path. Confirm that signature, test the same server with MCP Inspector, update and restart Claude Desktop once, then report the client-side failure with precise evidence if it remains.

This guide separates a connection failure from a dispatch failure and a server execution failure. It also covers the July 2026 Claude Desktop incident in which users reported healthy handshakes, missing tools/call messages, and recovery without local configuration changes.

Prerequisites

You need:

• the current Claude Desktop app on macOS or Windows;

• one enabled local MCP connector with a harmless read-only tool;

• access to Claude Desktop's MCP logs;

• the command and arguments that start the server;

• Node.js 22.7.5 or newer if you plan to run the current MCP Inspector.

Use a read-only operation such as listing an allowed directory. Do not test a write, delete, message, payment, or deployment Action while the failure is unclear.

Step 1: Identify Which MCP Layer Failed

MCP discovery and execution are separate protocol operations:

The official MCP documentation defines tools/list as discovery and tools/call as execution. A tool appearing in Claude Desktop proves only that discovery completed.

This guide focuses on the middle row. If the server does not connect, use How to Fix Claude Code MCP Failed to Connect Errors first.

Step 2: Reproduce Once and Read the Logs

On macOS, Claude Desktop logs are normally under:

~/Library/Logs/Claude

On Windows, they are normally under:

%APPDATA%\Claude

Fully quit Claude Desktop, reopen it, enable the connector in a new conversation, and ask for one read-only operation. Then search mcp.log, the connector-specific log, and main.log for this sequence:

initialize
notifications/initialized
tools/list
tools/call

On macOS or Linux, if rg is installed:

rg -n "initialize|tools/list|tools/call|Failed to call tool" ~/Library/Logs/Claude

On Windows PowerShell:

Get-ChildItem "$env:APPDATA\Claude\logs\*.log" |
  Select-String -Pattern "initialize|tools/list|tools/call|Failed to call tool"

Expected result for a dispatch failure: initialize and tools/list complete, the UI fails immediately, and no tools/call appears after the attempt. Record the app version, operating system, connector version, UTC timestamp, and exact tool name.

Do not delete application data or credentials just to produce a cleaner log. The July 2026 reports included complete wipes and reinstalls that did not change this signature.

Step 3: Test the Server With MCP Inspector

The official MCP Inspector is a separate MCP client. If Inspector can both list and call a tool, the server, transport, and basic schema are working outside Claude Desktop.

For a local Node.js server, replace the placeholders with your real command and a harmless tool:

npx @modelcontextprotocol/inspector --cli \
  node /absolute/path/to/server.js \
  --method tools/list

Then call one read-only tool:

npx @modelcontextprotocol/inspector --cli \
  node /absolute/path/to/server.js \
  --method tools/call \
  --tool-name list_allowed_directories

If your server needs arguments or environment variables, pass the same non-secret values used by Claude Desktop. Do not paste a provider key into a screenshot, issue, or public command history.

Expected result: tools/list returns the tool schema and tools/call returns a result. That control moves the investigation from the server to Claude Desktop's registry, permission, validation, or dispatch layer. For more Inspector examples, use How to Test an MCP Server With MCP Inspector.

If Inspector also fails, inspect the first actual error. Check the executable path, working directory, environment, allowed paths, authentication, and the tool's JSON Schema. Fix that server-side error before changing Claude Desktop.

Step 4: Apply the Smallest Safe Client Recovery

Use this order:

1. Confirm that Claude Desktop is on the current available version.

2. Fully quit the app, not just its window, then reopen it.

3. Open Settings > Extensions and confirm that the connector is enabled and its required fields are complete.

4. Review the tool permission in a new conversation and allow only the read-only test.

5. Run the same read-only request once and check whether tools/call now appears.

Expected result: either dispatch resumes, or you retain the same clean failure signature for support.

Anthropic's help center recommends updating Claude Desktop, restarting it, reviewing extension configuration, and checking MCP logs. Those steps are safe and reversible. Repeated reinstalls, broad PowerShell execution-policy changes, disabling a firewall, or deleting all local state do not isolate this layer and can create a second problem.

Step 5: Treat the July 2026 Incident as a Dispatch Incident

On July 22, 2026, users reported the same signature on macOS and Windows: Claude Desktop completed initialize and tools/list, but never sent tools/call. One GitHub report collected independent reproductions across first-party and custom Filesystem connectors.

The original reporter later said calls began working again on the same Claude Desktop build with no reinstall or configuration change. Another Windows reporter confirmed recovery on a later build. Those reports establish recovery, but they do not provide an official root-cause statement. Do not claim that a local Node.js version, JSON Schema field, extension update, or remote feature flag caused your case without your own evidence.

If the exact signature persists after the safe recovery sequence:

1. Check for a matching current incident or issue.

2. Add your app version, platform, connector type, UTC window, and sanitized log sequence.

3. State whether Inspector completed both tools/list and tools/call.

4. State which local changes you did not make.

5. Use a different trusted MCP client or a managed remote Action for urgent read-only work.

Expected result: the maintainer can distinguish a server failure from a client dispatch outage without asking you to repeat destructive cleanup.

Step 6: Use a Remote Control Path Without Exposing Credentials

A remote Action does not repair Claude Desktop, but it can keep a bounded workflow moving while you isolate a local client failure. It also provides a useful control because discovery and execution happen through another client and transport.

Install or update Aident Loadout by giving your coding agent this exact instruction:

Follow https://aident.ai/SETUP.md

Then run:

aident account auth status
aident vault vault --action status
aident capabilities search \
  --query "read-only issue lookup" \
  --types '["action"]' \
  --targetEnv staging \
  --limit 5

Inspect the selected Action before execution:

aident capabilities get --name "<canonical_action_name>"

Run one harmless read-only request that matches the returned schema. Expected result: one current schema is inspected, one read-only result returns, no provider credential is copied into the prompt, and git status --short remains unchanged.

This follows the repeatable structure behind Aident's Ollama networking guide: use the exact failure language, identify the layer, run a reproducible probe, state the expected result, and explain why the result narrows the cause.

Use Aident Loadout to verify one read-only Action. Measure success as one schema inspected, one harmless result returned, and no repository diff or provider secret exposed.

Common Failure Modes

The tool is visible, but Claude never chooses it

Ask for one explicit operation using the tool's exact purpose. If the app still does not attempt execution, inspect permissions and whether the connector is enabled for that conversation. This is different from an attempted call that fails immediately.

tools/call appears and returns an error

The request reached the server. Read the returned error and validate the input against the advertised schema. Do not keep changing the client after the transport has proven it can dispatch.

Inspector lists tools but cannot call one

The server may advertise a schema that it cannot execute, require a missing environment value, or reject the chosen input. Run the most basic read-only tool and inspect the server's stderr.

The connector works in one client but not another

Compare protocol version, transport, environment, authentication, and tool schema handling. Client-specific success is a control, not proof of the losing client's exact root cause.

Sources

• Getting Started with Local MCP Servers on Claude Desktop, Anthropic, accessed July 27, 2026

• Understanding MCP Servers, Model Context Protocol, accessed July 27, 2026

• MCP Inspector, Model Context Protocol, accessed July 27, 2026

• Claude Desktop never dispatches tools/call to the Filesystem extension, Anthropic issue tracker, July 22-27, 2026

• Claude Desktop local MCP tool calls fail before dispatch, Anthropic issue tracker, July 22, 2026

Refresh this guide when Anthropic publishes a root-cause statement, changes Claude Desktop log locations, or changes extension installation and permission controls.