By Shekhar — Founder, AgenticMarket. Tested on Cursor 0.48, VS Code 1.99, and Claude Desktop 0.10 on macOS 15 Sequoia and Windows 11. Last reviewed April 2026.

Your MCP server shows a green dot. The tools are listed. You saved the config, restarted the IDE, and the handshake clearly succeeded. But when you ask the agent something that should require a tool call — it either answers from memory, says it can't help, or just does nothing. This is a different problem from an MCP server that won't connect. If connection failures (error -32000, PATH issues, stdout contamination) are what you're debugging, see the MCP server not working troubleshooting guide instead. This post is specifically for the situation where the server is connected but the agent ignores it.

Quick win: skip manual tool configuration by browsing AgenticMarket's explore page and installing community-verified servers with a single command. It guarantees tool schemas are compatible with your IDE.

The short answer: A connected server and an agent that uses its tools are two separate things. Connection proves the handshake worked. Tool use requires the right IDE mode, staying under tool count limits, enough context budget left, and a prompt that signals to the agent that a real-time tool call is needed. Any one of these can fail silently.

Why "connected" doesn't mean "tools will be called"

When your IDE connects to an MCP server, it performs a handshake: sends an initialize request, the server responds with its capabilities and tool list, and the client stores that tool schema. This is what the green dot confirms.

After that handshake, three completely separate systems decide whether a tool ever gets called:

1. The IDE's mode/context — VS Code only exposes tools in Agent mode; other modes don't pass tool definitions to the model at all.
2. The tool budget — Cursor caps at 40 tools. Beyond that limit, tools are silently excluded from what the model can see.
3. The model's reasoning — Claude and GPT-4o decide whether to call a tool based on your prompt. If the task seems answerable from training data, they'll skip the tool entirely.

All three can fail without any error message. The server stays green. The tools panel still shows everything. The agent just never calls them.

see Image below :

Fix 1 — VS Code: you're not in Agent mode

MCP tools in VS Code GitHub Copilot are only active in Agent mode. In Ask mode, the tool panel appears but Copilot never injects the tool schemas into the context — the tools are visible in the UI but invisible to the model.

This is documented in the VS Code MCP docs but easy to miss because the tools panel appears in all modes. Look for the mode selector in the Copilot Chat input bar — it defaults to Ask. Switch it to Agent.

Copilot Chat → input bar → mode dropdown → switch Ask → Agent

see Image below :

If you don't see the mode dropdown, update to VS Code 1.99 or later. Agent mode shipped in 1.97 but the UI changed in 1.99.

One more VS Code-specific thing: when you save mcp.json for the first time, a Start button appears inline in the editor next to the server definition. You have to click it — it's not automatic on first save. After clicking Start, the server registers and tools become available in the session.

Fix 2 — Cursor: you've hit the 40-tool hard limit

Cursor enforces a hard maximum of 40 active tools across all connected MCP servers combined. If your servers collectively expose more than 40 tools, the excess are silently excluded — they appear in the tools panel as toggleable items, but the agent never receives their schemas.

You will not get a warning. The panel looks normal. The tools just silently don't exist from the model's perspective.

I confirmed this on Cursor 0.48 — opening Settings → Features → MCP Servers shows a live per-server tool count. Add them up: once the total crossed 40, the tools I added last disappeared from agent behavior while remaining visible in the panel. The Cursor MCP documentation mentions tool limits but doesn't surface the 40-tool number prominently; it's discussed in detail on the Cursor forum MCP threads.

How to check your current tool count:

Cursor Settings → Tools & MCPs → MCP Servers
→ Each server entry shows tool count
→ Add them up — if over 40, excess tools are invisible to the agent

How to fix it:

Disable servers you aren't actively using for the current task. Individual tools within a server can also be toggled off in the tools panel — disabling a tool removes it from the count. Keep your active tool count under 35 as a practical buffer.

If you need more than 40 tools regularly, work in task-specific profiles: enable only the servers relevant to what you're building right now and disable the rest.

