TL;DR
When an agent has several similar tools (say, two "send email" tools from different MCP servers), the model picks based on metadata: the server and tool names, the description, and the parameter schema. The researchers changed exactly one field at a time and watched how the choice shifted. The parameter schema had the biggest influence: which fields the tool accepts, how they're named, and how they're grouped. Names had little influence.
The headline finding: a tool can lose before it's ever called, purely because of poor naming and field structure. If a field is called recipient_id instead of the familiar to, the tool gets picked in 1–10% of cases instead of roughly 50%. The model reads _id as "needs an identifier, not an email address" and steers around that tool. If tool names differ but mean the same thing, the model often just takes the first one in the list.
The paper's practical takeaway: flat, separate parameters (owner and repo, not one glued string or an object), familiar field names, and a description that explains the parameters all improve a tool's odds. The tools' order in the list matters too, and you need to check it by swapping the order.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
What was changed (one at a time, everything else fixed):
S: server name → weak effect, position often decides
T: tool name → almost no influence
D: description → +, if it explains the parameters
P: parameter schema → the strongest and most stable effect
What wins in the schema (P):
• separate top-level fields > fields inside an object
• separate owner + repo > one "owner/repo" string (if the request gives them separately)
• familiar names (to, location) > "clever" ones (recipient_id)
Position in the list: among equal tools, the first one is picked more often
Example in Practice
Task: You're automating a Shopify store and have connected your agent (Claude Code or Cursor) to two MCP tools for creating an order in your CRM. You wrote one of them; the other came with a third-party server. The agent almost always picks the third-party one, and yours just sits there. You need to figure out what in your schema is holding it back and fix it.
Prompt:
You are a reviewer of MCP tool metadata. Two tools do the same thing.
The agent almost always picks tool B. Find where our tool A loses at the selection stage.
Tool A (ours):
name: crm-internal_create_order
description: Creates an order in the CRM.
parameters: { "create_order_request": { "customer_id": string, "items": array, "delivery_city": string } }
Tool B (third-party):
name: shop-server_create_order
description: Creates an order. customer_id is the customer's phone or email, items is a list of SKUs with quantities, city is the delivery city.
parameters: { "customer_id": string, "items": array, "city": string }
Check point by point:
1. Are the parameters grouped into an object even though they could be flat?
2. Are there nonstandard field names (for example, with an _id suffix or rare synonyms)?
3. Does the description explain the parameters and what gets returned?
4. Does the order of the tools in the list matter?
Give a rewritten version of A: flat parameters, familiar names, a description that explains each field.
Suggest 6 test requests and an order-swapping scheme to verify the result.
Result: The model will break down both schemas against the four points. Most likely it will flag A's wrapper object, the nonstandard field name, and the sparse description. Then it will produce a rewritten tool A with flat fields and a parameter description. At the end there'll be a test plan: a set of requests and runs with the tools in different orders.
Why It Works
The weakness. The model can't see the tool's code. All it has is the name, the description, and the schema. Similar tools often have nearly identical names, so there's nothing to choose by. Then the model leans on whatever it can: the order in the list, how a field "sounds."
The strength. The model is good at reading a schema as a signal of "does this tool fit my request." The field to looks like an email address, recipient_id like an internal identifier. Separate owner and repo fields map onto a request like "repository X belonging to user Y" with no extra conversion.
How to use it. Make the schema look like what naturally follows from the request. Flat fields, familiar names, and a description that spells out the parameters reduce the model's "matching friction."
Control knobs:
- Parameter structure → remove the wrapper object, split compound fields.
- Field names → use the most common ones in the category (to, location).
- Description → add what each field means and what the tool returns.
- Tool order → put the one you want first, but verify by swapping.
- Server and tool names → don't sink effort into them; the effect is weak and unstable.
Prompt Template
The paper has no ready-made prompts. The template below is assembled from its findings as a review checklist.
You are a reviewer of MCP tool metadata. Compare tools that do the same thing.
Goal: understand why the agent picks {competitor_tool} instead of {our_tool}.
Tool 1:
name: {name_1}
description: {description_1}
parameters: {schema_1}
Tool 2:
name: {name_2}
description: {description_2}
parameters: {schema_2}
Typical user request: {example_request}
Check:
1. Grouping: are there parameters inside an object that could be moved to the top level?
2. Names: are there nonstandard field names (_id suffix, rare synonyms)?
3. Compound fields: is there a single string that could be split into separate fields if the request gives them separately?
4. Description: does it explain each parameter and the result?
5. Order: how does the choice change if the tools swap places?
Output:
- a table of differences;
- a rewritten schema and description for {our_tool};
- {number} test requests and a test plan with order swapping.
Fill in:
- {our_tool} and {competitor_tool} — the two tools competing;
- the actual schemas and descriptions;
- a typical user request.
Limitations
⚠️ Only for similar tools: All effects were measured where any candidate could fulfill the request. If the request needs a feature only one tool supports (for example, CC'ing a recipient), the model picks the right one regardless of order.
⚠️ Depends on the specific names: The effect depends heavily on the words, not on the idea of "renaming" itself.
recipient_idlost badly, whilereceiver, a word not used in the requests, stayed competitive. There are no universally "good" names; you need to test.
⚠️ Depends on the request format: If the user writes the whole path (
owner/repo), the preference for separate fields weakens, and for one model it flips the other way.
⚠️ Position often decides everything: When the only differences are in the names, almost all models take the first tool. With two candidates this is especially noticeable. Without testing different orders, it's easy to mistake position for quality.
⚠️ Models aren't uniform: Not all models behave the same way. DeepSeek showed no clear schema preference on one task, and Qwen often chose purely by position, so its metadata effects are undetermined.
⚠️ Test conditions: The models' thinking mode was turned off, there were five tasks, and the requests were synthetic. For a real agent with long context and reasoning, the effect may differ. Part of the paper's text (joint experiments and conclusions) is truncated in the available version.
How They Tested It
The researchers first pulled the metadata of 367,174 MCP tools and noticed something odd. For example, 169 tools named send_email use 78 different parameter sets. Their names and descriptions are nearly identical; what differs is the fields (to versus recipient_id). You can't compute the schema's influence from this data, because everything else about the tools differs too. So they set up a controlled experiment.
For five tasks (sending an email, weather, creating an issue, an order, a pull request), they made versions of tools that differ in exactly one field: server name, tool name, description, or parameter schema. Each of five models (GPT-5.4 mini, Claude Sonnet 4.6, Gemini 3.5 Flash, DeepSeek V4 Pro, Qwen3.7-Plus) got 50 requests and 2, 3, or 5 candidates. List positions were balanced by cyclic rotation. A conditional logit model was used to estimate the effect "after adjusting for position."
The result: of 28 estimated numerical schema effects, 23 are statistically significant, and 22 of those are positive. The schema effect is roughly twice the server-name effect. The most telling contrast: recipient_id versus receiver. The first tanks selection to 1–10%, the second keeps it at 35–51%. This shows the model isn't just hunting for matching words: it "understands" what the field means. The decisive test was this: when the request asks for CC and only one schema supports it, all five models chose that one, even when it was listed second. In other words, the schema works as a "does this tool fit" check, not just as formatting instructions for arguments.
The unexpected part: names, which everyone pours effort into, decided almost nothing. In name comparisons, models picked the first tool 79–96% of the time. The practical rule that follows is simple: measure selection with the tools in different orders, or you're measuring position.
Adaptations and Extrapolations
💡 Adaptation for guarding against selection "hijacking": if you connect third-party MCP servers, check whether a third-party tool is beating yours thanks to a more "convenient" schema.
Here are two tools that do the same thing: {tool_1}, {tool_2}. Assess which one's schema is more "attractive" to the model based on: flat fields, familiar names, parameter explanations in the description. Show which differences could make the agent pick one of them regardless of quality.
🔧 Technique: order swapping → an honest selection test
Run the same 6–10 requests while changing the order of the tools in the list (A,B and B,A). If a tool only wins when it's first, its metadata isn't doing the work — it's a position effect. Verify any change to a description or schema by swapping.
Resources
- Which Metadata Matters for LLM Tool Selection in MCP? Evidence from Controlled Factor-Level Interventions
- Authors: Xiaofan Li, Xing Gao (University of Delaware), Fengchun Qiao (University of South Florida)
- Related work cited in the study: an analysis of metadata for 367,174 MCP tools (Li & Gao, 2026); tool-selection biases (Blankenstein et al., 2026); the impact of descriptions on tool use (Faghih et al., 2025); the quality of MCP tool descriptions (Hasan et al., 2026)