Configuring the Skylar Automation MCP Server

This section describes how to configure the integrated Model Context Protocol (MCP) server introduced in version 3.4.0 of Skylar Automation. The integrated MCP server exposes MCP components, tools, resources, and prompts sourced from installed SyncPacks to allow MCP clients such as Claude Desktop, VS Code, and others to interact with the Skylar Automation platform using Streamable HTTP.

Quick Start

The steps below describe how to begin using the MCP server with minimal additional configuration.

Log in to your Skylar Automation system and ensure that you have installed version 1.7.0 or later of the "Base Steps" SyncPack.
Verify that MCP components are loaded by running the following command:

GET /api/v1/mcp/namespaces
Create an API key to use with the MCP server. For more information on creating an API key, see Creating and Using API Keys in Skylar Automation.
Use Streamable HTTP to connect your agent or MCP client to https://<Skylar_Automation_Host_Address>/mcp. Enter the API key you created in Skylar Automation in the PF-APIKEY header.

Available MCP Components

MCP components are included in the "Base Steps" SyncPack version 1.7.0 and later. For the MCP components in the "Base Steps" SyncPack to be available for use, base_Steps_syncpack must be present in GET /api/v1/mcp/namespaces.

MCP Tools

Registered Name	Description	Parameters
base_steps_syncpack_run_application_by_name	Runs a Skylar Automation application by name	name: str, config_name: str
base_steps_syncpack_create_configuration	Creates a Skylar Automation configuration object	config_name: str, version: str, description: str, data: list[dict], author: str

The base_steps_syncpack_run_application_by_name MCP tool requires a Skylar Automation configuration object with a config_name that contains the pf_host and api_key. For more information, see Skylar Automation Configuration Objects.

The data: list [dict] parameter used by the base_steps_syncpack_create_configuration MCP tool is a list of configuration field objects. For example:

[
  { "name": "pf_host", "value": "my-sa-host.example.com" },
  { "name": "api_key", "value": "my-api-key", "encrypted": true },
  { "name": "other_config", "value": "value_other_config" }
]

MCP Resources

Uniform Resource Identifier (URI)	Description
resource://base_steps_syncpack/app_list	Lists all Skylar Automation applications
resource://base_steps_syncpack/config_list	Lists all Skylar Automation configuration objects

MCP Resource Templates

URI Template	Description	Parameters
resource://base_steps_syncpack/application/{app_name}	Gets a specific application	app_name
resource://base_steps_syncpack/configuration/{config_name}	Gets a specific configuration	config_name
resource://base_steps_syncpack/last_failure_log/{app_name}	Fetches last failure run logs for an application	app_name
resource://base_steps_syncpack/schedule_list/{config_name}	Lists schedules (requires Skylar Automation configuration)	config_name

MCP Prompts

Registered Name	Description	Parameters
base_steps_syncpack_Debug Skylar Automation Application Failure	Analyzes and debugs a failed Skylar Automation application run	name: str

Connecting an AI Agent

You can use Streamable HTTP to connect your AI agent or MCP client to the https://<Skylar_Automation_Host_Address>/mcp. Only API keys or users with execute permissions can access MCP components

Most MCP clients reject self-signed certificates. For information about configuring a valid certificate, see Changing the HTTPS Certificate.

Creating an API Key

Create an API key to use with the MCP server. For more information on creating an API key in Skylar Automation, see Creating and Using API Keys in Skylar Automation.

Client Examples

See the examples below for information on connecting a specific agent to the MCP server. For other clients, use https://<Skylar_Automation_Host_Address>/mcp as the Streamable HTTP URL and pass PF-APIKEY as a custom header.

Agents that Only Support Tools

Some agents and frameworks only support MCP tools, not resources or prompts. Solana Agent Kit MCP Server (SAMCP) handles this automatically by exposing all resources and prompts as callable tool wrappers so that no agent-side configuration is needed. These tool wrappers appear alongside regular tools in the tool list of the agent.

Prefix filtering does not apply to the MCP tool wrappers. List_resources, read_resource, list_prompts, and get_prompt are shared across all SyncPacks and must be explicitly included in the filter if needed. When included, they expose resources and prompts from all loaded SyncPacks.

An agent that only supports tools can still do the following:

Read any resource or resource template by calling list_resources and read_resource.
Use any prompt by calling list_prompts and get_prompt.

Component Naming Conventions

All MCP components are prefixed by SyncPack name:

Component Type	Pattern	Example
Tool	{syncpack}_{tool_name}	base_steps_syncpack_run_application_by_name
Prompt	{syncpack}_{prompt_name}	base_steps_syncpack_Debug Skylar Automation Application Failure
Resource	resource://{syncpack}/{path}	resource://base_steps_syncpack/app_list
Resource Template	resource://{syncpack}/{path}/{param}	resource://base_steps_syncpack/application/{app_name}

