When building automated response agents for enterprise security platforms, we often rely on MCP tools to perform various types of ban operations, such as banning a single IP, domain, file hash, MAC address, etc. However, during actual operation, large models often “infer” that these tools support batch input, leading to a common mistake:

Clearly, the tool expects a single string parameter, but the large model concatenates multiple IOCs into <span>ip1,ip2,ip3</span> and tries to pass it all at once.

Even the most advanced large models, despite explicit instructions in the system prompt prohibiting batch operations, and even stating “unless the tool explicitly supports batch, it must be executed one by one,” will still attempt to “optimize execution.” This is evidently a very stubborn problem.

After multiple tests, tuning prompts, and adding rules, I found a very effective and simple solution:

Core Technique: Let the Tool Name Itself Express “Single Entry Only”

For example:

• <span>block_ip</span> (easily misjudged as possibly supporting batch)

Change it to:

• <span>block_single_ip_address</span>

The model’s understanding will shift from:

“This is a tool for banning IPs, perhaps it can do it in batch.”

To:

“This is an action that can only ban one IP.”

Once the action name includes clear semantics like single / 单条 / 单对象 / 单值, the large model will automatically comply and will not concatenate multiple IOCs into a single parameter.

Why the Impact of Tool Names is Stronger than Prompts?

From a large number of test results, the behavior of large models when calling MCP tools follows a priority:

1. Tool Name (highest weight)
2. Tool Parameter Structure (e.g., array / string)
3. Tool Description Text
4. Logical Rules in System Prompts
5. Contextual Inference (experience, default habits)

In other words:

• The tool name is viewed as “the semantic definition of the function”
• The clearer the name, the more accurate the model’s inference
• If the name is ambiguous, the model will complete the behavior based on experience (e.g., default support for batch)

Therefore, even if the prompt emphasizes “execute one by one,” if the action name is <span>block_ip_address</span>, the model may still think:

“Many firewall APIs support batch, submitting in bulk is more efficient, let me optimize this for you.”

But once you change the name to:

• <span>block_single_ip_address</span>
• <span>block_one_ip</span>
• <span>block_exactly_one_ip</span>

The model will no longer infer, as the semantics are locked.

Practical Example

Incorrect Example (Prone to Batch Misuse)

Tool Name: block_ip_address
Param: ip_address (string)

The model might generate during invocation:

"ip_address": "8.8.8.9,1.1.1.2,203.0.113.1"

Correct Example (Completely Avoids Batch Misuse)

Tool Name: block_single_ip_address
Param: ip_address (string)

The model will strictly generate during invocation:

"ip_address": "8.8.8.8"

Even if the user inputs multiple IOCs, the model will automatically call the tool one by one, without concatenating strings.

Why is This Method More Effective than Prompts?

Because the tool name is the highest label for the model at the level of “code behavior inference.” It carries more weight than the rules described in the prompts.

For large models:

• Prompts = Usage Documentation
• MCP Tool Name = Real Definition of API

In scenarios where the model calls APIs, the semantics of the API take precedence over natural language descriptions.

Scope of Application

This technique is not only applicable to IP bans but also to:

• Domain bans<span>block_single_domain</span>

• File hash bans<span>block_single_file_hash</span>

• MAC address bans<span>block_single_mac_address</span>

• DNS sinkhole<span>add_single_sinkhole_record</span>

• URL blocking<span>block_single_url</span>

Any action you do not want the model to submit in batch can adopt this method.

Conclusion

In automated threat response agents, large models are prone to batch inference behavior, especially with security-related APIs. This often leads to parameter format errors, incorrect actions, and failures in submitting multiple targets at once.

Through practical verification:

The simplest, most stable, and effective way is: directly constrain the model’s behavior through naming in the MCP tool name.

For example:

• <span>block_ip_address</span> → ❌ Prone to batch misuse
• <span>block_single_ip_address</span> → ✅ Completely avoids batch misuse

The semantics of the tool name guide far more strongly than the constraints of prompts. This is a very practical technique worth adopting when building automated response agents.

If you are interested in learning more about us, feel free to click“Read the original text”