Skip to main content
Glama
taco-ops

Siril MCP Server

by taco-ops
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Siril MCP Server

CI Release Automated Release Python Versions License Development Status

⚠️ Work in Progress: This project is under active development and not yet ready for production use. APIs may change without notice.

A Model Context Protocol (MCP) server that provides tools for working with Siril astronomical image processing software and Seestar telescope data.

🚧 Current Status

This project is in early development. Current features include:

  • ✅ Siril Binary Detection: Smart detection of Siril installations across platforms

  • ✅ Version Checking: Check your installed Siril version

  • ✅ Basic Mosaic Processing: Process Seestar S30/S50 telescope images

  • ✅ Filter Support: Supports both broadband and narrowband processing

  • ✅ Auto Script Creation: Automatically creates required SSF scripts

  • ✅ FastMCP Integration: Proper async logging and error handling

  • 🔄 Script Updates: Download latest scripts from Naztronomy repository

  • 🔄 Project Analysis: Check project structure and file organization

  • ❌ GUI Integration: Headless preprocessing tools (planned)

  • ❌ PyPI Package: Not yet published

Related MCP server: aqc-mcp

Prerequisites

  • Python 3.10+

  • Siril astronomical image processing software

Siril Installation & Detection

The server automatically detects Siril installations in the following order:

  1. Custom Path: Set SIRIL_BINARY environment variable to specify a custom location

  2. System PATH: Checks if siril command is available in your PATH

  3. macOS App Bundle: /Applications/Siril.app/Contents/MacOS/Siril

  4. Common Locations: /usr/bin/siril, /usr/local/bin/siril, /opt/homebrew/bin/siril

macOS Users: If you installed Siril as an application, no additional setup is needed - it will be detected automatically.

Custom Installation: For non-standard installations, set the environment variable:

export SIRIL_BINARY="/path/to/your/siril/binary"

Installation

Note: This package is not yet published to PyPI. Install from source for now.

From Source (Development)

git clone https://github.com/taco-ops/siril-mcp
cd siril-mcp

# Using pipenv (recommended)
pipenv install --dev
pipenv shell

# Or using pip
pip install -e .

Future PyPI Installation

Once published, you'll be able to install via:

# Using pip
pip install siril-mcp

# Using pipenv
pipenv install siril-mcp

Development Setup

This project uses Pipenv for Python dependency management and npm for MCP testing tools. Make sure you have both installed:

pip install pipenv
# Node.js and npm should be installed for MCP integration testing

Setting up the development environment:

# Clone the repository
git clone https://github.com/taco-ops/siril-mcp
cd siril-mcp

# Install Python dependencies and create virtual environment
pipenv install --dev

# Install Node.js dependencies for MCP testing
npm install

# Activate the virtual environment
pipenv shell

# Install the package in development mode
pipenv install -e .

# Validate setup
npm run validate-ci

Available scripts:

Python (Pipenv):

# Build the package
pipenv run build

# Run Python tests
pipenv run test

# Format code with Black
pipenv run format

# Lint code with Flake8
pipenv run lint

# Upload to Test PyPI
pipenv run upload-test

# Upload to production PyPI
pipenv run upload

MCP Testing (npm):

# Run basic MCP functionality tests
npm run test

# Run MCP integration tests
npm run test:integration

# Run all MCP tests
npm run test:all

# Validate CI setup readiness
npm run validate-ci

Release Management (npm):

# Test release process (dry run)
npm run release:dry

# Create actual releases
npm run release:patch    # Bug fixes (1.0.0 → 1.0.1)
npm run release:minor    # New features (1.0.0 → 1.1.0)
npm run release:major    # Breaking changes (1.0.0 → 2.0.0)

# General release (auto-detects type)
npm run release

Local Development Workflow

Pre-commit Hooks (Recommended)

This project uses pre-commit hooks to ensure code quality. Install them for automatic checks:

# Install pre-commit hooks (one-time setup)
pipenv run pre-commit install

# Now all commits will automatically run:
# - Black formatting
# - isort import sorting
# - flake8 linting
# - pytest tests

Manual Quality Checks

You can also run quality checks manually:

# Run all pre-commit hooks on all files
pipenv run pre-commit run --all-files

# Run specific checks
pipenv run pre-commit run black        # Format code
pipenv run pre-commit run flake8       # Lint code
pipenv run pre-commit run pytest      # Run tests

Release Testing Locally

