Skip to main content
Glama

Call a service and return its response

ws_call_service
Destructive

Call a Home Assistant action over WebSocket and return its response data. Use when you need the action's response payload, not just changed states.

Instructions

Call a Home Assistant action over WebSocket and return its response data.

Sends call_service with return_response=True always set, so actions that support a response (e.g. weather.get_forecasts, calendar.get_events) return it; actions without one (light.turn_on, most control actions) fail with a validation error. domain/service must match [A-Za-z0-9_]+ (ADR-0006 D3) or the call is refused first. Refuses hassio.addon_stop/app_stop/addon_stdin/app_stdin against nexus's own add-on (self_protection.is_own_addon); addon_restart/ app_restart stay allowed. Outright refuses the eight services services_call_service gates behind confirm (ADR-0006 D5) — none support a response (F1).

Use when: the action's response payload is needed, not just the changed states. Not for: a plain control action, or one of the eight guarded services — use services_call_service for both. Returns: raw WS result: {success, result: {context, response}} on success, or a failure dict from HA; {"success": False} if no result message arrives. Errors: raises RuntimeError on a handshake timeout; {"error": "invalid_service_name"} for a malformed domain/service; {"error": "self_addon_hassio_service_blocked", "message": ...} for a blocked hassio.* case; {"error": "guarded_service_refused", "message": ..., "use": "services_call_service"} for a guarded service. Limits: blocks for up to timeout seconds (default 10), including the initial handshake.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoService data: fields plus targets (entity_id/area_id/device_id). Omit for a call that needs no data.
domainYesService domain to call, e.g. 'weather' or 'calendar'.
serviceYesService name within the domain, e.g. 'get_forecasts' or 'get_events'.
timeoutNoMaximum seconds to wait for the WebSocket handshake and the result message before giving up; must be between 1 and 300.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.25.1
    • addedInput schema / properties / data / description
      Added value: +"Service data: fields plus targets (entity_id/area_id/device_id). Omit for a call that needs no data."
    • addedInput schema / properties / domain / description
      Added value: +"Service domain to call, e.g. 'weather' or 'calendar'."
    • addedInput schema / properties / service / description
      Added value: +"Service name within the domain, e.g. 'get_forecasts' or 'get_events'."
    • addedInput schema / properties / timeout
      Added value: +{
      +  "default": 10,
      +  "description": "Maximum seconds to wait for the WebSocket handshake and the result message before giving up; must be between 1 and 300.",
      +  "maximum": 300,
      +  "minimum": 1,
      +  "type": "number"
      +}
  2. First observedv0.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotations (which only flag destructive/openWorld/idempotent hints): it discloses that return_response=True is always sent, that non-response actions fail with a validation error, the domain/service name regex, the self-addon protection for hassio.* services, the guarded-service refusal, the full error taxonomy, and the blocking timeout behavior.

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?

Front-loaded with purpose, then cleanly sectioned into Use when / Not for / Returns / Errors / Limits. Dense and nearly every line earns its place, though the ADR/requirement citations (D3, D5, F1) add provenance noise for an agent.

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?

Despite an output schema existing, the description covers return shape, error variants, and timeout limits, plus the refusal paths. Nothing an agent needs to invoke this correctly is missing.

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 coverage is 100% so the baseline is 3, but the description adds a constraint not present in the schema: domain/service must match [A-Za-z0-9_]+ or the call is refused, plus the timeout blocks for handshake and result. That is meaningful extra semantics.

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?

States a specific verb (call), resource (Home Assistant action over WebSocket) and the differentiator (return its response data). It is immediately distinguishable from services_call_service, which is named as the sibling for the non-response case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use when' (response payload is needed, not just changed states) and 'Not for' (plain control actions, the eight guarded services), each routing to the named alternative services_call_service. Nothing is left to inference.

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

Deploy Server

Other Tools