Skip to main content
Glama
techsterowniki

sinum-mcp

by techsterowniki
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Sinum MCP Server

Model Context Protocol server for Sinum smarthome system.

Description

This MCP server enables interaction with the Sinum system through Model Context Protocol. It allows retrieving device information and managing the smarthome system.

Related MCP server: matter-controller-mcp

Features

  • device_list: Retrieving list of all devices in the Sinum system

  • scene_list: Retrieving list of all scenes in the Sinum system

  • scene_activate: Activating scenes by ID

  • toggle_light: Toggling light devices (relay type with purpose === light)

  • API key authorization

  • Support for various device types (WTP, TECH, Virtual, SBus, SLink, LoRa, Modbus, etc.)

Installation

  1. Install dependencies:

npm install

  1. Configure environment variables:

cp env.example .env

  1. Edit the .env file and set:

Important: Replace your_api_key_here with your actual API key from the Sinum system.

Running

Development mode:

npm run dev

Production mode:

npm run build
npm start

MCP Configuration

Add the server to your MCP configuration:

{
  "mcpServers": {
    "sinum": {
      "command": "node",
      "args": ["/path/to/sinum-mcp/dist/index.js"],
      "env": {
        "SINUM_API_URL": "http://sinum.local/api/v1",
        "SINUM_API_KEY": "your_api_key_here"
      }
    }
  }
}

API

device_list

Retrieves a list of all devices in the Sinum system.

Parameters:

  • modified_since (optional): Timestamp - returns only devices modified after this date

Returns:

  • Collection of devices grouped by types (WTP, TECH, Virtual, SBus, SLink, LoRa, Modbus, System Module, Alarm System, Video, Custom Device Module)

scene_list

Retrieves a list of all scenes in the Sinum system.

Parameters:

  • None

Returns:

  • Collection of scenes with their details

scene_activate

Activates a scene with the given ID in the Sinum system.

Parameters:

  • id (required): ID of the scene to activate

Returns:

  • Success status and message

toggle_light

Toggles the state of a light device (on/off) for devices of type relay with purpose === light.

Parameters:

  • device_id (required): ID of the device to toggle

Returns:

  • Success status, message, and updated device information

Project Structure

sinum-mcp/
├── src/
│   ├── index.ts              # Main server file
│   ├── types/
│   │   ├── device.ts         # Device types
│   │   └── api.ts           # API types
│   ├── services/
│   │   └── sinum-api.ts     # Service for communication with Sinum API
│   └── tools/
│       ├── device-list.ts   # Tool for retrieving device list
│       ├── scene-list.ts    # Tool for retrieving scene list
│       ├── scene-activate.ts # Tool for activating scenes
│       └── toggle-light.ts  # Tool for toggling light devices
├── dist/                    # Compiled files
├── package.json
├── tsconfig.json
└── README.md

License

MIT

Available Tools

4 tools
device_listB

Retrieves a list of all devices/features in the Sinum smarthome system

ParametersJSON Schema
NameRequiredDescriptionDefault
modified_sinceNoTimestamp - returns only devices modified after this date (optional)

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It only states the action, omitting details like pagination, ordering, or that the optional modified_since parameter filters results.

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

Conciseness4/5

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

The description is a single sentence that front-loads the purpose. However, it is slightly incomplete by not mentioning the optional parameter.

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 optional parameter and no output schema, the description is adequate but minimal. It could mention filtering behavior or the scope of 'all devices/features'.

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 coverage is 100% as the single parameter modified_since is described in the schema. The description adds no extra semantic value beyond what the schema provides, meeting the baseline.

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 'retrieves' and the resource 'list of all devices/features', making the purpose unambiguous. It distinguishes from siblings like scene_list and toggle_light by specifying devices/features.

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?

There is no guidance on when to use this tool versus alternatives. No context about prerequisites or typical use cases is provided.

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

scene_activateB

Activates a scene with the given ID in the Sinum smarthome system

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesID of the scene to activate

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits beyond the basic activation. Important details like idempotency, side effects, authentication requirements, or error conditions are omitted.

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, concise sentence with no superfluous words. It is appropriately sized for the simplicity of the tool.

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?

Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is minimally functional but lacks context about return values, error handling, or behavioral constraints. More detail 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?