Test the release process without actually releasing:

# Install Node.js dependencies
npm install

# Test what a release would look like
npm run release:dry

# Test specific release types
npm run release:patch --dry-run
npm run release:minor --dry-run
npm run release:major --dry-run

🧪 Testing & Quality Assurance

This project includes comprehensive testing with both Python unit tests and MCP integration testing.

Test Suites

Python Unit Tests

Traditional pytest-based testing for core functionality:

# Run all Python tests
pipenv run test

# Run tests with coverage
pipenv run python -m pytest tests/ --cov=siril_mcp --cov-report=html

# Run specific test
pipenv run python -m pytest tests/test_server.py::test_find_siril_binary_macos_location -v

MCP Integration Tests

Node.js-based testing that validates the complete MCP server functionality:

# Install Node.js dependencies
npm install

# Run basic functionality tests
npm run test

# Run MCP protocol integration tests
npm run test:integration

# Run all MCP tests
npm run test:all

# Validate CI readiness
npm run validate-ci

CI/CD Pipeline

The project uses GitHub Actions for automated testing and releases:

Continuous Integration

  • Triggers: Every push and PR to main and develop branches

  • Python Versions: Tests across Python 3.10, 3.11, and 3.12

  • Test Coverage: Code formatting, linting, Python tests, and MCP integration tests

  • Environment Adaptive: Tests automatically adapt to CI environments where Siril isn't available

Release Pipeline

  • Triggers: When version tags (v*) are pushed

  • Pre-Release Validation: Comprehensive testing across all Python versions

  • MCP Protocol Validation: Ensures MCP server functionality before release

  • Automated Publishing: Builds and publishes to PyPI only after all tests pass

Test Coverage Includes

  • ✅ Siril binary detection across platforms

  • ✅ Version checking and error handling

  • ✅ SSF script content validation

  • ✅ Project structure validation

  • ✅ MCP protocol compliance and tool registration

  • ✅ Complete MCP server initialization and tool execution

  • ✅ Filter type processing differences

  • ✅ Environment variable handling

  • ✅ CI/CD environment adaptation

  • ✅ Error conditions and edge cases

Local Development Testing

# Quick validation of local setup
npm run validate-ci

# Test in CI mode locally (simulates GitHub Actions)
CI=true npm run test:all

# Full local testing
pipenv run test && npm run test:all

For detailed testing documentation, see CI_TESTING.md.

Usage

As an MCP Server

Run the server directly:

# If installed globally
siril-mcp

# If using pipenv
pipenv run siril-mcp

# Or activate the environment first
pipenv shell
siril-mcp

With Claude Desktop

Add to your Claude Desktop configuration:

{
  "mcpServers": {
    "siril": {
      "command": "siril-mcp"
    }
  }
}

Project Structure

Your Seestar project should be organized like this:

project_root/
├── lights/                 # Your FITS files go here
│   ├── Light_001.fits
│   ├── Light_002.fits
│   └── ...
└── process/               # Output directory (created automatically)
    └── mosaic.fits        # Final processed mosaic

Note: The SSF script files are created automatically - you don't need to download them manually!

Available Tools

find_siril_binary()

Locates and validates the Siril binary on your system. Useful for troubleshooting installation issues.

validate_siril_binary(binary_path)

Tests whether a specific Siril binary path works correctly. Useful for validating custom installations.

check_siril_version()

Returns the version of your installed Siril software.

process_seestar_mosaic(project_dir, filter_type)

Processes FITS files in the project directory using the appropriate Siril script.

  • project_dir: Path to your project root

  • filter_type: Either "broadband" or "narrowband"

The function automatically creates the required SSF scripts, so you don't need to download anything manually.

check_project_structure(project_dir)

Analyzes your project directory and shows what files are present and what might be missing.

download_latest_ssf_scripts(project_dir)

Downloads the latest SSF script files from the naztronaut/siril-scripts repository.

preprocess_with_gui(project_dir) (Planned)

Future feature to launch Naztronomy Smart Telescope preprocessing GUI in headless mode.

Filter Types Available

  • broadband: For UV/IR block filters (most common)

  • narrowband: For light pollution (LP) filters

🚀 Releases & CI/CD

Automated Release Process

This project features a fully automated release system with two approaches:

