# MCP tools not showing up? Start here

> MCP tools not showing in Claude, ChatGPT or Cursor? With Elaichi, connected tools are never listed by design. Check these five things, in order.

**TL;DR** With Elaichi, MCP tools not showing in the client's list is normal: connected tools are never listed one by one, however few there are, and the client finds them with search_tools. If a search still finds nothing, check five things in order: the app is connected, its connection is active, no restriction blocks it, the connection may run tools, and the search names the app. An empty list means the person's role lacks tool:execute, which only an admin can change.

## Why are my MCP tools not showing?

Usually because they are not supposed to show. With Elaichi, MCP tools not showing in the client's tool list is the design. In Elaichi, connected tools are never listed one by one, however few there are. Claude, ChatGPT or Cursor sees two tools, `search_tools` and `execute_tool`, and uses them to find and run every connected tool.

Hundreds of tool definitions crowd a model's context, and a long list makes the wrong pick likelier. So Elaichi lists only what the model needs to find a tool, and ranks each search against what the person can reach. [The MCP context window problem, and a fix](/blog/context-window-problem-mcp-tools/) explains the trade-off.

So start with what the list should contain. If it matches, the connection works, and a missing tool is one of the five checks below.

## What should an Elaichi tool list contain?

Three kinds of entry, and the connected tools are never among them:

- **Elaichi's own operations**, whose names start with `elaichi__`, listed individually when the person's role and the connection's permissions allow them.
- **`search_tools` and `execute_tool`**, present while at least one connected tool is reachable.
- **Nothing per app.** A Jira or Zendesk tool never appears in the list itself.

If `search_tools` and `execute_tool` are both missing, no connected tool is reachable yet, and the first two checks below are the likely reason.

## Is the app connected at all?

Check under **Connections** in Elaichi. If the app is not there, nothing can find its tools, and the fix is to connect it from the [connector catalog](/connectors/).

Search makes this case visible. A search naming an app the person never connected returns no results, with a line naming up to six apps the connection does reach. That empty answer is deliberate: a tool from the wrong app would be worse than none, because the model would call it.

## Is the connection active?

A connection that is not active contributes no tools at all. It is missing from the results, not present and failing. In the console a broken connection shows **Needs sign-in**, and one nobody finished shows **Awaiting sign-in**.

Open the connection under **Connections** and select **Reconnect**, or **Finish sign-in** for one that never completed. Then complete the app's own login. Reconnecting rebinds the same connection to the same account, so its shares and toolbox entries survive.

Who may do it is narrow. The owner, someone with edit access, or an admin over a shared connection can reconnect. Only the owner can finish a connection that never completed, because finishing it binds a new identity.

## Could a restriction hide the tool?

Yes, and a hidden tool looks exactly like one the connector never had. Restrictions decide which connectors and which individual tools a target may reach. A connector-wide block is visible: the connector is marked restricted. A block on one tool is not visible to the person it applies to.

So the honest answer from a member's seat is "unavailable", not "missing". Only someone who can view restrictions, an admin or an Auditor, can confirm a single blocked tool, and a default Member cannot. Ask one. Watch for one trap when allow rules are involved: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.

A restriction change takes about two minutes. Test it after that window.

## Does the connection have permission to run tools?

It needs one checkbox on Elaichi's consent screen: **Run your connected tools**. Without it, the connection can use Elaichi's own operations but no connected app. A tool call answers with an error naming that checkbox and asking you to reconnect and tick it.

Two narrower cases look the same from the client:

- **Delete tools hide without the delete permission.** A tool that deletes is left out of search entirely unless **Delete data and remove access** was ticked.
- **A connection limited to chosen toolboxes** reaches only their tools. If none of those toolboxes can be used any more, it reaches nothing, never everything. Edit the choice under **Settings**, then **Connected apps**, in Elaichi.

[Fixing OAuth errors when adding an MCP connector](/blog/mcp-oauth-errors/) covers reconnecting and the consent screen in detail.

