MCP Server - Meta Tool mode

Overview

The meta-tool architecture allows an AI aware client to work with CAST Imaging through two general-purpose tools rather than loading (around 50) individual tools in advance.

When an AI client (such as Claude Code, GitHub Copilot, or Codex) connects to the CAST Imaging MCP Server, it must first determine which operations are available. It does so by loading a description of every available tool into its working memory before any request is made.

The MCP Server exposes approximately 50 tools as of now - for listing applications, retrieving transactions, inspecting object details, and so on. Loading all of these consumes a substantial portion of the client’s limited working memory (its “context”). That memory is then unavailable for the analysis and reasoning the client is expected to perform. The effect is compounded when additional tool sets are connected at the same time.

The meta-tool architecture addresses this by replacing those 50 descriptions with two. The client begins with a minimal footprint and retrieves the detail for a specific capability only at the point it is required.

How it works

The model can be understood through an analogy of a restaurant.

• Classic mode (full) is comparable to presenting every guest with the entire menu, the recipe for each dish, and the complete ingredient list - all at once, before any selection has been made. The approach is thorough but unwieldy, and most of the information goes unused.
• Meta-tool mode (intents) is comparable to providing each guest with a concise menu and an attentive waiter. The guest reviews the menu, asks the waiter about the one or two dishes of interest, and then places an order. The kitchen is identical; only the manner of navigating it has changed.

In meta-tool mode the client is provided with three elements:

• A menu available on demand. A categorised list of every capability the server offers (for example, “Portfolio Discovery”, “Transactions & Data Graphs”, and “Quality Insights”). The client consults this list only when required, so it carries no cost until it is used.
• A “describe this capability” tool. Once a capability of interest has been identified on the menu, the client requests its precise details - the information the capability requires and an example of its use.
• A “run this capability” tool. With those details established, the client invokes the capability with the appropriate inputs and receives exactly the same result it would have received in classic mode.

The essential point is that the underlying capabilities are identical. Nothing is removed or diminished. The client simply discovers and invokes those capabilities through a leaner, two-step path rather than having every description pre-loaded.

Example

Consider the request: “Show the transactions for the application MyApp related to checkout.” In meta-tool mode the client performs the following steps internally:

1. Consults the menu and locates a capability named transactions.
2. Requests the details of transactions and learns that it requires an application name and accepts an optional filter.
3. Invokes transactions for MyApp with a checkout filter and returns the result.

The result is identical to the one classic mode would produce. The difference is not visible to the user and serves only to make more efficient use of the client’s working memory.

Benefits and trade-offs

Benefits

• The client retains significantly more free working memory, which can be applied to interpreting the request and analysing the codebase.
• The approach performs well when several tool sets are connected simultaneously.
• It scales as further capabilities are added to the server over time.

Trade-offs

• The client performs a small number of additional exchanges to look up a capability before running it. Individual requests may therefore feel marginally slower, even though the overall session is leaner.
• The approach depends on the client being capable enough to follow the look-up-then-run pattern. Modern, high-capability models handle this reliably; smaller or older models may occasionally do so imperfectly.

Activation

The mode is controlled by a single setting, MCP_TOOL_SURFACE_PROFILE available in the app.config (Docker - see MCP Server installation on Linux via Docker) or configuration.conf file (Microsoft Windows - see MCP Server installation on Microsoft Windows):

The MCP Server must be restarted after the value is changed. Once the client reconnects, it will be presented with the two meta-tools in place of the full list.

Confirming that the mode is active

After the server is switched to intents and the client reconnects, the list of tools the client reports for CAST Imaging should contain two entries in place of the full list of individual capabilities, these two tools are:

• get_structural_search_function_syntax - the “describe this capability” tool.
• run_structural_search_function - the “run this capability” tool.

The presence of these two tools confirms that meta-tool mode is active. The presence of the full list of capabilities indicates that the server remains in classic full mode.

Hiding specific tools (optional)

In meta-tool mode, individual tools can be hidden from the client - for example, those considered sensitive or otherwise undesirable for use. This is configured through the MCP_INTENTS_HIDDEN_FUNCTIONS setting, which accepts a comma-separated list of capability names:

MCP_INTENTS_HIDDEN_FUNCTIONS="scan_folder_as_application,manage_object_tags"

Hidden capabilities are removed from the menu and cannot be run. The setting is empty by default, in which case all capabilities are exposed.

Summary

• Meta-tool mode (intents) is an alternative to the classic full toolset.
• It exposes two general-purpose tools and an on-demand menu in place of every tool at once, conserving the client’s working memory.
• The capabilities themselves are unchanged; only the manner of their discovery and invocation differs.
• It is activated with MCP_TOOL_SURFACE_PROFILE=intents, followed by an MCP Server restart.
• Specific capabilities can optionally be hidden with MCP_INTENTS_HIDDEN_FUNCTIONS.
• Classic mode (full) remains the default for any deployment that does not opt in.