WidgetDash MCP lets an AI agent push numbers and data to a user's iPhone Home Screen / Lock Screen widgets and Live Activities, and read them back.
push_number — set a single value on a source (metric matched by label), keeping the source's other metrics, title and icon; creates the source if it doesn't exist.
push_metrics — create or update a source (title, SF Symbol icon, category, sort order, optional raw_data) and replace its full metrics list (1–50) with typed metrics: number, text, status, progress, percentage, plus colors like green/red/yellow.
list_sources — list the widget's sources (key, title, icon, shown/hidden) and plan usage (free plan = 5 sources).
get_widget_data — read what's currently on the widget: every enabled source with its metrics and last update time, or a single source.
delete_source — permanently delete a source and end its Live Activity, when the user asks.
Writes require WIDGETDASH_WRITE_KEY; reads use the optional WIDGETDASH_READ_KEY (falling back to the write key).
Enables AI agents to push numbers, metrics, statuses, and progress values to WidgetDash widgets on iPhone Home Screen, Lock Screen, and Live Activities via the WidgetDash iOS app, and to read back current widget data.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@widgetdash-mcp Put my Stripe MRR on my iPhone widget."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Let your AI agent put any number on your iPhone.
WidgetDash shows numbers from any service on iPhone Home Screen widgets, Lock Screen widgets and Live Activities. This Model Context Protocol server lets Claude Desktop, Claude Code, Cursor and other MCP clients push data to your widgets and read it back. You just ask:
"Put my Stripe MRR on my iPhone widget."
The free WidgetDash iOS app: https://apps.apple.com/us/app/widgetdash/id6761054679, with a WidgetDash widget on your Home Screen or Lock Screen.
Your API keys. Get them at https://widgetdash.app/app.
Write key: lets the agent create and update your widget data.
Read key (optional): read-only access. If you leave it out, the read tools use the write key.
Node.js 18 or newer (npx comes with it).
Related MCP server: iPhone MCP
claude mcp add widgetdash -e WIDGETDASH_WRITE_KEY=your-write-key -- npx -y widgetdash-mcpEdit claude_desktop_config.json (Settings → Developer → Edit Config), then restart Claude Desktop:
{
"mcpServers": {
"widgetdash": {
"command": "npx",
"args": ["-y", "widgetdash-mcp"],
"env": {
"WIDGETDASH_WRITE_KEY": "your-write-key",
"WIDGETDASH_READ_KEY": "your-read-key"
}
}
}
}Add this to ~/.cursor/mcp.json for all projects, or .cursor/mcp.json for one project:
{
"mcpServers": {
"widgetdash": {
"command": "npx",
"args": ["-y", "widgetdash-mcp"],
"env": { "WIDGETDASH_WRITE_KEY": "your-write-key" }
}
}
}Other MCP clients that can launch a stdio server work the same way. The command is npx -y widgetdash-mcp, and the keys go in the environment variables below.
Variable | Required | Description |
| For writes | Write key from https://widgetdash.app/app. |
| No | Read key. |
| No | API base URL. Default: |
"Put my Stripe MRR on my iPhone widget." (The agent reads the number with a Stripe tool, then calls push_number.)
"Show today's GitHub stars, open issues and open PRs for my repo on my Lock Screen widget."
"Make a 'Server' widget with CPU as a progress bar, uptime as a number and a green 'Healthy' status badge."
"Every time you finish a build, set the 'CI' widget status to Passing or Failing."
"What's on my WidgetDash widget right now?"
"Remove the old 'test' source from my widget."
Tool | What it does |
| Sets one value on a source, e.g. |
| Creates or updates a source: title ( |
| Lists your sources (key, title, icon, hidden or shown) and how many your plan allows. The free plan allows 5. |
| Shows what's on the widget now: every enabled source with its metrics and last update time, or a single source. |
| Permanently deletes a source and ends any Live Activity for it. |
Each metric has a label, a value, an optional type, an optional color and an optional wide:
type sets how the widget draws the value:
number: a big bold figure.
text: a plain string.
status: a colored badge.
progress: a bar. The value must be 0 to 100, and a trailing % is removed for you.
percentage: compact percent text.
timestamp: a moment, shown as a live relative time such as "8 hours ago". Send an ISO 8601 time (2026-10-23T05:00:00Z) or Unix epoch seconds. Reads show the relative time plus the exact time.
If you leave type out, values that look like numbers (42, $12,400, 3.5%) become number and everything else becomes text. With push_number, an existing metric keeps its current type, color and wide, and the source's other metrics are re-sent as they were stored: timestamps keep their exact time, and colors chosen by the source's color rules stay under the rules' control.
color: green, red, yellow, blue, gray, orange, purple or cyan.
wide: true gives the metric a full-width row of its own on Large widgets (iOS app 1.8 or later), for long text such as a title. Other text that shares a row shows up to two lines. Put wide metrics last to keep the others in one row.
icon: any SF Symbol name, e.g. dollarsign.circle.fill, chart.bar.fill, server.rack or heart.fill.
Fields you leave out (display_name, icon, category, raw_data) keep their current values. sort_order only places a new source: once it exists, its order is the one set in the app, so an agent can't undo it.
The write key can only write your own widget data. It can't reach other users' data or your account's billing.
Keys go only in the Authorization header of requests to the WidgetDash API. The server never logs them and removes them from any error text it returns.
Treat the write key like a password. If it leaks, rotate it at https://widgetdash.app/app.
The server only talks to WIDGETDASH_API_URL, which is https://api.widgetdash.app by default.
npm install
npm run build # compiles src/ to dist/
npm test # builds, then runs the end-to-end testsnpm test runs every tool through a real MCP client over stdio, against an in-memory mock of the WidgetDash API (test/mock-api.mjs). It needs no network and no keys, and it never contacts production.
To try it interactively, run npx @modelcontextprotocol/inspector node dist/index.js.
server.json is the entry for the official MCP Registry under the name io.github.purian/widgetdash-mcp, following schema 2025-12-11. The mcpName field in package.json must match that name for npm ownership verification. Status: draft. It hasn't been published yet, and the registry is still in preview, so check server.json against the current schema before running mcp-publisher publish.
MIT © WidgetDash
Permanently delete a data source (and its data) from the user's WidgetDash iPhone widgets. Ends any Live Activity for it. Only do this when the user asks to remove it. Requires WIDGETDASH_WRITE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| source_key | Yes | The source_key to delete (see list_sources). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint and idempotentHint, but the description adds material specifics beyond them: the deletion is permanent and cascades to the source's data, it terminates any associated Live Activity, and it requires WIDGETDASH_WRITE_KEY. These are exactly the irreversible side effects and auth requirements an agent needs before invoking a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: what is deleted, the side effect, the usage constraint, and the auth requirement. The destructive action is stated first and nothing is repeated from the annotations or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with no output schema, the description covers the operation, its cascading consequences, the required credential, and when it should be used. Nothing an agent needs to invoke this safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single required parameter (source_key) already documented with pattern, length, and a pointer to list_sources. The description adds no parameter-level detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a precise verb+resource+scope: 'Permanently delete a data source (and its data) from the user's WidgetDash iPhone widgets.' It also names the cascading effect ('Ends any Live Activity for it'), so an agent knows exactly what operation it is. Sibling differentiation is only implicit (the schema points to list_sources), but the purpose itself is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Only do this when the user asks to remove it' gives an explicit when-to-use condition and an implied guardrail against proactive deletion. It stops short of naming alternatives (e.g., list_sources for inspection) or noting prerequisites beyond the key, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what is currently shown on the user's WidgetDash iPhone widgets: every enabled source with its metrics and last update time, or one source if source_key is given. Uses WIDGETDASH_READ_KEY, or the write key if no read key is set.
| Name | Required | Description | Default |
|---|---|---|---|
| source_key | No | Only return this source. Omit to return all sources shown on the widget. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds a genuinely useful operational fact: it authenticates with WIDGETDASH_READ_KEY, falling back to the write key when no read key is set. It also indicates the return payload contains metrics and last update time, though it does not detail error or auth-failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, no filler, with the primary behavior (what is shown on the widget) front-loaded ahead of the mode switch and the auth note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing results and does so at a high level (enabled sources, metrics, last update time) plus the auth mechanism. A slightly fuller sketch of the returned structure would close the remaining gap for an open-world read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter's description already explains that omitting it returns all sources. The description's 'or one source if source_key is given' restates the schema rather than adding format or constraint detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: reading what is currently displayed on the user's WidgetDash iPhone widgets, including metrics and last update time. That framing (current widget state) is distinguishable from generic source management, though the distinction from list_sources is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear selection logic for the two modes: omit source_key for all enabled sources, supply it for a single source. It does not explain when to prefer this over the sibling list_sources, which appears to overlap in returning source information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the data sources on the user's WidgetDash iPhone widgets (source_key, title, icon, enabled/hidden) plus the plan's source usage (the free plan allows 5 sources). Uses WIDGETDASH_READ_KEY, or the write key if no read key is set.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already declared, the description adds meaningful context: it discloses the required credential (WIDGETDASH_READ_KEY, falling back to the write key) and describes the returned fields and plan quota. It does not cover rate limits or error behavior, but the auth detail is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences that front-load the list operation and then cover return fields, plan quota, and authentication. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only list tool, the description covers what is returned, the auth mechanism, and plan constraints. With no output schema, this is sufficient; nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the rubric sets the baseline at 4. The description adds no parameter-level information because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('data sources on the user's WidgetDash iPhone widgets'), and enumerates the returned fields. It clearly separates from push_* and delete_source siblings, but does not explicitly contrast with get_widget_data, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no alternatives named, and no exclusion criteria. The only usage signal is the auth-key note, which explains how to authenticate rather than when this tool is the correct choice over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a WidgetDash data source shown on the user's iPhone Home Screen / Lock Screen widgets and Live Activities. Sets the source's title, SF Symbol icon, category and its full list of metrics (label + value + type + color). The metrics list REPLACES the source's current metrics; use push_number to change a single value. Omitted display_name/icon/category keep their current values; sort_order only applies when the source is created. Requires WIDGETDASH_WRITE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| icon | No | SF Symbol name shown next to the title, e.g. 'dollarsign.circle.fill', 'chart.bar.fill', 'server.rack', 'heart.fill', 'cart.fill'. If omitted, keeps the existing icon (default 'circle.fill'). | |
| metrics | Yes | Metrics to show, in display order. Small widgets show the first few, so put the most important first. | |
| category | No | Free-form grouping, e.g. 'finance', 'monitoring', 'fitness'. If omitted, keeps the existing category (default 'general'). | |
| raw_data | No | Optional arbitrary JSON object stored alongside the metrics (not shown on the widget). If omitted, existing raw_data is kept. | |
| sort_order | No | Position for a NEW source among your sources (lower first, default 0). Ignored when updating an existing source: its order is set in the WidgetDash app. | |
| source_key | Yes | Stable identifier for this data source, e.g. 'stripe_mrr' or 'server_health'. Lowercase letters, digits, '_' or '-'. Pushing to an existing key updates it; a new key creates a new widget source. | |
| display_name | No | Title shown on the widget, e.g. 'Stripe'. If omitted, keeps the existing name (or derives one from source_key for new sources). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=false, but the description says the metrics list REPLACES the source's current metrics. Replacing a full list overwrites/removes prior metrics, which is a destructive update, so the description contradicts the annotation. Otherwise the description adds useful context such as the write key and create-only sort_order, but the contradiction forces a 1 under the rules.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four tight sentences and front-loads the create-or-update behavior plus the replacement warning. Every sentence adds either routing guidance, overwrite semantics, or authentication requirements. There is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich schema descriptions and annotations, the description covers the key behavioral details: mutation, full-list replacement, omitted-field preservation, create-only sort_order, and auth. It does not describe the response or error behavior, which is a minor gap for a mutating tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters in detail. The description still adds meaning by emphasizing that metrics REPLACES the existing list, omitted display fields are preserved, and sort_order is create-only. It does not add much granular syntax beyond the schema, but the replacement semantics are important.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: create or update a WidgetDash data source shown in iPhone widgets and Live Activities. It also distinguishes the tool from push_number by explaining that this tool sets the full metrics list. An agent can identify the operation 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use push_number to change a single value, which routes the agent between this tool and its closest sibling. It also explains that omitted display_name/icon/category keep current values and that sort_order only applies on creation. The WIDGETDASH_WRITE_KEY requirement is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quickest way to put a single number or value on the user's iPhone Home Screen / Lock Screen widget via WidgetDash, e.g. 'Stripe MRR = $12,400' or 'Open tickets = 7'. Sets one metric (matched by label) on a source, keeping the source's other metrics, title and icon; creates the source if it does not exist. Requires WIDGETDASH_WRITE_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| icon | No | SF Symbol name shown next to the title, e.g. 'dollarsign.circle.fill', 'chart.bar.fill', 'server.rack', 'heart.fill', 'cart.fill'. If omitted, keeps the existing icon (default 'circle.fill'). | |
| type | No | Optional; defaults to the existing metric's type, else inferred from the value. | |
| color | No | Optional accent color (green/red/yellow/blue/gray/orange/purple/cyan); defaults to the existing metric's color. | |
| label | Yes | Short label shown on the widget, e.g. 'MRR' or 'Users online'. | |
| value | Yes | The value to display, pre-formatted as you want it shown (e.g. '$12,400', '42', 'Healthy'). For 'progress' use 0-100; for 'timestamp' an ISO 8601 time or Unix epoch seconds. | |
| category | No | Free-form grouping, e.g. 'finance', 'monitoring', 'fitness'. If omitted, keeps the existing category (default 'general'). | |
| sort_order | No | Position for a NEW source among your sources (lower first, default 0). Ignored when updating an existing source: its order is set in the WidgetDash app. | |
| source_key | Yes | Stable identifier for this data source, e.g. 'stripe_mrr' or 'server_health'. Lowercase letters, digits, '_' or '-'. Pushing to an existing key updates it; a new key creates a new widget source. | |
| display_name | No | Title shown on the widget, e.g. 'Stripe'. If omitted, keeps the existing name (or derives one from source_key for new sources). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses upsert semantics (matched by label, other metrics/title/icon preserved), that a new source is created for an unknown source_key, and the required write key. The idempotentHint annotation is corroborated rather than restated; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the use case and examples, then the merge/create behavior, then the auth requirement. Every sentence carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter upsert tool with annotations but no output schema, the description covers creation vs update, preservation of existing fields, and auth. It doesn't indicate what the call returns (e.g., created source ID/confirmation), which is the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description still adds meaning by explaining that label is the matching key against existing metrics and that source_key determines update-vs-create. It adds no extra guidance on type/color/sort_order beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource+scope: put a single number/value on the user's iPhone Home/Lock Screen widget via WidgetDash, with two concrete examples. It implies differentiation from the multi-metric sibling ('single number') but never names push_metrics, so sibling routing still requires inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when this applies ('Quickest way to put a single number') and states the prerequisite (WIDGETDASH_WRITE_KEY). It does not explicitly name push_metrics as the alternative for several metrics, nor state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0push_metrics5 fields changedInput schema / properties / metrics / items / properties / type / descriptionPrevious value: -"How the widget renders the value: 'number' = big bold figure (counts, money, KPIs); 'text' = plain short string; 'status' = colored badge (e.g. 'Healthy', 'Down'); 'progress' = bar, value must be 0-100; 'percentage' = compact percent text. If omitted: 'number' for numeric-looking values (42, $12,400, 3.5%), otherwise 'text'."New value: +"How the widget renders the value: 'number' = big bold figure (counts, money, KPIs); 'text' = plain short string; 'status' = colored badge (e.g. 'Healthy', 'Down'); 'progress' = bar, value must be 0-100; 'percentage' = compact percent text; 'timestamp' = a moment shown as live relative time (e.g. '8 hours ago'), value is ISO 8601 like 2026-10-23T05:00:00Z or Unix epoch seconds. If omitted: 'number' for numeric-looking values (42, $12,400, 3.5%), otherwise 'text'."Input schema / properties / metrics / items / properties / type / enumPrevious value: -[
- "number",
- "text",
- "status",
- "progress",
- "percentage"
-]New value: +[
+ "number",
+ "text",
+ "status",
+ "progress",
+ "percentage",
+ "timestamp"
+]Input schema / properties / metrics / items / properties / value / descriptionPrevious value: -"The value to display, pre-formatted as you want it shown (e.g. '$12,400', '42', 'Healthy'). For 'progress' use 0-100."New value: +"The value to display, pre-formatted as you want it shown (e.g. '$12,400', '42', 'Healthy'). For 'progress' use 0-100; for 'timestamp' an ISO 8601 time or Unix epoch seconds."Input schema / properties / metrics / items / properties / wideAdded value: +{
+ "description": "Optional. true gives the metric a full-width row of its own on Large widgets (iOS app 1.8+), for long text such as a title. Other text that shares a row shows up to two lines. Put wide metrics last to keep the others in one row.",
+ "type": "boolean"
+}Input schema / properties / sort_order / descriptionPrevious value: -"Position among sources on the widget (lower first). If omitted, keeps the existing order (default 0)."New value: +"Position for a NEW source among your sources (lower first, default 0). Ignored when updating an existing source: its order is set in the WidgetDash app."push_number3 fields changedInput schema / properties / sort_order / descriptionPrevious value: -"Position among sources on the widget (lower first). If omitted, keeps the existing order (default 0)."New value: +"Position for a NEW source among your sources (lower first, default 0). Ignored when updating an existing source: its order is set in the WidgetDash app."Input schema / properties / type / enumPrevious value: -[
- "number",
- "text",
- "status",
- "progress",
- "percentage"
-]New value: +[
+ "number",
+ "text",
+ "status",
+ "progress",
+ "percentage",
+ "timestamp"
+]Input schema / properties / value / descriptionPrevious value: -"The value to display, pre-formatted as you want it shown (e.g. '$12,400', '42', 'Healthy'). For 'progress' use 0-100."New value: +"The value to display, pre-formatted as you want it shown (e.g. '$12,400', '42', 'Healthy'). For 'progress' use 0-100; for 'timestamp' an ISO 8601 time or Unix epoch seconds."v0.1.0delete_sourceget_widget_datalist_sourcespush_metricspush_numberScored across 5 tools
Each tool has a distinct action, and the push_metrics vs push_number overlap is explicitly resolved in the descriptions (full metric list replacement vs single value update). The only mild ambiguity is between get_widget_data and list_sources, since get_widget_data also enumerates sources with metrics, though list_sources uniquely adds plan usage metadata.
All five tools follow a clean snake_case verb_noun pattern (delete_source, get_widget_data, list_sources, push_metrics, push_number). Verbs are semantically meaningful and consistent within the read (get/list) and write (push/delete) families.
Five tools map exactly onto the domain's core operations: list sources, read widget data, full upsert, quick single-value upsert, and delete. No redundant tools and nothing that feels like padding.
The lifecycle is largely covered: read, list, create/update (both full and incremental), and delete. Minor gaps exist — sources are listed with enabled/hidden state but there is no tool to toggle visibility, reorder, or remove an individual metric, so agents must rewrite the whole metric list to make such changes.
AI agents and scripts reporting back to your iPhone with Push Notifications and Live Activities.
Publish status cards and Live Activities to iOS widgets, the Lock Screen, and the Dynamic Island.
Let your AI agent control real iPhones: screenshots, tap, swipe, type and open apps.
Push notifications for AI agents - send instant iPhone notifications from any MCP client.