Skylar Automation Configuration Objects

Some MCP tools require a Skylar Automation configuration object to be created before they can be called. A configuration object stores the data the tool needs at runtime. This data could be connection details to reach the Skylar Automation platform, or credentials for any external system that the MCP tool interacts with.

The following "Base Steps" tools require a configuration object:

base_steps_syncpack_run_application_by_name (parameter: config_name)
resource://base_steps_syncpack/schedule_list/{config_name}

To create a configuration object or update an existing one, see Managing Configuration Objects.

The config_name used by the MCP tools is derived from the configuration object name in lowercase letters with spaces replaced by underscores. For example: "Test Config" becomes test_config.

The following fields must be configured on the configuration object:

pf_host. Current Skylar Automation hostname (without https://)
api_key. A valid Skylar Automation API key with execute permissions

Configuration data is encrypted at rest and decrypted automatically when the MCP tool runs.

Filtering Tools by SyncPack

To scope an agent to only use the components from one SyncPack, filter by prefix. See the example for Pedantic AI below:

mcp_prefixes = ["base_steps_syncpack"]

def agent_tool_filter(ctx, tool):
    return any(tool.name.lower().startswith(p.lower()) for p in mcp_prefixes)

filtered_toolset = server.filtered(agent_tool_filter) if mcp_prefixes else server

agent = Agent(
    model=model,
    deps_type=str,
    toolsets=[filtered_toolset],
    system_prompt="List all available tools",
)

For more information, see the Pydantic AI documentation on tool filtering or the Open AI documentation on tool filtering.

Without filters, all tools loaded in the MCP server are exposed to the agent. Only include tools relevant to the required context for your use case. Prefix filtering only matches named tools, such as base_steps_syncpack_*. The resource and prompt wrappers listed below are not prefix-matched, and must be added to the filter explicitly if the agent you are using needs them:

list_resources
read_resource
list_prompts
get_prompt

Timeout Behavior

Every tool and resource call is subject to a server-side timeout,MCP_TIMEOUT, which is configured by the Skylar Automation administrator. When a call exceeds the timeout:

The server returns an MCP error response to the agent.
The tool execution is canceled server-side.
The agent receives a timeout/error message, not a partial result.

There is no way to extend or override the timeout from the agent side. If a tool consistently times out, contact your Skylar Automation administrator to adjust the MCP_TIMEOUT value or optimize the tool implementation.

Administrator Configuration

Set environment variables for the samcp service in the docker-compose-override.yml file to adjust server behavior. For more information, see Configuring Skylar Automation Services.

Variable	Purpose	Default
MCP_STATELESS_HTTP	HTTP session mode. Possible values are true or false. Set this variable to false if more than one replica of the MCP server is running.	false
MCP_TIMEOUT	Tool or resource execution timeout period in seconds.	30

Troubleshooting

The table below lists common symptoms, their likely cause, and a potential fix for the issue.

Symptom	Likely Cause	Fix
401 Unauthorized	Missing or invalid API key	Check the PF-APIKEY header. Regenerate the API key if needed.
403 Forbidden	User or key lacks execute permissions	Grant execute permissions in Skylar Automation.
/api/v1/mcp/namespaces returns empty list	No SyncPacks with MCP components installed	Install the "Base Steps" SyncPack version 1.7.0 or later.
Tool not found by agent	SyncPack not loaded, or name/prefix mismatch	Verify namespace appears in /api/v1/mcp/namespaces.
McpValidationError on tool call	Required configuration object is missing or fields don't match schema	Create the configuration object in Skylar Automation with the correct field names.
Tool call returns timeout error	Execution exceeded MCP_TIMEOUT	Contact Skylar Automation administrator. Consider breaking the operation into smaller steps.
TLS or certificate error from agent	Skylar Automationis using a self-signed or untrusted certificate	Install a valid certificate. For information about configuring a valid certificate, see Changing the HTTPS Certificate.

Creating MCP Components in a SyncPack

This section is intended for SyncPack developers building new MCP-enabled SyncPacks. You do not need to review this section if you are only using the existing MCP components provided by ScienceLogic in existing SyncPacks.

If you are creating a new SyncPack using the SyncPack Cookie Cutter tool, select include_mcp_components when prompted, and the samcp_components/ structure below will be generated automatically. You only need to edit the generated files.

MCP components live inside the SyncPack package under samcp_components/, following the same layout as base_steps_syncpack:

{syncpack_name}/
└── samcp_components/
    ├── __init__.py
    ├── base_schemas.py          # Pydantic models for inputs/outputs (optional)
    ├── tools/
    │   ├── __init__.py
    │   └── tools.py
    ├── resources/
    │   ├── __init__.py
    │   └── resources.py
    ├── prompts/
    │   ├── __init__.py
    │   └── prompts.py
    └── templates/
        ├── __init__.py
        └── templates.py

SAMCP discovers all classes that inherit from the base classes below and registers them automatically at load time.

Set self.prefix = "<your_syncpack_name>" in every component. This becomes the registered name prefix.

MCP Tool

The subclass is BaseTool. Set self.function_tool to the callable element that implements the tool logic. In the example below, the tool is registered as my_syncpack_do_something.

from samcp.base_components import BaseTool

SYNCPACK = "my_syncpack"

class MyTool(BaseTool):
    def __init__(self):
        super().__init__(
            name="do_something",
            description="Does something useful",
            tags=["my_syncpack", "something"],
        )
        self.function_tool = self.do_something
        self.prefix = SYNCPACK

    @staticmethod
    async def do_something(param: str) -> dict:
        return {"result": param}

MCP Resource

The subclass is BaseResource. Set a static URI and the self.function_resource. In the example below, the resource is registered as resource://my_syncpack/my_list.

import json
from fastmcp.resources import ResourceResult, ResourceContent
from samcp.base_components import BaseResource

SYNCPACK = "my_syncpack"

class MyResource(BaseResource):
    def __init__(self):
        super().__init__(
            uri="resource://my_list", # no prefix here — SAMCP prepends it at registration
            name="get_my_list",
            description="Returns a list of items",
            tags=["my_syncpack", "list"],
        )
        self.function_resource = self.get_my_list
        self.prefix = SYNCPACK

    def get_my_list(self) -> ResourceResult:
        items = [{"id": 1, "name": "item1"}]
        return ResourceResult(
            contents=[ResourceContent(json.dumps(items), mime_type="application/json")]
        )

Resource Template

The subclass is BaseTemplate. Use a URI template with {param} placeholders. The method signature must match the placeholder names. In the example below, the resource template is registered as resource://my_syncpack/item/{item_id}.

import json
from fastmcp.resources import ResourceResult, ResourceContent
from samcp.base_components import BaseTemplate

SYNCPACK = "my_syncpack"

class MyTemplate(BaseTemplate):
    def __init__(self):
        super().__init__(
            uri_template="resource://item/{item_id}",  # no prefix here — SAMCP prepends it at registration
            name="get_item",
            description="Get a single item by ID",
            tags=["my_syncpack", "item"],
        )
        self.function_template = self.get_item
        self.prefix = SYNCPACK

    def get_item(self, item_id: str) -> ResourceResult:
        item = {"id": item_id, "name": "example"}
        return ResourceResult(
            contents=[ResourceContent(json.dumps(item), mime_type="application/json")]
        )

Prompt

The subclass is BasePrompt. Set self.function_prompt to a callable element that returns a string that will act as the prompt text sent to the agent. In the example below, the prompt is registered as my_syncpack_analyze_something.

from samcp.base_components import BasePrompt

SYNCPACK = "my_syncpack"

class MyPrompt(BasePrompt):
    def __init__(self):
        super().__init__(
            name="analyze_something",
            title="Analyze Something",
            description="Prompt to analyze X",
            tags=["my_syncpack", "analyze"],
        )
        self.function_prompt = self.analyze_something
        self.prefix = SYNCPACK

    @staticmethod
    def analyze_something(name: str) -> str:
        return f"Analyze {name} and provide a summary of findings."

Using Configuration Objects in a Tool

Use config_to_object to fetch a named configuration object from Skylar Automation and deserialize it into a Pydantic model. Encrypted fields are decrypted automatically.

Define a Pydantic model (MyConfig) that matches the fields stored in the Skylar Automation configuration object.
Call config_to_object (MyConfig, config_name) to load and decrypt the configuration object.
Use the configuration fields to reach the target system.
Return only the data fetched from the external system. Do not return configuration fields directly to the agent.

import httpx
from pydantic import BaseModel, Field
from samcp.utils.manager import config_to_object
from samcp.base_components import BaseTool

SYNCPACK = "my_syncpack"

class MyConfig(BaseModel):
    host: str = Field(description="Target hostname")
    api_key: str = Field(description="API key")

class MyTool(BaseTool):
    def __init__(self):
        super().__init__(name="get_items", description="Fetches items from an external system", tags=[])
        self.function_tool = self.get_items
        self.prefix = SYNCPACK

    @staticmethod
    async def get_items(config_name: str) -> dict:
        config = config_to_object(MyConfig, config_name)
        async with httpx.AsyncClient() as client:
            response = await client.get(
                f"https://{config.host}/api/items",
                headers={"Authorization": f"Bearer {config.api_key}"},
            )
            response.raise_for_status()
            return response.json()  # returns external API data, not config fields

The config_name is the ID of the configuration object stored in Skylar Automation.

The config_to_object automation raises an MCPValidationError if the configuration is missing or does not match the schema.