F
licenseB
qualityNot graded
maintenanceEnables interaction with Homey smart home devices through natural language, allowing users to control devices, manage zones, and trigger automation flows.
6
4
Nature Remo MCP Server
by noboru-i
Click on "Install 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., "@Nature Remo MCP Serverlist all my appliances"
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.
Nature Remo MCP server
MCP Server for the Nature Remo API.
Overview
This is an MCP server for Nature Remo, designed to handle requests and interact with the Nature Remo API using the Model Context Protocol SDK. It provides tools to manage and automate interactions with Nature Remo devices.
Related MCP server: Smart Home Device Control MCP Server
Prerequisites
Create your own access_token on Nature Remo Home. more detail, see documentation).
Setup
Usage with VS Code
Add the following configuration to your User Settings (JSON) file. Open the settings by pressing Cmd + Shift + P and selecting Preferences: Open User Settings (JSON).
Alternatively, you can create a .vscode/mcp.json file in your workspace to share the configuration with others. Note that the mcp key is not needed in the .vscode/mcp.json file.
Note that the
mcpkey is not needed in the.vscode/mcp.jsonfile.
{
"mcp": {
"servers": {
"nature-remo": {
"command": "npx",
"args": [
"-y",
"noboru-i/nature-remo-mcp-server"
],
"env": {
"ACCESS_TOKEN": "<YOUR_TOKEN>"
}
}
}
}
}Usage with Claude Desktop
{
"mcpServers": {
"github": {
"command": "npx",
"args": [
"-y",
"noboru-i/nature-remo-mcp-server"
],
"env": {
"ACCESS_TOKEN": "<YOUR_TOKEN>"
}
}
}
}Tools
This server provides the following tools:
list_devices - List devices on the home.
No parameters required
list_appliances - List appliances on the home.
No parameters required
operate_tv - Operate a TV appliance.
applianceId: Appliance id (string, required)button: Button label (string, required)times: Number of times to press the button (integer, optional)
operate_aircon - Operate an aircon appliance.
applianceId: Appliance id (string, required)airDirection: Air direction (string, optional)airDirectionH: Horizontal air direction (string, optional)airVolume: Air volume (string, optional)button: Button label (string, optional)operationMode: Operation mode (string, optional)temperature: Temperature (string, optional)temperatureUnit: Temperature unit (string, optional)times: Number of times to press the button (integer, optional)
License
This project is licensed under the terms of the MIT open source license. Please refer to MIT for the full terms.
Available Tools
4 toolslist_appliancesA
List appliances on the home
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as read-only nature, authentication requirements, or response format.
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 that is front-loaded and contains no unnecessary words.
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?
For a simple tool with no parameters and no output schema, the description is adequate but could be slightly more informative about the scope or usage context.
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 input schema has no parameters (0 params, 100% coverage), so the description does not need to add parameter semantics. Baseline for 0 params is 4.
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 'List appliances on the home' clearly states the verb (List) and the resource (appliances on the home), and distinguishes it from sibling tools like list_devices and operational tools.
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?
The description provides no guidance on when to use this tool versus siblings like list_devices, operate_aircon, or operate_tv.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_devicesB
List devices on the home
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 of behavioral disclosure. It only states the basic action (list devices) without any additional behavioral traits, such as whether it returns online/offline status, requires authentication, or has performance implications.
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 extremely concise at 5 words, front-loading the purpose. However, it could be improved by adding a brief note on scope or differentiation without losing conciseness.
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 simple nature (no parameters, no output schema), the description is minimally adequate but lacks clarity on the scope (e.g., 'home' vs 'room') and differentiation from 'list_appliances'. An agent might be uncertain which tool to invoke.
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?
There are no parameters, so the schema coverage is 100% by default. The description adds no further parameter-level meaning, but this is acceptable as there is nothing to elaborate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists devices on the home, providing a specific verb and resource. However, it does not distinguish from the sibling tool 'list_appliances', leaving ambiguity about the difference between devices and appliances.
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?
The description provides no guidance on when to use this tool versus alternatives like 'list_appliances', 'operate_aircon', or 'operate_tv'. No usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
operate_airconD
Operate an aircon appliance
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| applianceId | Yes | ||
| airDirection | No | ||
| airDirectionH | No | ||
| airVolume | No | ||
| button | No | ||
| operationMode | No | ||
| temperature | No | ||
| temperatureUnit | No | ||
| times | No |
TDQS
D1.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does not disclose any behavioral traits, such as whether it turns the appliance on/off or requires prerequisites, leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It lacks structure and fails to convey essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no annotations, the description is grossly incomplete. It provides no information on effects, return values, or prerequisites.
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?
With 9 parameters and 0% schema description coverage, the description should compensate but does not. It adds no meaning to parameters like 'airDirection' or 'operationMode', leaving them unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Operate an aircon appliance' adds minimal information beyond the tool name, restating it without specifying what operations are possible. It is vague and fails to differentiate from sibling tools like 'operate_tv'.
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 on when to use this tool versus alternatives such as 'list_appliances' or 'operate_tv'. The description implies general control of an aircon but provides no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
operate_tvD
Operate a TV appliance
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| applianceId | Yes | ||
| button | Yes | ||
| times | No |
TDQS
D1.3/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description lacks any disclosure of side effects, permissions, or limitations; the agent gets no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but under-specified; true conciseness requires including essential information, which is missing here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and no annotations, the description fails to provide necessary context for safe and correct invocation.
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 description does not explain the meaning of 'applianceId', 'button', or 'times', leaving parameter semantics entirely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Operate a TV appliance' minimally identifies the resource but does not specify what operations are possible, making it vague and not distinguishing from sibling 'operate_aircon'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'operate_aircon' or list tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
C2.5/5.0
Disambiguation2/5
The tools 'list_appliances' and 'list_devices' have overlapping purposes, as both list things on the home without clear distinction. This could cause confusion for an agent selecting which tool to use.
Naming Consistency5/5
All tool names follow a consistent 'verb_noun' pattern using snake_case (e.g., 'list_appliances', 'operate_aircon'), making them predictable and easy to understand.
Tool Count5/5
With 4 tools, the set is appropriately scoped for a simple home automation server, covering basic listing and operation tasks without being overwhelming.
Completeness3/5
The tool set covers listing and operating two specific appliances, but lacks operations for other common actions like turning off, scheduling, or managing devices/appliances, 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
Control your Tesla from your AI assistant - climate, charging, access, and security.
Control Android TV from any AI. 38 MCP tools: playback, recap, recommend, smart-home, schedules.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables AI models to control and query smart home devices (air conditioners, lights, locks, cameras, refrigerators) through a backend API. Supports device control operations, status queries, and detailed device information retrieval with built-in documentation for proper device usage.2
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to interact with Home Assistant smart home devices through natural language. Control devices, manage automations, query entity states, and retrieve historical data across your home automation system.1MIT
- FlicenseNot gradedqualityDmaintenanceEnables controlling smart home devices like lights, fans, air conditioners, and Android TVs through natural language commands, with persistent state and TV content search/playback via ADB.1
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/noboru-i/nature-remo-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server