Skip to main content
Glama
tim661811
by tim661811

Create a HomeyScript script

homey_script_create

Create a new Homey script and get its ID. Write reusable JavaScript that runs on the hub, takes arguments, and returns values to Flows.

Instructions

Creates a new script and returns the id the Homey assigned to it. Use that id afterwards: the name is not an address, and two scripts may share one. The script runs on the Homey, so it has the Homey API available as Homey, writes output with log(), and can hand a value back to the Flow that started it with return or tag(). Write scripts to be reusable. Take what varies as an argument rather than baking it in: the HomeyScript Flow card passes text into the script as args[0], so one script can serve several Flows and several rooms. Prefer looking a device up by what it IS over what its id is, for example by zone and capability, so the script survives a device being replaced. Prefer returning a value and letting the Flow act on it over acting inside the script. A script that answers "should I open the window" can be reused; one that also opens the window cannot. A hard-coded device id is acceptable when there is genuinely no other way, or when a lookup would be more fragile than the id. It is the exception, and it is worth a comment saying why. This server cannot see log() output: it goes to the HomeyScript app console and no route here reads it. What comes back is the return value, so return whatever needs checking rather than logging it. While a script is being written, return an object with the intermediate values in it; trim it to the real answer once it works. Run it with homey_script_run once created, because a script that has never run is a script nobody has checked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesThe JavaScript to run on the Homey.
nameYesA short descriptive name, shown in the HomeyScript app and when picking the script in a Flow.
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important runtime behavior: the script executes on the Homey with Homey API access, log() output goes to the HomeyScript app console and is not visible to this server, and the response is the script's return value. It also explains the script can return or tag() values back to the Flow, adding real 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.

Conciseness5/5

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

The description is long but every sentence earns its place. It is front-loaded with the core purpose, then follows a logical flow from creation, to runtime behavior, to authoring best practices, to debugging and verification. There is no redundancy or filler.

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?

There is no output schema, but the description clearly explains what is returned (the assigned id and, for scripts, the return value). It also covers runtime environment, Flow integration, logging limitations, and the recommended next step. This is complete for a create tool with this complexity.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: code is JavaScript running on the Homey, name is shown in the app and Flow picker, scripts receive args[0] from the Flow card, and return values are observable while log() is not. This greatly enriches both parameters.

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 opens with a specific verb and resource: 'Creates a new script and returns the id the Homey assigned to it.' It clearly distinguishes creation from sibling tools like homey_script_update, homey_script_get, and homey_script_delete by emphasizing that the returned id is the address, not the name.

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 workflow context: use the returned id afterwards and run the script with homey_script_run once created. It also provides substantial guidance on how to write reusable scripts. It does not explicitly contrast with update/delete/alternatives, so it stops short of a full 5.

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

Other Tools

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/tim661811/homey-mcp'

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