Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Spruthub MCP Server list all my smart home devices"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for controlling Sprut.hub smart home devices. This server provides Claude and other MCP-compatible clients with dynamic access to the complete Sprut.hub JSON-RPC API through schema autodiscovery.
Dynamic API Discovery - Automatically discovers and exposes all available Spruthub JSON-RPC methods
Schema Validation - Built-in parameter validation and documentation for all API methods
Full API Coverage - Access to all Spruthub functionality including devices, rooms, scenarios, and system administration
WebSocket Connection - Secure connection to Spruthub server with authentication
Method Categories - Organized API methods by category (hub, accessory, scenario, room, system)
Real-time Schema Updates - Schema information updated with spruthub-client library versions
Structured Responses - JSON-formatted responses optimized for AI integration
Related MCP server: Home Assistant MCP
Run the MCP server directly using npx:
npx spruthub-mcp-serverAdd to your Claude Desktop MCP settings:
{
"mcpServers": {
"spruthub": {
"command": "npx",
"args": ["spruthub-mcp-server"],
"env": {
"SPRUTHUB_WS_URL": "wss://your-spruthub-server.com/ws",
"SPRUTHUB_EMAIL": "your-email@example.com",
"SPRUTHUB_PASSWORD": "your-password",
"SPRUTHUB_SERIAL": "your-device-serial"
}
}
}
}For development or local modifications:
git clone https://github.com/shady2k/spruthub-mcp-server.git
cd spruthub-mcp-server
npm installAdd this server to your MCP client configuration. For Claude Desktop, add to your claude_desktop_config.json:
{
"mcpServers": {
"spruthub-mcp-server": {
"command": "npx",
"args": [
"spruthub-mcp-server@1.3.9"
],
"env": {
"SPRUTHUB_WS_URL": "ws://192.168.0.100/spruthub",
"SPRUTHUB_EMAIL": "your_email@example.com",
"SPRUTHUB_PASSWORD": "your_password",
"SPRUTHUB_SERIAL": "AAABBBCCCDDDEEEF"
}
}
}
}{
"mcpServers": {
"spruthub-mcp-server": {
"command": "node",
"args": ["/path/to/spruthub-mcp-server/src/index.js"],
"env": {
"SPRUTHUB_WS_URL": "ws://192.168.0.100/spruthub",
"SPRUTHUB_EMAIL": "your_email@example.com",
"SPRUTHUB_PASSWORD": "your_password",
"SPRUTHUB_SERIAL": "AAABBBCCCDDDEEEF"
}
}
}
}Note: Replace the environment variables with your actual Spruthub server details:
SPRUTHUB_WS_URL: WebSocket URL of your Spruthub server
SPRUTHUB_EMAIL: Your Spruthub account email
SPRUTHUB_PASSWORD: Your Spruthub account password
SPRUTHUB_SERIAL: Your Spruthub hub serial number
Security Best Practice: For sensitive values like SPRUTHUB_PASSWORD, consider using your system's environment variables instead of hardcoding them in the config file:
{
"mcpServers": {
"spruthub-mcp-server": {
"command": "npx",
"args": ["spruthub-mcp-server@1.3.9"],
"env": {
"SPRUTHUB_WS_URL": "ws://192.168.0.100/spruthub",
"SPRUTHUB_EMAIL": "your_email@example.com",
"SPRUTHUB_PASSWORD": "$SPRUTHUB_PASSWORD",
"SPRUTHUB_SERIAL": "AAABBBCCCDDDEEEF"
}
}
}
}Then set the password in your system environment:
export SPRUTHUB_PASSWORD="your_actual_password"This server provides three core tools that give you access to the complete Spruthub JSON-RPC API:
spruthub_list_methodsDiscover all available Spruthub API methods with their descriptions and categories.
Parameters:
category (optional): Filter methods by category (hub, accessory, scenario, room, system)
Example usage: Start here to explore what's available in your Spruthub system.
spruthub_get_method_schemaGet detailed schema information for any API method, including parameters, return types, and examples.
Parameters:
methodName (required): The method name to get schema for (e.g., accessory.search, characteristic.update)
Important: Always call this tool before using spruthub_call_method to understand the exact parameter structure required.
spruthub_call_methodExecute any Spruthub JSON-RPC API method with the provided parameters.
Parameters:
methodName (required): The API method to call
parameters (optional): Method parameters as defined in the method's schema
Critical: You MUST call spruthub_get_method_schema first to understand the parameter structure. Never guess parameters.
Explore your system:
spruthub_list_methods → spruthub_get_method_schema → spruthub_call_methodControl devices:
spruthub_get_method_schema(methodName: "characteristic.update")
→ spruthub_call_method(methodName: "characteristic.update", parameters: {...})Browse by category:
spruthub_list_methods(category: "accessory") → Get device-related methods
spruthub_list_methods(category: "scenario") → Get automation methodsThe schema-based approach provides efficient access to Spruthub functionality:
Discovery Phase: Use spruthub_list_methods to explore available functionality
Schema Phase: Use spruthub_get_method_schema to understand method requirements
Execution Phase: Use spruthub_call_method with proper parameters
Filter by category when exploring: Use category parameter in spruthub_list_methods
Always get schema first: Never guess API parameters - use spruthub_get_method_schema
Use specific methods: The API provides targeted methods for efficient operations
Check method categories:
hub - Hub management and status
accessory - Device discovery and control
scenario - Automation and scenes
room - Room management
system - System administration
Each API method includes:
Complete parameter specifications
Return type definitions
Usage examples
REST API mapping (where available)
Category classification
# Install dependencies
npm install
# Run in development mode with auto-reload
npm run dev
# Run linting
npm run lint
# Fix linting issues
npm run lint:fixLOG_LEVEL: Set logging level (default: 'info')
SPRUTHUB_WS_URL: WebSocket URL for Spruthub server (required if auto-connecting)
SPRUTHUB_EMAIL: Email for authentication (required if auto-connecting)
SPRUTHUB_PASSWORD: Password for authentication (required if auto-connecting)
SPRUTHUB_SERIAL: Device serial number (required if auto-connecting)
LOG_LEVEL: Set logging level (info, debug, warn, error) (default: 'info')
MIT
Execute any Sprut.hub JSON-RPC API method. IMPORTANT: You MUST call spruthub_get_method_schema first to understand the exact parameter structure before calling this method. Never guess parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| methodName | Yes | The method name to call (e.g., "accessory.search", "characteristic.update") | |
| parameters | No | Method parameters exactly as defined in the method schema. MUST call spruthub_get_method_schema first to get the correct parameter structure. Do not guess parameter names or structure. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses the prerequisite schema requirement and warns against guessing, but does not mention potential side effects, return value, or error behavior of executing arbitrary methods. This is partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, with purpose stated first and critical warnings highlighted with 'IMPORTANT.' Every sentence earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a generic executor, the description provides the essential workflow (call schema first) and is complemented by sibling tools for listing and schema retrieval. It omits return value and error details, but these are likely found via the method schema, so the description is adequate if not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'methodName' and 'parameters' clearly documented, including examples and the requirement to consult the schema. The tool description adds no new parameter semantics beyond reinforcing the same instructions found in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute any Sprut.hub JSON-RPC API method' with a specific verb and resource, distinguishing it from sibling tools like spruthub_list_methods and spruthub_get_method_schema. It is unambiguous about the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'You MUST call spruthub_get_method_schema first' and 'Never guess parameters,' giving clear when-to-use and when-not-to-guess guidance. This is directly actionable for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed schema for a specific Sprut.hub API method including parameters, return type, examples
| Name | Required | Description | Default |
|---|---|---|---|
| methodName | Yes | The method name (e.g., "accessory.search", "characteristic.update") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output contents (parameters, return type, examples), giving some behavioral context. However, it does not mention authentication, error cases, side effects, or safety guarantees, and no annotations exist to cover these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, with no unnecessary words. It is concise and directly communicates the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and partially explains the return content, but it lacks explicit guidance on when to use it relative to sibling tools and does not specify the return structure beyond listing included elements. Given the simple one-parameter interface, it is adequate but not enriched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete coverage with a description and examples for methodName. The tool description adds no parameter-specific semantics, but the schema is sufficient on its own.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a distinct resource 'detailed schema for a specific Sprut.hub API method'. It clearly differentiates this tool from siblings like spruthub_list_methods (which lists all methods) and spruthub_call_method (which invokes a method) by focusing on a single method's schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a method's schema before calling it, but it does not explicitly state when to prefer this over spruthub_list_methods or how it relates to spruthub_call_method. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Sprut.hub JSON-RPC API methods with their categories and descriptions
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter methods by category (hub, accessory, scenario, room, system) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the tool lists methods and includes categories/descriptions, but does not mention that it is read-only, whether there is pagination, or how filtering behaves for invalid categories. It adds only the basic facts without deeper context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action ('List') and resource. Every word adds value: 'all', 'available', 'categories', 'descriptions'. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional filter and no output schema, the description adequately explains what the tool returns (methods with categories and descriptions). It could mention that this is the starting point before using get_method_schema or call_method, but given the simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter 'category', which already explains its purpose and allowed values. The description adds no parameter-specific information, so it neither improves nor detracts from the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'Sprut.hub JSON-RPC API methods', and the scope 'with their categories and descriptions'. It distinguishes itself from sibling tools (get_method_schema and call_method) by focusing on enumeration rather than details or invocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool lists all available methods. While it doesn't explicitly mention when to use it over siblings, the purpose is self-evident as a discovery/listing tool. There are no exclusions or alternative recommendations, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.3.16spruthub_call_methodspruthub_get_method_schemaspruthub_list_methodsScored across 3 tools
Each tool has a distinctly different role: listing methods, retrieving schemas, and executing calls. There is no overlap or ambiguity in their purposes.
All three tools follow a consistent 'spruthub_' prefix with clear verb_noun structure (list_methods, get_method_schema, call_method). The naming pattern is uniform and predictable.
Three tools are perfectly scoped for a meta-server that dynamically exposes a full JSON-RPC API. Each tool provides a necessary layer of the interaction workflow.
The set covers the complete lifecycle of API interaction: discovering available methods, understanding their schemas, and invoking them. No essential capabilities are missing for the domain.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Remote MCP for 1,500+ APIs. Vault-managed credentials; OAuth or API key. Search, load, and execute.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
