تجنب تعارض أسماء الأدوات

When many servers share a host, two of them may both ship a tool called search. Now the model cannot tell which one you mean. ⚠️

The model picks tools by name. If two entries read the same, it may call the wrong one, producing puzzling results. A collision quietly breaks routing.

Give each tool a unique label by prefixing it with its server. This is namespacing: github_search and docs_search can now live side by side.

Many hosts add the server name as a prefix automatically when they merge the tool pool, so collisions are resolved before the model ever sees them.

Even with auto-prefixing, vague names hurt. Inside your own server, choose specific tool names like create_issue, not just create, so intent stays obvious.

Clients and prompts may reference a tool by name. Renaming it later is a breaking change, so treat each tool name as part of your public contract.

If two tools must look similar, sharp descriptions help the model choose. Spell out exactly when each tool applies and how they differ.

Adopt one naming pattern across all your servers, like service_action. A predictable scheme makes the whole toolset readable at a glance.

Tools are not alone: resource URIs can clash as well. Use distinct schemes, like notes:// versus tasks://, so two servers never fight over an address.

After wiring servers together, list every tool the host exposes and scan for duplicates. Catching a clash early beats debugging a wrong call later. 🔍

Clear, prefixed, stable names let the model route confidently across a busy fleet. Good naming is invisible when it works and painful when it does not. ✨

What is the standard cure for two servers sharing a tool name?

Namespacing tools by server keeps identical names distinct, and clear, stable descriptions help the model route to the right one every time. 🎉