## Did the search name the tool?

Search matches words, not meaning, so phrase the request the way the tool is named. Ask for "list Jira issues" rather than "what is the team working on". The model searches with `search_tools` and calls the result through `execute_tool`.

A search returns nothing rather than a weak match from another app. That floor keeps the model from running a Notion tool when you asked about Cal.com. [How MCP tool search picks one tool from hundreds](/blog/search-tools-ranking-floor-idf/) explains the ranking.

## Why is the whole list empty?

The person's role lacks `tool:execute`. Without that permission the list is empty at every level of access the connection holds, and every call answers with an error naming the permission and saying that reconnecting will not help. Guest, Auditor and Billing Admin lack it, while Member and above hold it.

That fix belongs to an admin, who changes the role. A Billing Admin or an Auditor who signs in to look at Elaichi from Claude will always see an empty list, and that is correct.

An organization can also switch off Elaichi's own operations. They then disappear from every list, while connected tools keep working.

## Why did the tools not appear after a change?

Because the client is holding an old list. The [MCP specification](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) lets a server declare whether it will send a notification when its list of tools changes. Elaichi declares that it will not, so a client keeps whatever list it last read.

Most changes do not need a fresh list, because connected tools are found by search, not by the list. The exception is the first app. `search_tools` and `execute_tool` appear only once a connected tool is reachable, so a client that read its list before then does not have them. Start a new conversation, or disconnect and reconnect, to make it read the list again.

In Claude, also check the conversation's own switch. Each chat has a toggle per connector under the **+** button, then **Connectors**, and a connector switched off there sends nothing ([Anthropic's getting-started guide](https://claude.com/docs/connectors/getting-started)). Cursor offers a similar per-server switch under Customize ([Cursor's MCP docs](https://cursor.com/docs/mcp)).

## Who fixes which cause?

| Cause | Who fixes it |
|---|---|
| App not connected | Anyone who may connect apps |
| Connection needs sign-in | Its owner, an edit grantee, or an admin |
| Connection never finished | Its owner |
| A restriction | An admin |
| No permission to run tools | The person, by reconnecting |
| Role lacks `tool:execute` | An admin |
| Old tool list in the client | The person, with a new conversation |

Once tools appear, [the Claude setup](/blog/connect-elaichi-to-claude/) and [the ChatGPT setup](/blog/connect-elaichi-to-chatgpt/) cover what to set before a team relies on it.

## FAQ

### Why does my MCP client show only search_tools and execute_tool?

Because that is how Elaichi works. In Elaichi, connected tools are never listed one by one, however few there are. The client looks a tool up with search_tools and runs it with execute_tool, so those two in the list mean the connection is working.

### Why is my Elaichi tool list completely empty?

Your role probably lacks the tool:execute permission. Without it the list is empty whatever the connection allows, and every call says so. Guest, Auditor and Billing Admin lack it. An admin has to change the role.

### Does Elaichi tell my client when the tool list changes?

No. Elaichi declares that it sends no list-changed notifications, so a client keeps whatever list it last read. Start a new conversation or reconnect if a newly connected app's tools do not appear.

### How long does a restriction change take to show up?

Role and restriction changes take about two minutes, on every surface. Grant revocation, member removal and suspension take effect on the next call.

## Read next

- [Connect company apps to Claude and ChatGPT](/blog/connect-company-apps-to-claude-and-chatgpt/) — To connect company apps to Claude and ChatGPT, connect each account once in Elaichi, share it, and add one URL to both. No MCP server to run.
- [Connect Elaichi to Claude Code](/blog/connect-elaichi-to-claude-code/) — To connect Elaichi to Claude Code, run one claude mcp add command and sign in with OAuth. The entry holds no secret, so a project .mcp.json is safe to commit.
- [Connect Elaichi to Codex](/blog/connect-elaichi-to-codex/) — To connect Elaichi to Codex, add one URL as a streamable HTTP server and run codex mcp login. No token, no header, and each engineer signs in as themselves.