Option 1: GitHub Actions Release (Recommended)

  1. Go to: GitHub Actions

  2. Select: "Release with release-it" workflow

  3. Click: "Run workflow"

  4. Choose: Release type:

    • Patch (1.0.0 → 1.0.1) - Bug fixes

    • Minor (1.0.0 → 1.1.0) - New features

    • Major (1.0.0 → 2.0.0) - Breaking changes

Option 2: Traditional Tag-Based Release

# Create and push a new version tag
git tag v1.0.0
git push origin v1.0.0

Both methods trigger the complete release pipeline:

Pre-Release Validation

  1. ✅ Code Quality: Automated linting and formatting checks

  2. ✅ Multi-Python Testing: Tests across Python 3.10, 3.11, and 3.12

  3. ✅ Python Unit Tests: Complete pytest suite validation

  4. ✅ MCP Integration Tests: Full MCP protocol and tool functionality testing

  5. ✅ Package Building: Wheel and source distribution validation

Release Execution

  1. ✅ Version Management: Automatic version synchronization across all files

  2. ✅ Changelog Generation: Conventional changelog with commit links

  3. ✅ GitHub Release: Automated release creation with artifacts

  4. ✅ PyPI Publishing: Automatic publishing to PyPI (for stable releases)

Advanced Release Features

  • 🔄 Version Synchronization: Automatically syncs versions between package.json and pyproject.toml

  • 📝 Conventional Changelogs: Auto-generated changelogs from commit messages

  • 🏷️ Smart Tagging: Automatic git tagging with proper semantic versioning

  • 📦 Asset Management: Release artifacts automatically attached to GitHub releases

  • ✨ Pre-commit Hooks: Quality checks run automatically before releases

Quality Gates

No release proceeds unless ALL tests pass, ensuring every published version is:

  • ✅ Properly formatted and linted

  • ✅ Compatible across supported Python versions

  • ✅ Functionally validated with unit tests

  • ✅ MCP protocol compliant

  • ✅ Tool functionality verified

  • ✅ Package integrity confirmed

CI Status Badges

The repository includes live status badges showing:

  • CI Continuous Integration: Current build status

  • Release Release Pipeline: Latest release status

🤝 Contributing

This project is in early development and contributions are welcome! Here's how to get started:

Development Setup

  1. Fork the repository

  2. Create a feature branch: git checkout -b feature/amazing-feature

  3. Install development dependencies:

    pipenv install --dev  # Python dependencies
npm install           # Node.js testing dependencies

Making Changes

  1. Make your changes and add tests

    • Add Python unit tests in tests/ directory

    • Update MCP integration tests if modifying tool functionality

  2. Run the complete test suite:

    pipenv run test      # Python tests
npm run test:all     # MCP integration tests
npm run validate-ci  # CI readiness check

  3. Format and lint your code:

    pipenv run format    # Black formatting
pipenv run lint      # Flake8 linting

Submitting Changes

  1. Commit your changes: git commit -m 'Add amazing feature'

  2. Push to the branch: git push origin feature/amazing-feature

  3. Open a Pull Request

Pull Request Requirements

All PRs must pass:

  • ✅ Code Formatting: Black formatting compliance

  • ✅ Linting: Flake8 validation without errors

  • ✅ Python Tests: All pytest unit tests passing

  • ✅ MCP Integration: All MCP protocol tests passing

  • ✅ Multi-Python: Tests passing on Python 3.10, 3.11, and 3.12

  • ✅ CI Validation: All GitHub Actions workflows passing

Testing Your Changes Locally

Before submitting a PR, ensure everything works:

# Quick validation (like CI will run)
npm run validate-ci

# Complete local testing
pipenv run test && npm run test:all

# Test CI mode locally
CI=true npm run test:all

Development Roadmap

  • Complete GUI integration for preprocessing tools

  • Add support for additional telescope types

  • Implement batch processing capabilities

  • Add image quality assessment tools

  • Create comprehensive documentation site

  • Publish to PyPI for stable releases

  • Add Docker container support

Filter Types Available

Credits

This MCP server uses SSF scripts from the naztronomy/siril-scripts repository by Nazmus Nasir (Naztronomy.com), used under the GPL-3.0 license.

License

MIT License - see LICENSE file for details.

Available Tools

7 tools
check_project_structureA

