ActivitySmith

Set Widget Metric Value

set_widget_metric_value

Record the latest value of a Lock Screen Widget metric, identified by its key. Use it whenever the tracked number or text changes, such as new revenue, signups, or uptime. The value replaces the previous one. Widgets on the user's Lock Screen pick it up on their next refresh, about every 15 minutes, so it is not instant; for an immediate alert, use send_push_notification. If no metric uses the key yet, this creates one with a label made from the key, in number format for numeric values and string format for text; call create_widget_metric first for a currency, percent, or unit format or a custom label. Keys of deleted metrics are not recreated. Each successful call counts as a billable metric update and returns a billing error when the account's trial or plan does not allow more. Returns the metric with its new latest value and created: true when this call created it.

Input Schema

Name	Required	Description
`key`	Yes	Metric key, as shown by list_widget_metrics. A new key creates the metric. 1-64 lowercase letters, numbers, dots, underscores, or dashes. Example: mrr.
`value`	Yes	New value. For number, currency, percent, and unit metrics, send a number; formatted text such as "$1,234.50", "99.9%", or "120ms" is also parsed. For string metrics, send text up to 64 characters.
`timestamp`	No	Optional ISO 8601 time the value was measured, such as 2026-10-18T09:00:00Z. Defaults to now.

Output Schema

Name	Required	Description	Default
`metric`	Yes
`created`	No
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 26, 2026

changedInput schema / properties / key / description

Previous value: -"Key of an existing metric, as shown by list_widget_metrics. Example: mrr."New value: +"Metric key, as shown by list_widget_metrics. A new key creates the metric. 1-64 lowercase letters, numbers, dots, underscores, or dashes. Example: mrr."

changedOutput schema / description

Previous value: -"The widget metric after its latest value was recorded."New value: +"The widget metric after its latest value was recorded. created is true when this call created the metric."

addedOutput schema / properties / created
```
Added value: +{
+  "type": "boolean"
+}
```

First observedOct 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare it is a non-destructive write; the description adds real substance: value overwrite semantics, ~15-minute refresh latency, auto-creation with inferred format, that deleted-metric keys are not recreated, and billing errors on trial/plan limits.

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?

Purpose and usage are front-loaded in the first two sentences with no filler, but the remainder is one dense run-on covering creation, formats, deletion, billing, and return value that could be split for scannability.

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 3-parameter mutation tool with an output schema, the description covers everything an agent needs: idempotent-style overwrite behavior, latency expectations, creation side effects, prerequisites, and failure modes (billing, deleted keys). Return-value explanation is redundant but harmless.

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, and the description adds some meaning: that the key drives creation, that the value replaces the prior value, and how numeric/text values are treated. Format-parsing details and the timestamp default are already in the schema, so the gain is modest rather than large.

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 (record/set) and resource (Lock Screen Widget metric value) keyed by metric key, and distinguishes itself from create_widget_metric and update_widget_metric by describing auto-creation and value replacement explicitly.

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?

Gives explicit triggers ('whenever the tracked number or text changes'), an exclusion with an alternative ('for an immediate alert, use send_push_notification'), and a prerequisite routing rule ('call create_widget_metric first for a currency, percent, or unit format or a custom label').

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

All ActivitySmith tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?