Schema coverage is 100%, with the parameter 'id' already well-described as 'ID of the scene to activate'. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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 ('Activates'), the resource ('a scene'), and the context ('in the Sinum smarthome system'). It is specific and distinguishes from sibling tools like device_list, scene_list, and toggle_light.

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 provided on when to use this tool versus alternatives. There is no indication of prerequisites, such as whether the scene must exist or be in a certain state, or when toggle_light might be more appropriate.

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

scene_listA

Retrieves a list of all scenes in the Sinum smarthome system

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

No annotations exist, so the description must carry full behavioral disclosure. It only states the action without noting safety (read-only), potential side effects, or access requirements. For a listing tool, it is assumed safe but not explicitly stated.

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 sentence that is front-loaded with the action and resource. No redundant or extra information. Perfectly concise.

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?

Given no parameters and no output schema, the description provides the essential purpose. However, it does not describe the return format or any pagination/ordering, which could be useful. The simplicity of the tool justifies a 4.

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?

With 0 parameters, schema coverage is trivially 100%. The description does not need to elaborate on parameters. Baseline for 0 params is 4, and the description adds no extra meaning beyond the trivial schema, but this is acceptable.

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 uses the verb 'Retrieves' and specifies the resource as 'list of all scenes in the Sinum smarthome system'. It distinguishes from siblings like 'device_list' (devices) and 'scene_activate' (activation), making purpose unambiguous.

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 provided on when to use this tool versus alternatives. It does not mention context, prerequisites, exclusions, or conditions for use.

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

toggle_lightA

Toggles the state of a light (on/off) for devices of type relay with purpose === light

ParametersJSON Schema
NameRequiredDescriptionDefault
device_idYesID of the device to toggle

TDQS

A3.8/5.0
Behavior2/5

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

No annotations provided, so description must carry burden. States basic toggle effect but omits any side effects, such as failure modes, asynchronous behavior, or required permissions.

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 concise sentence, no redundancy, front-loaded with key information.

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?

Adequate for a simple one-parameter toggle action. No output schema needed, but could mention result or error handling. Still sufficiently complete given low complexity.

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?

Schema covers device_id with 100% coverage. Description adds meaningful context: device must be of type relay with purpose light, which filters valid IDs beyond the schema.

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?

Clearly states the action (toggles), the object (light), and the constraint (devices of type relay with purpose light). Distinguishes from sibling tools like device_list and scene tools.

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?

Implicit that it's for toggling lights, but no explicit when-to-use or when-not-to-use guidance, no mention of prerequisites or alternatives.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.0
    • First observeddevice_list
    • First observedscene_activate
    • First observedscene_list
    • First observedtoggle_light
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool targets a distinct functionality: device listing, scene listing, scene activation, and light toggling. There is no overlap or ambiguity.

Naming Consistency4/5

Tools use snake_case, but patterns vary: two use 'noun_list' (device_list, scene_list) and two use 'verb_noun' (scene_activate, toggle_light). Mostly consistent with minor deviation.

Tool Count4/5

Four tools is a reasonable number for a basic smarthome server. It covers core operations without being too sparse or overloaded.

Completeness3/5

The set covers essential device listing, scene management, and light toggling, but lacks control over other device types (e.g., temperature, blinds) and advanced operations like brightness or scene creation, leaving notable gaps.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • xiaomi-device-control

    alleneee
    F
    license
    Not graded
    quality
    C
    maintenance
    MCP server for controlling Xiaomi/Mi Home smart devices via natural language, supporting device listing, property read/write, action calls, and camera snapshots.
    11
    -

  • matter-controller-mcp

    0x1abin
    A
    license
    Not graded
    quality
    D
    maintenance
    A powerful MCP server that enables AI assistants to discover, commission, and control Matter-compatible smart home devices through a standardized interface.
    21
    8
    MIT

  • ha-mcp

    osrd-gh
    A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that enables AI assistants to control Home Assistant via natural language, including device control, automation management, and system configuration.
    MIT

  • Loxone MCP Server

    reijosirila
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables natural language control of Loxone smart home systems, including lighting, audio, climate, and environmental monitoring, through MCP-compatible clients.
    29
    2
    AGPL 3.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/techsterowniki/sinum-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server