MCP Server 3.1 - Meta Tool mode

Overview

The meta-tool architecture allows an AI aware client to work with CAST Imaging through a small set of 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 a small set of general-purpose meta-tools. 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

Each MCP server which offers a tool surface has its own profile setting. Meta-tool mode (intents) is the default for both:

Both accept the same two values:

Where you set them depends on the installer:

• Linux via Docker - in the .env file. Apply the change with ./run.sh --restart. See MCP Server 3.1 installation on Linux via Docker.
• Microsoft Windows - in configuration.conf before the installation, or in the deployed app.config file afterwards. Restart the service to apply the change. See MCP Server 3.1 installation on Microsoft Windows.

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

The Text2Cypher MCP server does not use a tool surface profile: it exposes its tools directly.

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 a small set of discovery and dispatcher meta-tools in place of the full list of individual capabilities. Structural and semantic searches use separate discovery (“describe this capability”) and execution (“run this capability”) dispatchers.

When semantic search is enabled, the following four meta-tools are exposed:

• get_structural_search_function_syntax - describes the structural search capability.
• run_structural_search_function - runs the structural search capability.
• get_semantic_search_function_syntax - describes the semantic search capability.
• run_semantic_search_function - runs the semantic search capability.

The presence of these meta-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. As with the profile itself, this is configured per MCP server, and each setting accepts a comma-separated list of capability names:

STRUCTURAL_MCP_INTENTS_HIDDEN_FUNCTIONS="scan_folder_as_application,manage_object_tags"
SEMANTIC_MCP_INTENTS_HIDDEN_FUNCTIONS=

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

Summary

• Meta-tool mode (intents) is the default; classic mode (full) is opt-in.
• It exposes a small set of general-purpose meta-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.
• The profile is set per MCP server, with STRUCTURAL_MCP_TOOL_SURFACE_PROFILE and SEMANTIC_MCP_TOOL_SURFACE_PROFILE, followed by an MCP Server restart.
• Specific capabilities can optionally be hidden with STRUCTURAL_MCP_INTENTS_HIDDEN_FUNCTIONS and SEMANTIC_MCP_INTENTS_HIDDEN_FUNCTIONS.