Checks and displays the structure of a Seestar project directory, showing what files are present and what might be missing.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_dirYespath to your project root

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. 'Checks and displays' implies a read-only operation, and it specifies output theme (present/missing files), but doesn't disclose error handling, side effects, or behavior beyond these traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with action, zero redundant words. All content is relevant and directly tied to tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has a single parameter, no annotations, but has an output schema. Description clearly defines purpose and scope, but could specify what constitutes a valid project structure or what 'missing' is compared against. Minor gap given simplicity and existing schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema already documents the sole parameter (project_dir) with 100% coverage. Description adds no extra detail about parameter format or meaning beyond what schema provides, warranting baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Checks and displays' with resource 'structure of a Seestar project directory', clearly stating it shows present and missing files. This distinguishes it from sibling tools that handle version checks, binary validation, and processing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternative guidance. Usage is implied as a diagnostic step for Seestar projects, but there is no statement about when to choose this over sibling tools like validate_siril_binary or process_seestar_mosaic.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_siril_versionA

Runs 'siril --version' on the local machine and returns the version string.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses that it executes a command on the local machine and returns the version string, which is transparent for a read-only operation. It does not mention failure modes if siril is missing, but the core behavior is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys both the action and the result.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool that runs one command and returns a string, the description fully covers the essential behavior. The presence of an output schema further reduces the need to explain return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the schema fully covers the input. The description adds no parameter detail, but the baseline of 4 applies for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: runs 'siril --version' and returns the version string. This distinguishes it from siblings like find_siril_binary (locating the binary) and validate_siril_binary (verifying functionality).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus find_siril_binary or validate_siril_binary. The description only states what the tool does, with no mention of prerequisites (e.g., siril must be installed) or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

download_latest_ssf_scriptsA

Downloads the latest SSF script files from the naztronaut/siril-scripts repository and saves them to your project directory. This ensures you have the most up-to-date versions of the Siril scripts.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_dirYespath to your project root where scripts will be saved

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the full burden of disclosing side effects. It does not mention whether existing files are overwritten, whether network access is required, or what happens on failure. The description only states the happy path without behavioral caveats.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no filler. It gets straight to the point and is well-structured, placing the primary action first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and an output schema, the description covers the basic purpose and destination. However, it omits important operational context like whether the script files will overwrite existing ones, if a directory must already exist, or if there are network prerequisites. Given the lack of annotations, some additional context would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage for the single parameter project_dir with a clear description. The tool description only reinforces 'project directory' without adding new semantic details, so it meets the baseline but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('downloads'), the resource ('latest SSF script files from the naztronaut/siril-scripts repository'), and the destination ('saves them to your project directory'). This distinguishes it from sibling tools like check_siril_version or process_seestar_mosaic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'This ensures you have the most up-to-date versions' implies use when fresh scripts are needed, but there is no explicit guidance on when to use it versus alternatives or when not to use it. The use case is only indirectly suggested.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_siril_binaryA

Locates the Siril binary on your system and returns its path. This is useful for troubleshooting installation issues or confirming which version of Siril will be used.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states the core action (locating) and the return value (path), but does not disclose edge cases such as what happens if the binary is not found, whether it searches the PATH, or any side effects. This is adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and front-loaded with the action. The first sentence states the purpose, and the second provides context. Every word earns its place, with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, output schema present) and the description's clear statement of purpose and return value, the description is complete. The output schema handles return details, so the description does not need to explain them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description correctly implies that no input is needed and that the operation is system-wide. No further parameter semantics are required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Locates' and the resource 'Siril binary', and specifies that it 'returns its path'. This distinguishes it from sibling tools like check_siril_version and validate_siril_binary, which focus on version checking and validation, respectively.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by stating it is 'useful for troubleshooting installation issues or confirming which version of Siril will be used'. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

preprocess_with_guiB

Launches the full Naztronomy-Smart_Telescope_PP.py GUI in headless mode. (Requires sirilpy installed and a display server.)

ParametersJSON Schema
NameRequiredDescriptionDefault
project_dirYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It mentions prerequisites and headless mode but does not disclose potential side effects, failures, or what the GUI launch entails (e.g., blocking, interactive behavior, error handling). Significant behavioral gaps remain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short, front-loaded sentences with no redundant information. The parenthetical prerequisite is appropriately placed. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool description is minimal and does not explain how it fits into the preprocessing pipeline, what the GUI performs, or what the user should expect. Although an output schema exists, the description lacks sufficient behavioral and integration context to be fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not mention the 'project_dir' parameter at all. The parameter name gives a hint, but the description fails to explain its role in launching the GUI. No compensation for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Launches') and target resource ('full Naztronomy-Smart_Telescope_PP.py GUI') with a specific mode ('headless'). This distinguishes it from sibling tools like process_seestar_mosaic or check_siril_version.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: this tool is for launching the GUI headlessly. It lists a prerequisite but provides no explicit when/when-not guidance or comparison to alternative tools. The prerequisite gives some context but lacks exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

