In a previous article (Convert your decisions and models to tools, En-MASse) we introduced mas-mcp-toolmaker, a Python package to automate tool definitions in a Model Context Protocol (MCP) server. These tools definitions are tied to published Micro Analytic Service (MAS) modules.
Users benefit by accessing customised, compact and relevant toolsets for their agentic interactions.
In this article, we address an additional point. Tool development and tool consumption (whether by agents or the people who design such agents) are distinct activities and involve different personas, that of the "builder" and the "runner" respectively.
You need automated tool discovery mechanisms to bring new product to market seamlessly. New products, in this case, being updated MCP servers with new, modified or pruned tools.
Approach
To accomplish this, we rely on a fundamental architectural design underpinning the Analytics Life Cycle, the unified SAS Viya analytics platform. SAS Viya comprises several applications. SAS Intelligent Decisioning and SAS Model Manager, which provide MAS-published modules, tend to operate at downstream phases (Deploy) in the Analytics Life Cycle. Whereas, SAS Studio (or the SAS Data and AI Studio to call it by its new name) is associated more with upstream activities (data) such as data pipelines, data engineering and ETL. Studio provides useful functionality to define, deploy and schedule jobs. You use them to build a daily tool aggregation flow as shown in the following diagram. Thus, this typically upstream application, Studio, satisfies the demands of daily orchestration to discover, aggregate and create tool servers meant for downstream activities.
Orchestration
The diagram represents a SAS Studio Flow charting out the process in three swim lanes.
1. Install dependencies : an optional swim lane, this creates a virtual environment and installs the mas-mcp-toolmaker Python package used for tool discovery and aggregation. Virtual environments offer isolation, ephemeralism and portability. A virtual environment enables you to run this flow in any SAS environment where Python is available to SAS Studio, required packages are installed at run time and only take effect for the duration of the SAS Studio Flow.
2. Create MCP Server Scripts : as the main swimlane in this flow, this is where you call methods for tool discovery, aggregation, filtering and output. Individual Python program nodes represent the creation process for each MCP server. Here's what happens within a Python node.
# Set Daily Tool Aggregation (DTA) location
dta_location = "/mnt/viya-share/data/daily_tool_aggregation"
server_name = "viya4-stable-all-tools"
# Imports
from mas_mcp_toolmaker import MASModule
import os
# Set Environment Variables
os.environ["VIYA_HOST"]= os.getenv("SAS_SERVICES_URL")
os.environ["VIYA_ACCESS_TOKEN"] = os.getenv("SAS_CLIENT_TOKEN")
# Discover and aggregate
masm = MASModule()
# Script Server File
masm.script_ram_server(os.path.join(dta_location,f"{server_name}-ram.py"))
User-specified parameters are the MCP server script's output location and a name for the script, which is useful when defining multiple servers. The rest of the program imports the package, initialises a MASModule class and outputs a server script of the specified name. Note how we define environment variables used by the module to authenticate with MAS. SAS Studio's availability in a unified Viya environment is beneficial because predefined environment variables such as the SAS_SERVICES_URL and the SAS_CLIENT_TOKEN can be used (read this article to learn more) to authenticate and retrieve information from other services, one example being MAS.
The above code snippet referred to the first Python node in the flow which aggregates all available tools (if that's what you want to do), but, notice that in subsequent nodes you can apply filters to create smaller, more compact and specific MCP servers. The server name parameter can be changed to provide a descriptive name for those specific files.
# This section creates an MCP server only for categorisation tools
# Define server name
server_name = "viya4-stable-phonereview-tools"
# Imports
import copy
# Create a filter
masm_filter_1 = copy.deepcopy(masm)
masm_filter_1.filter_modules({'module_description': 'categorises'})
# Script server file
masm_filter_1.script_ram_server(os.path.join(dta_location,f"{server_name}-ram.py"))
3. Revert environments: another optional swim lane to be used only if you chose to run earlier steps in a virtual environment. This restores the default Python environment in Studio thus keeping your configuration clean.
Versioning
The flow can also support versioning to identify if a daily version has changed from the previous and if so, affords opportunity to implement version control. Version control helps rollback to an earlier MCP server version should problems be encountered with the new version.
Monitoring
Note and use the Flow Status Handling feature. A fairly recent addition to Studio functionality, status handling helps you write the status of all flow runs to a dataset for monitoring processes. You'll find this useful when monitoring daily runs of the flow.
Self-service configuration
Also note use of the `script_ram_server` method. `mas-mcp-toolmaker` offers two options to generate MCP server scripts, in stdio and RAM (SAS Retrieval Agent Manager). You can add additional parameters in the Python script to capture whether the consumer requires an stdio or RAM-optimised server, and call the appropriate method.
Extensibility
The next time a consumer requests a new server with pre-specified tools, extend the flow by adding and additional Python block / node and changing parameters to accommodate the new request. The new parameters would correspond to:
1. The name of the server
2. A filter condition , or an explicit specification of the tools requested
3. Whether a stdio or RAM-optimised server is required
Resultant server scripts can be routed to the appropriate consumer who uses them in their downstream application.
The Bigger Picture
Automated tool discovery and creation isn't just about a package, isn't just about automation, and it most definitely is not just about a nearsighted focus on one module (Micro Analytics Service) or a specific part of the AI lifecycle such as decisioning or model execution.
The bigger picture lives in the world of DevOps. Considering the roles of "builder" (the developer) and "runner" (the consumer), let's look at this as a model of treating AI agents as consumers and using DevOps practices (comprising build, automation, testing and continuous integration among others) to satisfy needs of those agents. In short, provide agents the tools they need to do their job.
Data pipelines and workflows like those facilitated by SAS Studio Flows (and supporting components such as SAS and Python code, scheduling and monitoring) help us implement DevOps for agent tool servers in an approachable and configurable manner.
The example we provide here deals with only parts of the DevOps cycle but can easily accommodate other vital components such as feedback loops, testing and self-service configuration. Feel free to try out the steps above and drop a line to let me know your thoughts.
