KOVA MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_devicesA | List available myGEKKO devices, optionally filtered to one system. Args: system: optional system key (e.g. 'lights', 'blinds', 'roomtemps'). |
| get_stateA | Read the current state of a device by its path (e.g. 'lights/item0'). |
| describe_capabilitiesA | Discover what this specific controller exposes and how to control it. Because every installation is configured differently, call this to learn which systems exist, which are controllable, and the exact command grammar of each writable device. Systems with a 'typed_tool' are best driven by that tool (e.g. control_light); the rest are driven by 'control_device' using an advertised command token or label. Args: system: optional system key to describe just one (e.g. 'lights'). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| inventory_resource | Full device inventory: systems, items, paths, and capabilities. |
| capabilities_resource | What THIS controller can do: systems + decoded per-device command grammar. |
TDQS
Scored across 3 tools
The three tools have clearly distinct responsibilities: listing devices, reading state, and describing controller capabilities. However, the describe_capabilities description references 'control_light' and 'control_device' tools that are not present in the set, which could confuse an agent about which tool to use for control operations.
All tool names consistently follow the verb_noun snake_case pattern: list_devices, get_state, describe_capabilities. The naming is perfectly uniform and predictable, with no mixed conventions or unexplained abbreviations.
Three tools is at the low end of what would be appropriate for a smart home server, but since the tools reference dynamic, configuration-driven capabilities, the count is borderline acceptable for a discovery/query-focused surface. However, the absence of any control tools (referenced but not included) makes the surface feel thin for what appears to be a home automation domain.
The surface covers discovery and reading well but is significantly incomplete for control tasks. An agent can list devices, read state, and learn how to control systems, but then hits a dead end because control_light and control_device do not actually exist as tools. The capability descriptions promise actions the server cannot perform, creating a clear gap.