MCP tools not showing up? Start here

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 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.

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 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 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 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). Cursor offers a similar per-server switch under Customize (Cursor's MCP docs).

Who fixes which cause?

Once tools appear, the Claude setup and the ChatGPT setup cover what to set before a team relies on it.