---

Fix 3 — The context window tax no one talks about

Every MCP server you connect injects its full tool schema into the model's context window at the start of each session — before you type a single character. This isn't a Cursor bug or a VS Code quirk; it's how the MCP protocol works.

Measured in practice: a session with 5–6 multi-tool servers loaded has been documented consuming 15,000+ tokens in tool definitions before any user message. Developer testing reported on the Cursor forum found that 30–40% of a context window can go to tool schemas that are never called in that session.

The consequences:

• Earlier context limit hits — you run out of context faster on long sessions
• Degraded reasoning — the model has less working memory for your actual task
• Claude Desktop "reached tool-use limit" — Claude Desktop stops mid-task after too many tool calls, more likely with heavy server loads

The fix is the same as the tool count fix: run only the servers you need right now. Unlike the 40-tool limit which is about schema visibility, the context budget issue affects you even if you're under 40 tools — 6 servers with 5 tools each can still consume a disproportionate share of context.

This is why AgenticMarket's servers are designed to be lean and single-purpose — each does one thing, keeps its tool schema small, and doesn't pollute the context budget of unrelated tasks.

---

Fix 4 — The agent decided it doesn't need to call anything

Language models make tool call decisions based on whether the task appears to require live data, external access, or computation they can't do alone. For many queries, they'll answer from training data and skip the tool entirely — even when a better answer was available through the tool.

Common scenarios where the agent skips tools:

• A question the model can answer from memory, even if stale ("what's the current EUR/USD rate" can get answered with outdated training data)
• The tool name doesn't make its purpose obvious to the model
• The prompt is ambiguous about whether real-time data is needed

Prompts that consistently trigger tool calls:

textCOPY
// Too vague — model answers from training data
"What's the exchange rate?"

// Explicit — model understands it needs live data
"Use the exchange-rate tool to fetch the current EUR to USD rate"

// Also works — framing signals it needs real data
"What is today's live EUR/USD rate? Do not use training data."

Referencing the exact tool name is the most reliable signal. When the model sees a name it recognizes in the active tools list, it routes to that tool. If the tool name is generic (fetch, get_data, query) the model has less to anchor on.

AgenticMarket's servers follow a verb-noun naming convention (check_url_status, fetch_exchange_rate, read_webpage) specifically to give the model strong routing signals.

---

Fix 5 — Tool name conflicts between servers

If two connected servers expose a tool with the same name — or names differing only by underscore vs hyphen (get_data vs get-data) — the behavior is undefined. One set wins, one set gets silently overridden. You won't know which.

This surfaces as: "these tools worked yesterday and stopped today." What usually happened is a server update changed a tool name, creating a conflict with another server.

How to check for conflicts:

bashCOPY
# In Cursor: open the output panel and look for tool registration messages
# Ctrl+Shift+U → select MCP from the dropdown
# Look for: "Tool X already registered" or duplicate tool names in the list

If you find a conflict, rename one tool or disable one of the conflicting servers. There's no automatic resolution.

---

Fix 6 — Claude Desktop transport mismatch or tool-use limit

Two Claude Desktop-specific issues cause tools to silently stop being called even when servers appear connected.

Transport mismatch: Claude Desktop expects stdio servers. Remote HTTP servers with "url": "https://..." in the config will appear connected in Claude Desktop's UI but the tools will never be called. If you copied a Cursor or VS Code config that uses URL-based entries, they won't work in Claude Desktop.

jsonCOPY
// Works in Cursor and VS Code — does NOT work in Claude Desktop
// Claude Desktop silently ignores this entry
{
  "mcpServers": {
    "my-server": {
      "url": "https://api.example.com/mcp"
    }
  }
}

// Use this in Claude Desktop instead — runs the server locally via npx
{
  "mcpServers": {
    "my-server": {
      "command": "npx",
      "args": ["-y", "my-server-package"]
    }
  }
}

See Anthropic's Claude Desktop MCP documentation for the supported config formats.

