Skip to main content
Glama

Increment a counter helper

helpers_increment_counter

Increment a Home Assistant counter by its configured step to count event occurrences. Not for resetting to zero.

Instructions

Increment a counter helper by its configured step.

Calls counter.increment with {"entity_id": entity_id} over HTTP; repeating this call keeps increasing the counter's value.

Use when: counting up an event occurrence. Not for: setting the counter back to zero — use helpers_reset_counter. Returns: the list of states changed by the call.

Input Schema

NameRequiredDescriptionDefault
entity_idYesFull counter entity ID to increment, e.g. 'counter.visits'.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.25.1
    • addedInput schema / properties / entity_id / description
      Added value: +"Full counter entity ID to increment, e.g. 'counter.visits'."
  2. First observedv0.3.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds useful behavioral context beyond that: the increment uses a configured step, repeating the call keeps increasing the value, and it returns the list of changed states. It does not discuss permissions or failure modes, but it meaningfully extends the annotation profile.

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 front-loaded with the action, then behavior, usage, exclusion, and return information. Every sentence is purposeful and there is no 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?

For a simple single-parameter helper with an output schema, the description covers purpose, behavior, when to use, the key alternative, and the return shape. Annotations cover safety, and the output schema handles return structure.

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

Parameters3/5

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

Schema description coverage is 100% and there is only one parameter, so the schema already documents entity_id fully. The description repeats the entity_id in an HTTP payload example but adds no new semantic detail such as format constraints or alternatives.

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 states a specific verb and resource ('Increment a counter helper') and immediately distinguishes it from the reset sibling. An agent can identify the tool's function without opening the schema.

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?

It gives explicit when-to-use guidance ('counting up an event occurrence') and an explicit exclusion with the correct alternative ('Not for: setting the counter back to zero — use helpers_reset_counter'). This directly resolves the most likely sibling ambiguity.

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