Skip to main content
Glama

update_habit

Update an existing habit by changing only specified fields like name, reminders, or status, without affecting other properties.

Instructions

Update an existing habit. Only provided fields are changed
(read-modify-write under the hood — safe for partial updates).

[Category: Habits]  [Auth: V2]
[Related: list_habits, create_habit, delete_habit]

Args:
    habit_id: The habit ID to update.
    name: New name.
    goal: New target value (Real habits).
    step: New increment step.
    unit: New measurement unit.
    color: New hex color.
    status: 0=active, 2=archived.
    section_id: Move to a different section.
    repeat_rule: New RRULE (use build_recurrence_rule).
    reminders: New reminder times list, e.g. ["08:00", "20:00"].
               Pass [] to clear all reminders.
    encouragement: New completion message.
    target_days: New target days.

⚠️  CRITICAL — V2 /habits/batch is a FULL REPLACEMENT, not a PATCH:
    Sending only {"id": ..., "reminders": [...]} will wipe name, color,
    status and every other field to null/default. This tool prevents that
    by fetching the current habit state first, then merging your changes
    before sending the complete object. Never call client.batch_habits
    with a partial habit dict directly.

Common uses:
    Archive:        update_habit(habit_id="...", status=2)
    Rename:         update_habit(habit_id="...", name="New Name")
    Add reminders:  update_habit(habit_id="...", reminders=["08:00", "20:00"])
    Clear reminders: update_habit(habit_id="...", reminders=[])

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
habit_idYes
nameNo
goalNo
stepNo
unitNo
colorNo
statusNo
section_idNo
repeat_ruleNo
remindersNo
encouragementNo
target_daysNo
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: it explains the read-modify-write pattern for safe partial updates, warns that the V2 batch endpoint does full replacement, and specifies that only provided fields are changed. This is comprehensive and honest.

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 structured well with sections: general description, args list, critical warning, and common uses. It is somewhat lengthy but each sentence adds value due to the tool's complexity. Front-loaded with the key behavior.

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?

Given 12 parameters, no output schema, and no annotations, the description covers all necessary aspects: behavior, parameters, usage warnings, common scenarios, and related tools. It is thorough and leaves no major gaps.

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?

Despite 0% schema description coverage, the description lists all 12 parameters with meaningful explanations, including examples for reminders (e.g., format and clearing) and status values (0=active, 2=archived). It adds substantial context beyond the schema's property names.

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 clearly states 'Update an existing habit' with a specific verb and resource. It distinguishes from siblings by explicitly mentioning it's a partial update (read-modify-write) and contrasting with create_habit and delete_habit in the related tools.

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?

The description provides explicit usage context: when to use for partial updates, common examples like archive/rename/reminders, and a critical warning against using the underlying batch endpoint directly. It also lists related tools for context.

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

Install Server

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/KpihX/tick-mcp'

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