Tool-use limit mid-task: Since early 2026, Claude Desktop enforces a per-turn tool call limit. On complex agentic tasks with many tool calls, Claude stops mid-task with "Claude reached its tool-use limit for this turn." The workaround is to break tasks into smaller explicit steps and reduce the total number of servers loaded.

---

AgenticMarket-specific fixes

If you installed a server through AgenticMarket and it's connected but tools aren't being called, run through these in order.

Check that the server is active:

bashCOPY
# See all installed servers and their current status
agenticmarket list

A server with status inactive means AgenticMarket's health monitor detected the creator's endpoint is down. The server appears in your config but calls will fail silently. If you see inactive, that's a server-side issue — try a different server for the same task.

Verify your credits:

bashCOPY
agenticmarket balance

A zero balance causes all tool calls to fail silently after the connection is established. The server connects fine (auth happens at the IDE config level) but the actual tool invocation gets rejected by the proxy. Top up at agenticmarket.dev/topup — credits never expire.

Reinstall if config drifted:

bashCOPY
# Remove clears all config entries the CLI previously wrote
agenticmarket remove server-name
agenticmarket install username/server-name

Manual edits to the AgenticMarket config entries can break the auth header format. A clean reinstall writes everything correctly.

---

Quick diagnostic checklist

---

Related reading:

• MCP Server Not Working? The Complete Troubleshooting Guide — for connection failures (-32000, PATH, stdout), not tool-call failures
• How to Install MCP Servers Without Editing JSON — one command installs to every IDE simultaneously
• How to Monetize Your MCP Server — if you're building servers rather than installing them, the secret validation pattern that prevents unauthorized tool calls

---

Frequently asked questions

Why does my MCP server show green in Cursor but the agent never calls the tools?

A green dot confirms the handshake. It doesn't guarantee the agent will use the tools. The most common causes: Cursor's 40-tool limit silently excluding your server, the agent deciding it can answer from training data, or tool name conflicts. Check Settings → Features → MCP Servers, count your total active tools, and try an explicit prompt that names the tool directly.

Why does VS Code show my MCP tools but they're never called in chat?

MCP tools in VS Code only activate in Agent mode. In Ask or Edit mode, tools are visible in the UI but never passed to the model. Switch the Copilot Chat mode selector from Ask to Agent. Also confirm you clicked the Start button that appears in the mcp.json editor when you first save a new server entry.

How do I force Cursor to use a specific MCP tool?

Reference the exact tool name in your prompt: "Use the fetch_exchange_rate tool to get the current EUR/USD rate." The more explicit the routing signal, the more reliably the agent calls it. Generic prompts that could be answered from training data will often skip tools entirely.

What is the Cursor 40-tool hard limit?

Cursor caps the total number of tools the agent can see at 40, summed across all connected servers. Beyond 40, tools are silently excluded — the UI shows them as enabled but the agent doesn't receive their schemas. Disable servers you aren't actively using to stay under the limit.

Why does Claude Desktop stop mid-task with "reached tool-use limit"?

Claude Desktop enforces a per-turn tool call cap. This triggers more easily when you have many servers loaded and Claude is making multiple sequential tool calls. Break tasks into smaller explicit steps and reduce the number of active servers.

Why do tool definitions consume so much context?

Every connected MCP server injects its full tool schema into the model's context at session start — before your first message. Real-world measurements show 5–6 multi-tool servers consuming 15,000+ tokens per session before any work is done. Run only the servers you need for the current task.

---

Last reviewed April 2026. Tested on Cursor 3.0.1, VS Code 1.115.1, Claude Desktop 0.10 — macOS 15 Sequoia and Windows 11. If you're hitting a "connected but ignored" failure not covered here, open an issue and I'll add it.

---

If this was your problem: drop a comment with which fix resolved it — the 40-tool limit catches more people than most expect. Helps other developers find the right answer faster.

I publish posts on MCP tooling roughly twice a month. Subscribe to the AgenticMarket newsletter to get the next one.