process_seestar_mosaicA

Runs the appropriate Siril .ssf mosaic script on all FIT(S) in project_dir/lights, stacking them into a mosaic according to Seestar S30/S50 conventions.

This function automatically creates the required SSF script files in your project directory, so you don't need to manually download them from the repository.

ParametersJSON Schema
NameRequiredDescriptionDefault
filter_typeNo'broadband' for UV/IR block or 'narrowband' for LP filterbroadband
project_dirYespath to your project root (must contain a 'lights/' subdir)

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses a key side effect (automatically creating required SSF script files in the project directory) and clarifies the processing scope. It doesn't mention external dependencies like Siril being installed or whether files might be overwritten, but the core behavioral traits are well described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The first sentence states the action, input, and output; the second removes a likely user concern (manually downloading scripts). The information is front-loaded and every clause adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential context: input directory, processing action, output concept, and a major convenience. An output schema exists, so return details don't need explaining. However, given sibling tools like find_siril_binary and validate_siril_binary, the description could have mentioned prerequisites or ordering, so it's not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces that project_dir must contain a 'lights/' subdir, matching the schema. It does not add further meaning to filter_type beyond what the schema already provides via its enum and per-value descriptions, so no higher score is warranted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Runs'), a clear resource ('the appropriate Siril .ssf mosaic script on all FIT(S) in project_dir/lights'), and states the outcome ('stacking them into a mosaic'). It also differentiates from sibling tools by explicitly noting that it auto-creates the SSF scripts, so users don't need to download them separately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it processes all FIT(S) in project_dir/lights and auto-creates script files. It implicitly advises against a separate manual download step, which distinguishes it from the sibling download_latest_ssf_scripts. However, it doesn't explicitly state when not to use this tool or mention prerequisites like running check_project_structure first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_siril_binaryA

Tests whether a specific Siril binary path works correctly. Useful for validating custom installations or non-standard locations.

ParametersJSON Schema
NameRequiredDescriptionDefault
binary_pathYesFull path to the Siril binary to test

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the tool's purpose (testing whether a binary path works) but leaves 'works correctly' undefined—does it run the binary, check version, or verify permissions? It also doesn't state side effects or failure behavior. However, as a validation tool, the core behavior is reasonably clear, earning a mid-range score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. It front-loads the core purpose and then adds a practical use case. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter, full schema coverage, and an output schema present. The description explains what the tool does and when to use it; no additional context is needed for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes the only parameter 'binary_path' with 'Full path to the Siril binary to test,' providing 100% coverage. The description adds no additional parameter details beyond what the schema already offers, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Tests whether a specific Siril binary path works correctly,' which is a specific verb ('Tests') and resource ('Siril binary path'). It distinguishes from siblings like check_siril_version (version check) and find_siril_binary (locating a binary) by focusing on validation of a given path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Useful for validating custom installations or non-standard locations.' This implies when to use the tool, though it does not explicitly mention alternatives or when not to use it. The context is sufficient to guide the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updatesv1.1.0
    • First observedcheck_project_structure
    • First observedcheck_siril_version
    • First observeddownload_latest_ssf_scripts
    • First observedfind_siril_binary
    • First observedpreprocess_with_gui
    • First observedprocess_seestar_mosaic
    • First observedvalidate_siril_binary
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 7 tools

Disambiguation5/5

Each tool has a clearly distinct action: checking version, finding binary, validating binary, processing mosaic, preprocessing with GUI, downloading scripts, and checking project structure. Even the three binary-related tools are easily told apart by their different verbs and purposes.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern, with verbs like check, find, validate, process, preprocess, download, and check. There is no mixing of styles or vague naming.

Tool Count5/5

With 7 tools, the set is well-scoped and each tool serves a clear purpose within the Siril/Seestar workflow. It is neither too sparse nor overloaded.

Completeness4/5

The tool set covers the core lifecycle for Seestar image processing: ensuring the environment is correct, downloading needed scripts, checking project structure, and running the two main processing workflows. Minor gaps exist (e.g., no tool to fix project structure issues), but agents can work around them.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers