In Model Context Protocol (MCP) systems, LLMs select tools from metadata rather than from their implementations. Names and descriptions summarize what a tool does, while the parameter schema specifies the fields a tool accepts and how they are organized. Our analysis of metadata for 367,174 MCP tools reveals substantial schema variation among functionally similar tools. Many of these tools share names and similar descriptions but expose different parameter schemas. This raises a key question: can parameter-schema differences influence tool selection before any call is made? We study this question through controlled metadata interventions across five LLMs and five tasks. Each comparison changes exactly one metadata factor (server name, tool name, description, or parameter schema) while keeping the others fixed. We balance tool positions and use conditional logistic regression to estimate position-adjusted effects. We find that: (1) parameter-schema changes produce the largest and most consistent selection shifts among the tested interventions. Models tend to favor separate top-level parameters over grouped or composite forms. (2) Descriptions that explain parameters also tend to increase selection, while name effects are weaker and less consistent. (3) Targeted comparisons show that schema effects depend on the specific parameter names and on how the request represents the same information. When only one schema satisfies an explicit request requirement, all five models select the compatible tool despite position preferences. These results show that parameter schemas influence not only how tools are called, but also whether they are selected. For MCP developers and evaluators, schema design and tool ordering can therefore affect which implementation is invoked even when functionality is unchanged.
Figures & tables
Figure 1: Overview of the study (full MCP workflow in Appendix Figure 10 ). (a) Tools that share a name often take different parameters: the 169 send_email records in our dataset use 78 distinct parameter sets. (b) In each comparison, the LLM receives the same request and candidate tools that differ in exactly one metadata field: server name (S), tool name (T), description (D), or parameters (P). The host joins S and T into a single name field, and a two-letter server suffix only distinguishes the candidates. Here, Tool B renames to to recipient_id . (c) Selection rate of Tool B in two-tool comparisons, with one dot per LLM. Renaming to to recipient_id lowers it to 1–10%, whereas renaming it to receiver keeps it at 35–51%, close to chance.
Dimension
Task
vhigh
vlow
Naming
Send Email
to
recipient_id
Get Weather
location
input
Structuring
Create Issue
(owner, repo, ...)
params_dict
Place Order
(customer_id, ...)
create_order_requests
Decomposition
Create Pull Request
(owner, repo)
repository
Table 1: Parameter variations across the five tasks.
Task
Model
S
T
D
P
Send Email
GPT-5.4 mini
2.39
1.98
1.37
4.13
Claude Sonnet 4.6
1.74 †
1.24 †
0.00 †
4.56
Gemini 3.5 Flash
1.54
1.62
0.55
7.88
DeepSeek V4 Pro
0.01 †
− 0.83 †
2.49
3.03
Qwen3.7-Plus
5.64 †‡
− 0.30 †
5.64 †‡
11.77 †
Get Weather
GPT-5.4 mini
− 0.89
0.38 †
1.02
4.44
Table 2: Conditional-logit estimates of metadata effects on tool selection with three candidate tools.
Figure 2: Metadata effects on tool selection with two and five candidate tools for (a) Send Email and (b) Place Order. Cells show conditional-logit coefficients ( β ) for vhigh vs. vlow , adjusted for presentation position. S: server name; T: tool name; D: description; P: parameter schema. Both panels use the same color scale. † indicates that the 95% confidence interval includes zero.
Figure 3: Two-tool selection rates for Place Order. Each comparison contains one vhigh and one vlow , with 100 valid trials per model and factor. Blue bars show the rate of selecting the vhigh candidate; orange bars show the rate of selecting the first tool. The dashed line marks the uniform-choice baseline of 0.5 for both rates.
Figure 4: Joint metadata and position effects in the two-tool factorial experiment (Send Email). Bars show conditional-logit coefficients ( β ) for vhigh vs. vlow in each field and for position 1 vs. 2, estimated jointly; parameter effects in blue. † : 95% confidence interval includes zero.
Figure 5: Two-tool selection rates under changes to parameter names, field descriptions, and task requirements. (a) Send Email: rate of selecting the tool with the renamed parameter; other parameters are unchanged. (b) Place Order: rate of selecting the tool with a single object parameter rather than separate named parameters. (c) Send Email: rate of selecting the tool with an additional optional cc parameter, with and without an explicit CC request. Dashed lines mark the 50% baseline.
Appendix figures & tables8 assets
Supplementary material from the paper’s appendix.
Appendix
Figure 6: Tool names, description composition, and parameter sets in the Send Email cluster.
Task
Factor
vhigh (1)
vlow (0)
Send Email
S
email-server
message-server
T
send_email
send_gmail
D
Parameter and return explanations
Brief description
P
to, subject, body
recipient_id, subject, message
Get Weather
S
weather-server
utility-server
T
get_weather
weather_current
Appendix
Table 3: Metadata variants for the five tasks. Server names are shown without the candidate-specific suffix. Description entries summarize the content; the full text appears in Appendix B.3 .
Figure 7: Observed three-tool selection rates for Create Issue across models and metadata factors. Blue bars show the vhigh selection rate and orange bars the position-1 selection rate; solid and hatched bars denote the 1H+2L and 2H+1L compositions, respectively. Each bar summarizes up to 150 trials. Under uniform choice, the vhigh baseline is 1/3 for 1H+2L and 2/3 for 2H+1L, and the position-1 baseline is 1/3 for both.
Model
Tools
S
T
D
P
GPT-5.4 mini
2
4.72 †
1.08
0.22 †
8.15 †
3
2.39
1.98
1.37
4.13
5
1.79
1.69
0.63
5.17
Claude Sonnet 4.6
2
0.00 †
4.72 †
0.00 †
7.79 †
3
1.74 †
1.24 †
0.00 †
4.56
5
1.35
0.07 †
0.12 †
3.15
Appendix
Table 4: Conditional-logit estimates of metadata effects for Send Email with two, three, and five candidate tools.
Table 5: Conditional-logit estimates of metadata effects for Send Email by candidate composition.
Figure 8: Effects of parameter names and field descriptions on tool selection in Send Email. Cells show the percentage of valid trials in which the model selects the base tool, which uses to , subject , and body . The other tool renames to to recipient_id (Recipient name), body to message (Body name), or both (Both names). With desc. gives corresponding fields of both tools the same descriptions; Without desc. omits field descriptions. The tool-level description is the same in all conditions, and 50% indicates no preference.
Figure 9: Effects of explicit CC requests on tool selection in Send Email when the extended tool renames to . The base tool uses to , subject , and body ; the extended tool uses recipient_id , subject , body , and an optional cc field. Neither tool has field descriptions. Queries either do not mention CC (CC unspecified) or explicitly request CC recipients (CC required). Cells show the percentage of valid trials in which the model selects the extended tool. Valid trials contain exactly one call to a candidate tool, regardless of argument validity; each condition has 92–100 valid trials out of 100 (e.g., Qwen’s 100% under CC required is 97 of 97 valid trials).
Figure 10: Tool selection in MCP. (1) For each connected server, the MCP host uses an MCP client that calls tools/list to obtain each tool’s name, description, and input schema. (2) The user sends a request. (3) The host joins server and tool names into a single name field and sends the request with all tools to the LLM. (4) The LLM, which sees only this metadata, selects a tool, fills its arguments, and returns the tool call to the host; this is the step we study. (5) The host invokes the selected tool by sending tools/call to its server through the corresponding client, and (6) the result is returned to the user. Descriptions are omitted from the tool list for space.
Large Language Models (LLMs) with tool-calling capabilities have demonstrated remarkable potential in executing complex tasks through external tool integration. The Model Context Protocol (MCP) has emerged as a standardized framework for connecting LLMs to diverse toolsets, with individual MCP servers potentially exposing dozens to hundreds of tools. However, current implementations face a critical scalability challenge: providing all available tools to the LLM context results in substantial token overhead, increased costs, reduced accuracy, and context window constraints. We present a semantic tool discovery architecture that addresses these challenges through vector-based retrieval. Our approach indexes MCP tools using dense embeddings that capture semantic relationships between tool capabilities and user intent, dynamically selecting only the most relevant tools (typically 3-5) rather than exposing the entire tool catalog (50-100+). Experimental results demonstrate a 99.6% reduction in tool-related token consumption with a hit rate of 97.1% at K=3 and an MRR of 0.91 on a benchmark of 140 queries across 121 tools from 5 MCP servers, with sub-100ms retrieval latency. Contributions include: (1) a semantic indexing framework for MCP tools, (2) a dynamic tool selection algorithm based on query-tool similarity, (3) comprehensive evaluation demonstrating significant efficiency and accuracy improvements, and (4) extensibility to multi-agent and cross-organizational tool discovery.
The Model Context Protocol (MCP) standardizes how servers expose data and tools to Large Language Models (LLMs). A common server design embeds frequently used reference data, such as identifier lookup tables, directly in the server instructions: the system-prompt text a server hands to the host application. When a query concerns an entry of the embedded table, the model can act on it immediately instead of re-discovering the same information through a search tool. We test whether client LLMs actually consume such instruction-embedded data, reporting a 54,000-trial study across 24 LLMs (9 Claude, 6 Gemini, 9 GPT) on a production legal-information MCP server. A diagnostic condition that removes the competing search tool shows that failures are dominated by behavioral preference rather than missing capability. With search unavailable, 23 of 24 models read the embedded data reliably (hit ratio at least 98%); with a search tool merely present, 9 models drop below 15%. A 2^3 factorial analysis of three instruction-level interventions reveals strong interaction effects: combining all three restores at least 86% for 20 of 24 models, but individual interventions can backfire for specific model families. Per-server prompt engineering is therefore a workaround rather than a fix; we argue that MCP host applications should provide an explicit mechanism that places server instructions ahead of tool selection in the client LLM's deliberation.
Minhan Cho, Soyoung Park, Kihyeon Jeong +3
Remember & Company AI Lab · Sungkyunkwan University · National Assembly Research Service +2
Large language model (LLM) agents invoke external tools to retrieve and reason over information beyond pretrained knowledge. The Model Context Protocol (MCP) standardizes how such tools are surfaced, and a proxy MCP server aggregates many backend servers behind a single endpoint providing a secure, governable chokepoint for authentication, policy enforcement, and observability. This architecture creates two compounding challenges: a context-engineering bottleneck where full tool schemas saturate the model context window before any user query, and a tool discoverability barrier where users and agents cannot identify the best tool among 2,000+ indexed tools across 200+ MCP servers. Prompt caching reduces reprocessing cost but neither frees context capacity nor improves accuracy. We present SCOUT (Selective Context Optimization for Universal Tooling), which reframes tool exposure as a context-selection problem, injecting only tools relevant to the current step. SCOUT surfaces two MCP meta-tools -- tool_search and execute_tool -- where tool_search performs hybrid retrieval, fusing BM25 sparse matching with dense vector search via Reciprocal Rank Fusion to return the top-k relevant tools. Backed by zero-downtime catalog update pipelines, SCOUT resolves both context saturation and tool discovery challenges. In production at PayPal, SCOUT reduces MCP tool-token consumption from 140.2k tokens (70.1% of context) to 1.3k tokens (0.8%), a 99% reduction, cutting per-query inference cost at enterprise scale. Because SCOUT is surfaced as standard MCP tools, it is model-agnostic and requires no client-side modifications.