Wrapping Untrusted MCP Tools with Lunar MCPX Tool Customization

Not all AI tools are built equal, and not all of them are built by people you know or trust. As the MCP (Model Context Protocol) ecosystem grows, more community-developed open source servers are popping up with tools for everything from weather data to translation. While this is great for speed, it is not so great if you care about data security, output reliability, or just knowing what’s really happening under the hood.

In our previous post, we showed how the Lunar AI Gateway can enforce security policies and validate outbound calls using Lunar.dev Flows before they leave your system. That layer governs traffic behavior in real time. But agent behavior starts earlier, at the point where tools are discovered and selected.

That’s where MCPX Tool Customization comes in. It lets you reshape tool definitions themselves: override parameters, lock inputs, redact outputs, and expose only safe variants, before a single request is made.

Why Tool Customization?

MCPX Tool Customization is a powerful feature which lets you reshape and enforce how AI agents interact with external tools, especially when those tools come from untrusted or community sources.

When an agent requests available tools, MCPX pulls the upstream manifest and applies your configured policies. This process enables you to:

• Filter or remove tools you don’t want exposed
• Clone and rename tools to suit specific use cases
• Lock input parameters using overrideParams
• Redact or modify return values
• Create safe, preconfigured variants (child tools) from a single base tool

These child tools inherit the behavior of the original but expose a controlled interface to the agent. This gives you a way to enforce behavior on tools you don’t control, without forking their code or managing your own mirror server.

This is particularly useful when you're integrating with community-run MCPs or third-party APIs exposed through an MCP layer. You might want the functionality, but not the default behavior, especially when agents are selecting tools autonomously and generating input parameters on the fly.

Use Case: Enforcing Timezone Consistency

Let’s say you want your agent to fetch the current time, but always in the same timezone regardless of what timezone you are located in. You’ve found a public MCP server that exposes a tool called get_current_time and accepts a timezone parameter. But you want to make sure the agent can only query specific, pre-approved timezones like "Europe/Paris" or "Asia/Tokyo" and not any arbitrary values.

With MCPX Tool Customization, you can create safe, locked-down versions of that tool. The configuration below goes directly into your app.yaml file:

toolExtensions:
  services:
    time:
      get_current_time:
        childTools:
          - name: get_current_time_in_paris
            description:
              append: "This version always uses the Paris timezone."
            overrideParams:
              timezone: "Europe/Paris"
          - name: get_current_time_in_tokyo
            description:
              append: "This version always uses the Tokyo timezone."
            overrideParams:
              timezone: "Asia/Tokyo"

‍‍This creates two new tools, get_current_time_in_paris and get_current_time_in_tokyo , each wrapping the original with a locked input.

This gives you agent-friendly flexibility (the LLM still has tool choices) without exposing you to unpredictable behavior. You can scale this out to cover any fixed list of timezones, locations, or use cases, each with their own name, description, and behavior, while still relying on the same underlying upstream tool.

What's Happening Under the Hood

When the agent requests a list of available tools, MCPX pulls in the upstream manifest and applies your configured customizations.

These child tools inherit the underlying behavior of the original, but present themselves differently to the agent. That gives you a lot of surface area to shape how the agent interacts with the outside world even when you’re relying on untrusted, black-box infrastructure.

This is perfect for creating environment-specific tools, pre-configured workflows, or simplified interfaces because:

1. One tool becomes many: A generic tool spawns specialized variants
2. Fixed parameters: Each variant has pre-configured, locked inputs
3. Transparent to users: Extended tools appear just like any other
4. No code changes: Original tools stay untouched

Conclusion: Why This Matters

Security isn’t just about access control, it’s about shaping intent. As AI agents become more autonomous and integrate a growing mix of third-party tools, you need guardrails not just on which tools can be called, but how.

MCPX Tool Customization gives you those guardrails from inside the MCP layer. It lets you lock down inputs, hide outputs, create safer tool variants, and control how external functionality is exposed without rewriting code, forking upstream servers, or deploying additional infrastructure.

We walked through a simple example, but the same pattern can be used to constrain search queries, enforce filters, strip sensitive fields, or split a single tool into multiple safe-use variants. All of this is All of this happens behind the scenes, without requiring the agent to adapt; resulting in a cleaner, safer, and more predicable tool interface.

All of this happens behind the scenes, without requiring the agent to adapt.

For developers and security engineers, that means you can safely experiment with the fast-growing MCP ecosystem, bringing you one step closer to adopting it safely across your organization. Researchers can expose tools that stay within task-specific limits. And teams can move faster while knowing that even untrusted tools are wrapped in your own rules.

Setup is simple: write a bit of YAML, drop it into your app.yaml, and you’re done.