Tools · Runs in your browser, optional AI deep-dive

MCP Tool Collision Checker

Connect a few MCP servers and your agent starts picking the wrong tool. Paste each server's tool list to find the names, descriptions and parameters it will confuse, and what to rename before you ship.

Same name, two servers

search on GitHub and search on web search. Clients may drop one or route the call to the wrong server.

Two tools, one job

get_issue and fetchIssue, or descriptions so alike the model has to guess which one you meant.

Definitions eat context

Every tool's schema is sent with every request. Dozens of tools cost tokens and make the choice harder.

Your servers' tool lists

One box per MCP server or tool source. Paste the result of tools/list, or an OpenAI / Anthropic toolsarray. The examples below are illustrative, not any vendor's real schema.

{ "tools": [ { "name": "search", "description": "Search GitHub for repositories, code, or issues matching a query.", "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "type": { "type": "string", "description": "repositories, code or issues" } }, "required": [ "query" ] } }, { "name": "get_issue", "description": "Get a GitHub issue by its number, including title, body, labels and state.", "inputSchema": { "type": "object", "properties": { "repo": { "type": "string", "description": "owner/name" }, "issue_number": { "type": "number" } }, "required": [ "repo", "issue_number" ] } }, { "name": "create_issue", "description": "Open a new issue in a GitHub repository.", "inputSchema": { "type": "object", "properties": { "repo": { "type": "string", "description": "owner/name" }, "title": { "type": "string" }, "body": { "type": "string" } }, "required": [ "repo", "title" ] } }, { "name": "list_issues", "description": "List issues in a GitHub repository, filtered by state and labels.", "inputSchema": { "type": "object", "properties": { "repo": { "type": "string", "description": "owner/name" }, "state": { "type": "string" }, "labels": { "type": "string" } }, "required": [ "repo" ] } }, { "name": "create_or_update_file", "description": "Create or update a single file in a GitHub repository and commit it to a branch.", "inputSchema": { "type": "object", "properties": { "repository": { "type": "string", "description": "owner/name" }, "path": { "type": "string" }, "content": { "type": "string" }, "branch": { "type": "string" } }, "required": [ "repository", "path", "content" ] } } ] }
5 tools · ~361 tokens
{ "tools": [ { "name": "search", "description": "Search the web and return the top results with titles, URLs and snippets.", "inputSchema": { "type": "object", "properties": { "query": { "type": "string" }, "count": { "type": "number" } }, "required": [ "query" ] } }, { "name": "fetch", "description": "Fetch a URL and return the page as markdown.", "inputSchema": { "type": "object", "properties": { "url": { "type": "string" } }, "required": [ "url" ] } } ] }
2 tools · ~99 tokens
{ "tools": [ { "name": "fetchIssue", "description": "Get an issue.", "inputSchema": { "type": "object", "properties": { "id": { "type": "string" } }, "required": [ "id" ] } }, { "name": "create_issue", "description": "Create an issue.", "inputSchema": { "type": "object", "properties": { "title": { "type": "string" }, "description": { "type": "string" }, "team": { "type": "string" } }, "required": [ "title", "team" ] } }, { "name": "search_issues", "description": "Search issues by text, returning matching issues with their state and labels.", "inputSchema": { "type": "object", "properties": { "q": { "type": "string" } }, "required": [ "q" ] } } ] }
3 tools · ~141 tokens

Likely mix-ups

At least one pair of tools shares a name or does the same job in words the model can't separate. Expect wrong tool picks, or calls routed to the wrong server.

tools

servers

~601

tokens / request

Confusable pairs

highcreate_issue (GitHub) ↔ create_issue (Issue tracker)Identical name on two servers — clients that don't namespace tools may drop one or send the call to the wrong server
highget_issue (GitHub) ↔ fetchIssue (Issue tracker)Synonymous names (same action, different verb or plural) · Descriptions 60% similar
highsearch (GitHub) ↔ search (Web search)Identical name on two servers — clients that don't namespace tools may drop one or send the call to the wrong server
mediumsearch (GitHub) ↔ search_issues (Issue tracker)Descriptions 57% similar

Weak descriptions

mediumfetchIssue (Issue tracker)Only repeats the name: "Get an issue."
mediumcreate_issue (Issue tracker)Only repeats the name: "Create an issue."

Inconsistent parameters

lowThe search query goes by 2 namesquery in search (GitHub), search (Web search) · q in search_issues (Issue tracker)
lowThe repository goes by 2 namesrepo in get_issue (GitHub), create_issue (GitHub), list_issues (GitHub) · repository in create_or_update_file (GitHub)

Fixes, most important first

highNamespace `search`: expose it as `github__search`, `web_search__search`
highNamespace `create_issue`: expose it as `github__create_issue`, `issue_tracker__create_issue`
highRename one of `get_issue` (GitHub) and `fetchIssue` (Issue tracker), or prefix both with their server, and say in each description which system it acts on
mediumAdd a "use this for …, not for …" sentence to `search` (GitHub) and `search_issues` (Issue tracker) that names how they differ
mediumRewrite the description of `fetchIssue` (Issue tracker): what it does, what it returns, and when to pick it
mediumRewrite the description of `create_issue` (Issue tracker): what it does, what it returns, and when to pick it
lowPick one parameter name for the search query: `query`, `q`
lowPick one parameter name for the repository: `repo`, `repository`

The checks run in your browser; nothing is uploaded or stored. The share link holds tool names, descriptions and parameter names and types — not parameter descriptions. Token counts are estimates (~4 characters per token). A heuristic review of the text the model sees, not a test of how a specific model behaves.

AI deep-dive

The checks above find the tools your agent will mix up. The AI deep-dive fixes them: a new name and a rewritten description for every confusable tool, normalised parameters, and the tools your agent probably doesn't need.

What is the agent for?Optional

0 / 6,000

Free with a sign-in. Nothing you paste is stored.

Building an agent on many tools?

I design and build AI agents with LangGraph and MCP — with tool sets scoped per task, descriptions written for the model, and evals that catch wrong tool picks before your users do.

LangChain Developer Services →Discuss your project

Designing AI Agents: Tools, Patterns, and Pitfalls

Designing AI agents that hold up — single-step vs multi-agent workflows, tool-calling patterns, memory architecture, and the reliability pitfalls.

How to Build a Custom Model Context Protocol (MCP) Server in TypeScript for Claude Code

Build an MCP server in TypeScript with the official SDK — expose PostgreSQL inspection tools over stdio, sanitize queries, and wire it into Claude Code.

Engineering Custom MCP Servers for Local AI Agents: Bridging PostgreSQL, MongoDB, and REST APIs with LangGraph and Next.js

A hands-on 2026 guide to building secure TypeScript MCP servers that connect local Ollama models and Claude Code to PostgreSQL, MongoDB, and REST APIs, orchestrated with LangGraph, streamed to a Next.js dashboard, and deployed with Docker and Nginx on AWS.

How to Build a Self-Healing Tool Call Execution Loop using Zod and LangGraph.js

Learn how to build a self-healing tool call loop in LangGraph.js. Validate LLM tool arguments with Zod, route failures to a correction node, and let local models fix their own invalid JSON.

How to Implement Hierarchical Context Compaction in LangGraph.js to Prevent Agent Context Drift

A practical, code-first guide to building a hierarchical context compaction layer in LangGraph.js — using Ollama for local summarization and PostgreSQL checkpointing to stop long-running AI agents from drifting off-goal.

Frequently asked questions

Why does my agent call the wrong tool?

A model chooses a tool by reading its name and description, nothing else. When two tools have the same name, synonymous names such as get_issue and fetchIssue, or descriptions that cover the same ground, the model has nothing to decide on and guesses. Thin descriptions such as "Get an issue." make it worse, because they don't say which system the tool acts on.

What happens when two MCP servers expose a tool with the same name?

It depends on the client. Some prefix tools with the server name, some keep whichever registered first and drop the other, and some have routed calls to the wrong server. The MCP spec doesn't settle it, so the safe fix is to make names unique yourself — usually by prefixing each with its server, such as github__search and web__search.

How do I get the tool list from an MCP server?

Call tools/list on it: the MCP Inspector (npx @modelcontextprotocol/inspector) shows the result and lets you copy it as JSON. If your agent framework already builds a tools array for the OpenAI or Anthropic API, you can log and paste that instead — the checker accepts both shapes.

How many tools is too many?

There's no hard number, but choice gets less reliable as the list grows, and every definition is sent with every request, so it costs tokens and latency. OpenAI's function-calling guide suggests keeping fewer than about 20 tools available at once. Beyond that, load tools per task or split the work across sub-agents that each get a smaller set.

How is description overlap measured?

Each tool's name and description become a TF-IDF word vector, with common verbs mapped to one form (fetch, read and get count as the same word). Two tools whose vectors are 50% or more similar and share at least two meaningful terms are flagged. It's a fast heuristic, not a model, so read each flag before acting on it.

Is my tool list stored or sent anywhere?

The checks run in your browser. A share link carries the tool names, descriptions and parameter names in the part of the URL after #, which browsers never send to a server.

What does the AI deep-dive add?

It proposes a new name and a rewritten description for each confusable tool, normalises parameter names, and flags tools your agent probably doesn't need. The optional AI deep-dive sends your tool names, descriptions and parameters to an AI model through OpenRouter and returns a written review. It needs a free sign-in (email code) and is rate-limited. Nothing you paste is saved by this site — only a count of runs, for the limits.